Почему на моем устройстве с обратной связью отсутствует трафик, отличный от 127.xxx?
У меня проблема, которая вызвала у меня головную боль, и я нашел решение, но я не могу понять, почему проблема вообще возникла.
Я ' У нас есть обратный прокси-сервер nginx, который маршрутизирует запросы на 1 из 3 серверов. Все они являются узловыми серверами, два из них являются экспресс-серверами, а один изготовлен на заказ.
Проблема: , когда мой брандмауэр включен , первый запрос из общего времени безотказной работы двух экспресс-серверов страдает 504: Тайм-аут шлюза . После этого файлы обслуживаются быстро и без проблем, даже в течение нескольких дней.
Мне удалось сузить проблему до брандмауэра, заметив, что проблема исчезает, когда я полностью выключаю брандмауэр. На моем сервере работает FreeBSD с использованием PF в качестве брандмауэра. Вот соответствующий pf.conf:
iface = "vtnet0"
loopback = "lo0"
public_ip = "132.148.77.28/32"
localnet = "127.0.0.1"
nat on $iface from any to any -> $public_ip # added by cloud server provider
pass out quick on $iface proto { tcp udp } from port ntp keep state
block log all
pass in on $iface proto tcp from $localnet to port mail
pass in log on $iface proto tcp to $public_ip port { ssh http } keep state
pass in log on $loopback proto tcp to $localnet port { 5555 5556 5557 } keep state
pass out log all keep state
Я понимаю, что любой трафик на устройстве vtnet0 будет переведен на использование общедоступного IP.
Я запустил tcpdump с помощью следующей команды:
sudo tcpdump -c 10 -vvv -t -i pflog0 -e -n tcp
Я захватил 10 пакетов с тройной детализацией, подавив временную метку, на pflog0, распечатав правило pf, которое разрешало или блокировало пакет, оставив IP-адреса и порты в виде чисел и перехватывая трафик только с помощью tcp.
Вот интересные результаты первого запроса, а также результаты последующих запросов:
$ sudo tcpdump -c 10 -vvv -t -i pflog0 -e -n tcp
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes
rule 8..16777216/0(match): pass in on vtnet0: (tos 0x0, ttl 52, id 53488, offset 0, flags [DF], proto TCP (6), length 60)
67.197.156.119.45274 > 132.148.77.28.80: Flags [S], cksum 0x76df (correct), seq 356096480, win 29200, options [mss 1460,sackOK,TS val 63916304 ecr 0,nop,wscale 7], length 0
rule 9..16777216/0(match): pass out on lo0: (tos 0x0, ttl 64, id 2406, offset 0, flags [DF], proto TCP (6), length 60)
127.0.0.1.28850 > 127.0.0.1.5556: Flags [S], cksum 0xfe30 (incorrect -> 0x180a), seq 2069090201, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 33367168 ecr 0], length 0
rule 5..16777216/0(match): pass in on lo0: (tos 0x0, ttl 64, id 2406, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->3354)!)
127.0.0.1.28850 > 127.0.0.1.5556: Flags [S], cksum 0xfe30 (incorrect -> 0x180a), seq 2069090201, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 33367168 ecr 0], length 0
rule 9..16777216/0(match): pass out on lo0: (tos 0x0, ttl 64, id 2414, offset 0, flags [DF], proto TCP (6), length 60)
132.148.77.28.48488 > 132.148.77.28.80: Flags [S], cksum 0xa38f (incorrect -> 0x1728), seq 3973611725, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 33367544 ecr 0], length 0
rule 2..16777216/0(match): **block in on lo0**: (tos 0x0, ttl 64, id 2414, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->8ded)!)
132.148.77.28.48488 > 132.148.77.28.80: Flags [S], cksum 0xa38f (incorrect -> 0x1728), seq 3973611725, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 33367544 ecr 0], length 0
rule 2..16777216/0(match): **block in on lo0**: (tos 0x0, ttl 64, id 2416, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->8deb)!)
132.148.77.28.48488 > 132.148.77.28.80: Flags [S], cksum 0xa38f (incorrect -> 0x0b6a), seq 3973611725, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 33370550 ecr 0], length 0
rule 2..16777216/0(match): **block in on lo0**: (tos 0x0, ttl 64, id 2418, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->8de9)!)
132.148.77.28.48488 > 132.148.77.28.80: Flags [S], cksum 0xa38f (incorrect -> 0xfee6), seq 3973611725, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 33373753 ecr 0], length 0
rule 2..16777216/0(match): **block in on lo0**: (tos 0x0, ttl 64, id 2420, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->8de7)!)
132.148.77.28.48488 > 132.148.77.28.80: Flags [S], cksum 0xa38f (incorrect -> 0xf265), seq 3973611725, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 33376954 ecr 0], length 0
rule 2..16777216/0(match): **block in on lo0**: (tos 0x0, ttl 64, id 2422, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->8de5)!)
132.148.77.28.48488 > 132.148.77.28.80: Flags [S], cksum 0xa38f (incorrect -> 0xe5c8), seq 3973611725, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 33380183 ecr 0], length 0
rule 2..16777216/0(match): **block in on lo0**: (tos 0x0, ttl 64, id 2424, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->8de3)!)
132.148.77.28.48488 > 132.148.77.28.80: Flags [S], cksum 0xa38f (incorrect -> 0xd943), seq 3973611725, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 33383388 ecr 0], length 0
10 packets captured
11 packets received by filter
0 packets dropped by kernel
$ sudo tcpdump -c 10 -vvv -t -i pflog0 -e -n tcp
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes
rule 8..16777216/0(match): pass in on vtnet0: (tos 0x0, ttl 52, id 408, offset 0, flags [DF], proto TCP (6), length 60)
67.197.156.119.45482 > 132.148.77.28.80: Flags [S], cksum 0x2e49 (correct), seq 3314040182, win 29200, options [mss 1460,sackOK,TS val 64109806 ecr 0,nop,wscale 7], length 0
rule 9..16777216/0(match): pass out on lo0: (tos 0x0, ttl 64, id 2446, offset 0, flags [DF], proto TCP (6), length 60)
127.0.0.1.19450 > 127.0.0.1.5556: Flags [S], cksum 0xfe30 (incorrect -> 0x603e), seq 629617255, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 34141175 ecr 0], length 0
rule 5..16777216/0(match): pass in on lo0: (tos 0x0, ttl 64, id 2446, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->332c)!)
127.0.0.1.19450 > 127.0.0.1.5556: Flags [S], cksum 0xfe30 (incorrect -> 0x603e), seq 629617255, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 34141175 ecr 0], length 0
rule 9..16777216/0(match): pass out on lo0: (tos 0x0, ttl 64, id 2459, offset 0, flags [DF], proto TCP (6), length 60)
127.0.0.1.54320 > 127.0.0.1.5556: Flags [S], cksum 0xfe30 (incorrect -> 0x8ec2), seq 2137792783, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 34141359 ecr 0], length 0
rule 5..16777216/0(match): pass in on lo0: (tos 0x0, ttl 64, id 2459, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->331f)!)
127.0.0.1.54320 > 127.0.0.1.5556: Flags [S], cksum 0xfe30 (incorrect -> 0x8ec2), seq 2137792783, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 34141359 ecr 0], length 0
rule 8..16777216/0(match): pass in on vtnet0: (tos 0x0, ttl 52, id 13349, offset 0, flags [DF], proto TCP (6), length 60)
67.197.156.119.45484 > 132.148.77.28.80: Flags [S], cksum 0x9e57 (correct), seq 2310473985, win 29200, options [mss 1460,sackOK,TS val 64109860 ecr 0,nop,wscale 7], length 0
rule 8..16777216/0(match): pass in on vtnet0: (tos 0x0, ttl 52, id 32739, offset 0, flags [DF], proto TCP (6), length 60)
67.197.156.119.45486 > 132.148.77.28.80: Flags [S], cksum 0x5b67 (correct), seq 2464105159, win 29200, options [mss 1460,sackOK,TS val 64109860 ecr 0,nop,wscale 7], length 0
rule 8..16777216/0(match): pass in on vtnet0: (tos 0x0, ttl 52, id 55497, offset 0, flags [DF], proto TCP (6), length 60)
67.197.156.119.45488 > 132.148.77.28.80: Flags [S], cksum 0x832f (correct), seq 3354322413, win 29200, options [mss 1460,sackOK,TS val 64109860 ecr 0,nop,wscale 7], length 0
rule 9..16777216/0(match): pass out on lo0: (tos 0x0, ttl 64, id 2474, offset 0, flags [DF], proto TCP (6), length 60)
127.0.0.1.60189 > 127.0.0.1.5556: Flags [S], cksum 0xfe30 (incorrect -> 0xe2c0), seq 1589892785, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 34141386 ecr 0], length 0
rule 5..16777216/0(match): pass in on lo0: (tos 0x0, ttl 64, id 2474, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->3310)!)
127.0.0.1.60189 > 127.0.0.1.5556: Flags [S], cksum 0xfe30 (incorrect -> 0xe2c0), seq 1589892785, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 34141386 ecr 0], length 0
10 packets captured
14 packets received by filter
0 packets dropped by kernel
Я добавил новые строки между информацией о пакете для лучшей читаемости . В первом дампе вы заметите, что «правило 2» блокирует пакеты, что происходит только в самом первом запросе после того, как восходящий сервер запускается заново.
Что дает? Вы также заметите, что эти заблокированные пакеты находятся в интерфейсе обратной связи, но они исходят и отправляются на публичный IP-адрес. Я думаю, что их не следует использовать NAT, потому что они re не на интерфейсе vtnet0. Тем не менее, почему последующие запросы используют другой путь для облегчения связи от nginx к вышестоящему серверу?
Я нашел исправление, которое заключалось в изменении следующей строки из моего pf.conf:
передать журнал $ iface proto tcp в порт $ public_ip {ssh http} сохранить состояние
кому:
передать протокол протоколов tcp в порт $ public_ip {ssh http} сохранить состояние
Я удалил часть в $ iface , поэтому брандмауэр позволит передавать даже пакеты на порт 80 $ public_ip в кольцевой проверке интерфейс. У меня также есть умеренные опасения по поводу последствий ослабления этого правила для безопасности, которые незначительны только потому, что я больше не полностью понимаю, как работает трафик между этими различными сетевыми интерфейсами.
На данный момент я даже не уверен если проблема связана с моим брандмауэром или с nginx, просто когда брандмауэр отключен, проблема исчезает.
Обратите внимание, что nginx - это proxy_pass , отправляющий запросы в трех разных серверных блоках к http://127.0.0.1: [port] , где порт - один из 5555, 5556 или 5557.
После долгих исследований правильное исправление моей проблемы, вместо изменения упомянутой мной строки, заключалось в полном удалении этой строки и добавлении пропуска набора для lo0 в блок Options файла pf.conf (после макросов и перед правилами фильтрации пакетов). Это полностью запрещает pf касаться интерфейса loopback.
Что касается ip не 127.x.x.x, появляющихся на устройстве loopback, у меня есть теория. Как предложил @Richard Smith, я запустил netstat -rn и заметил следующие две строки:
Destination Gateway Flags Netif
132.148.77.28 link#1 UHS lo0
132.148.77.28/32 link#1 U vtnet0
Я немного покопался и обнаружил, что эти две записи были добавлены как псевдоним через ifconfig ] к первому интерфейсу Ethernet, указанному в выводе ifconfig: vtnet0. Таким образом, кажется, что трафик действительно может быть направлен через кольцевую проверку на 132.148.77.28, как показано на этом маршруте. Это просто означает, что он будет использовать vtnet0 в качестве шлюза для этого. Теперь я не уверен, что произошло ли то, что когда он достиг vtnet0 в качестве шлюза, он получил NAT по правилу pf, но тогда я не уверен, почему tcpdump все еще показывает старый интерфейс (lo0), из которого Оно пришло. Мне все еще кажется странным, что вышестоящий сервер, который прослушивает 127.0.0.1, решил открыть порт на 132.148.77.28, чтобы попытаться ответить прокси-серверу в первый раз, а затем при последующих запросах просто использовать 127.0.0.1. 0.1 и пусть обратный прокси «опустится до своего уровня» для связи. Моя теория состоит в том, что алгоритм маршрутизации «запомнил», что предыдущий путь был плохим (т.е. был заблокирован), и поэтому попробовал другой подход. Я не буду отмечать свой ответ как принятый, потому что мне действительно нужен профессионал с хорошо обученным глазом, чтобы проверить, имеют ли мои легковесные теории хоть какую-то силу.