У меня есть два выделенных сервера: «веб» (ГГГ.ГГГ.ГГГ.ГГГ) и «монитор» (ХХХ.ХХХ.ХХХ.ХХХ).
Оба находятся в одной сети массового хостера (hetzner).
Теперь в «сети» у меня работают 3 метрические конечные точки prometheus: docker-engine (9323) на «голом железе» и neo4j (2004), telegraf (9273) в качестве контейнеров докеров.
Оба док-контейнера правильно сопоставляют свои выходные порты с хостом, поэтому следующие вызовы, выполняемые в «сети», работают:
рысь http://YYY.YYY.YYY.YYY:9323/metrics => ОК
рысь http://YYY.YYY.YYY.YYY:9273/metrics => ОК
рысь http://YYY.YYY.YYY.YYY:2004/metrics => ОК
Но вызов этих конечных точек с «мониторного» сервера работает только для докер-движка службы медвежьего металла (9323).
рысь http://YYY.YYY.YYY.YYY:9323/metrics => ОК
рысь http://YYY.YYY.YYY.YYY:9273/metrics => время ожидания
рысь http://YYY.YYY.YYY.YYY:2004/metrics => время ожидания
Подробный статус UFW предоставляет следующее
Статус: активен
Ведение журнала: включено (низкий уровень)
По умолчанию: запрещать (входящие), разрешать (исходящие), запрещать (маршрутизируемые)
Новые профили: пропустить
К действию от
-- ------ ----
[...]
9323/tcp РАЗРЕШИТЬ ВХОД XXX.XXX.XXX.XXX
9273/tcp РАЗРЕШИТЬ ВХОД XXX.XXX.XXX.XXX
2004/tcp РАЗРЕШИТЬ В XXX.XXX.XXX.XXX
[...]
Для этих IP-адресов нет других правил, а также общих правил, которые применяются к подсетям, интерфейсам и т. д. Все остальные правила предназначены для дискретных портов, например 22, 80, 443 и т. д.
Странно то, что это сработало всего за несколько часов до этого. Тем временем я немного экспериментировал с этим здесь https://medium.com/@pitapun_44686/what-is-the-best-practice-of-docker-ufw-under-ubuntu-69e11c826b31 и добавил следующий блок в самый конец /etc/ufw/after.rules
*фильтр
:ufw-пользователь-вперед - [0:0]
:ДОКЕР-ПОЛЬЗОВАТЕЛЬ - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j ВОЗВРАТ -s 192.168.0.0/16
-A DOCKER-USER -j ufw-user-forward
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12
-A DOCKER-USER -j ВОЗВРАТ
СОВЕРШИТЬ
Теперь я закомментировал это и перезапустил ufw. Эти порты 9273 и 2004 по-прежнему недоступны, так что причина не в этом.
Я настроил уровень журнала ufw на высокий, но не вижу никаких попыток подключения или отброшенных пакетов с хоста XXX.XXX.XXX.XXX.
Пытаясь подключиться через telnet к одному рабочему порту (telnet YYY.YYY.YYY.YYY 9323), я вижу связь в журналах ufw, но не для двух других портов.
[АУДИТ UFW] SRC=XXX.XXX.XXX.XXX DST=YYY.YYY.YYY.YYY DPT=9323 =>
[АУДИТ UFW] SRC=YYY.YYY.YYY.YYY DST=XXX.XXX.XXX.XXX SPT=9323
Я подготовил ufw с помощью модуля ansible «ufw».
Какие еще могут быть причины? Что здесь происходит? :-)
Может быть, сеть хостеров налагает какой-то фильтр между этими серверами из-за «подозрительной» активности (частого общения)?
Бывает и так, что сегодня я запускаю несколько избыточных тестов artarti.io с XXX.XXX.XXX.XXX на порт 80/443 на YYY.YYY.YYY.YYY, но эта гипотеза не объясняет, почему не работают только эти два порта. больше.
И окончательный тест, отключение ufw на YYY.YYY.YYY.YYY, тоже не помогает. Порты 9273 и 2004 недоступны, 9323 есть.
Вот вывод из iptables -L -v -n https://pastebin.com/HVeJGXb9
