У меня есть хост KVM с виртуальным pfSense, который должен передавать трафик NAT от других виртуальных ящиков за общедоступным IP-адресом pfSense. PfSense подключен к двум мостам: vmbr0 подключает его к общедоступному Интернету. vmbr1 - это мост фильтрации VLAN, который соединяет его с другими гостевыми системами виртуализации на том же хосте и с некоторыми туннелями VXLAN с другими хостами. (только одна VLAN была фактически отображена на pfSense, и локальное соединение в этой VLAN было безупречным).
По какой-то причине я не понимаю, эта настройка странно взаимодействует с отслеживанием соединений.
В качестве основного теста подключения я могу ping прочее, а также curl http://google.com из коробки pfSense.
Но вот где это становится странным:
На второй виртуальной машине, подключенной к блоку pfSense, я пытаюсь wget http://google.com (curl не установлен), но он не может успешно подключиться к целевому хосту.
Я вижу, что NAT на блоке pfSense работает и пакет пересылается:
root@KVM_HOST ~ # tcpdump -i vmbr0 host 172.217.22.78
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:04:23.680846 IP $PFSENSE_PUBLIC_IP.26151 > fra15s17-in-f78.1e100.net.http: Flags [S], seq 1239804912, win 64240, options [mss 1460,sackOK,TS val 2535739136 ecr 0,nop,wscale 7], length 0
22:04:24.702640 IP $PFSENSE_PUBLIC_IP.26151 > fra15s17-in-f78.1e100.net.http: Flags [S], seq 1239804912, win 64240, options [mss 1460,sackOK,TS val 2535740158 ecr 0,nop,wscale 7], length 0
Я вижу на хосте KVM, что пакет отбрасывается в этом правиле iptables:
pkts bytes target prot opt in out source destination
10434 627K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
Я подтвердил это iptables -t raw -A PREROUTING -d google.com -j TRACE, который показывает, что это правило соответствует.
Когда я пробую тот же wget с другой виртуальной машины на другом хосте KVM (подключенном через туннель VXLAN), он работает:
root@KVM_HOST ~ # tcpdump -i vmbr0 host 172.217.22.78
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:06:08.794751 IP $PFSENSE_PUBLIC_IP.14173 > fra15s17-in-f14.1e100.net.http: Flags [S], seq 2190375059, win 64240, options [mss 1460,sackOK,TS val 714013620 ecr 0,nop,wscale 7], length 0
22:06:08.799797 IP fra15s17-in-f14.1e100.net.http > $PFSENSE_PUBLIC_IP.14173: Flags [S.], seq 2844348518, ack 2190375060, win 60192, options [mss 1380,sackOK,TS val 3763410024 ecr 714013620,nop,wscale 8], length 0
22:06:08.800303 IP $PFSENSE_PUBLIC_IP.14173 > fra15s17-in-f14.1e100.net.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 714013625 ecr 3763410024], length 0
22:06:08.800314 IP $PFSENSE_PUBLIC_IP.14173 > fra15s17-in-f14.1e100.net.http: Flags [P.], seq 1:138, ack 1, win 502, options [nop,nop,TS val 714013625 ecr 3763410024], length 137: HTTP: GET / HTTP/1.1
22:06:08.805315 IP fra15s17-in-f14.1e100.net.http > $PFSENSE_PUBLIC_IP.14173: Flags [.], ack 138, win 240, options [nop,nop,TS val 3763410030 ecr 714013625], length 0
22:06:08.816474 IP fra15s17-in-f14.1e100.net.http > $PFSENSE_PUBLIC_IP.14173: Flags [P.], seq 1:529, ack 138, win 240, options [nop,nop,TS val 3763410041 ecr 714013625], length 528: HTTP: HTTP/1.1 301 Moved Permanently
22:06:08.816972 IP $PFSENSE_PUBLIC_IP.14173 > fra15s17-in-f14.1e100.net.http: Flags [.], ack 529, win 501, options [nop,nop,TS val 714013642 ecr 3763410041], length 0
Соответствуя этому, conntrack -E выявляет абсолютно никаких событий conntrack в первом случае, а все ожидаемые во втором.
Я не вижу никакой разницы между двумя случаями, которая могла бы это объяснить. Я опубликовал анализ двух SYN-пакетов в Wireshark на https://pastebin.com/J6hEA7HB где первый не был отслежен, а второй - нет.
Мое недоумение усугублялось тем, что пинг одного и того же целевого IP-адреса работал в любом сценарии и всегда генерировал события conntrack:
root@KVM_HOST ~ # conntrack -E | grep 172.217.22.78
[NEW] icmp 1 30 src=PFSENSE_PUBLIC_IP dst=172.217.22.78 type=8 code=0 id=11191 [UNREPLIED] src=172.217.22.78 dst=PFSENSE_PUBLIC_IP type=0 code=0 id=11191
[UPDATE] icmp 1 30 src=PFSENSE_PUBLIC_IP dst=172.217.22.78 type=8 code=0 id=11191 src=172.217.22.78 dst=PFSENSE_PUBLIC_IP type=0 code=0 id=11191
Я не понимаю, что я здесь делаю не так, и даже если я что-то делаю не так. Как я могу убедиться, что отслеживание соединений работает надежно?