Почему iptables отклоняет второй и последующие фрагменты разрешенного пакета?


9

У меня есть два хоста, которые пытаются установить соединение IPSec друг с другом. Для этого им нужно общаться по UDP-портам 500 и 4500, поэтому я открыл их в брандмауэрах на обоих концах (показано в соответствующей части):

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m udp -p udp --dport 500 -j ACCEPT
-A INPUT -m udp -p udp --dport 4500 -j ACCEPT
#.....
-A INPUT -j REJECT --reject-with icmp6-port-unreachable

Однако обмен ключами никогда не удается. Каждая сторона пытается повторно передавать UDP-пакеты снова и снова, никогда не услышав ответа, пока они, наконец, не сдадутся.

Я начал tcpdumpс одного конца и заметил, что пакет UDP был фрагментирован и что порт ICMP, недоступный, возвращался после того, как поступил второй фрагмент.

Пример такого неудачного обмена (продезинфицированный для вашей защиты):

04:00:43.311572 IP6 (hlim 51, next-header Fragment (44) payload length: 1240) 2001:db8::be6b:d879 > 2001:db8:f:608::2: frag (0x5efa507c:0|1232) ipsec-nat-t > ipsec-nat-t: NONESP-encap: isakmp 2.0 msgid 00000001 cookie 55fa7f39522011ef->f8259707aad5f995: child_sa  ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1596/ip 1220)
04:00:43.311597 IP6 (hlim 51, next-header Fragment (44) payload length: 384) 2001:db8::be6b:d879 > 2001:db8:f:608::2: frag (0x5efa507c:1232|376)
04:00:43.311722 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 432) 2001:db8:f:608::2 > 2001:db8::be6b:d879: [icmp6 sum ok] ICMP6, destination unreachable, length 432, unreachable port[|icmp6]

Брандмауэр записал следующее в отношении этого пакета:

Aug 26 04:00:43 grummle kernel: iptables: REJECT IN=eth0 OUT= MAC=############### SRC=2001:0db8:0000:0000:0000:0000:be6b:d879 DST=2001:0db8:000f:0608:0000:0000:0000:0002 LEN=424 TC=0 HOPLIMIT=51 FLOWLBL=0 OPT ( FRAG:1232 ID:5efa507c ) PROTO=UDP

У меня сложилось впечатление, что Linux автоматически собирает фрагменты перед передачей их в фильтр пакетов. Так почему же эти фрагменты не собираются повторно и поэтому второй фрагмент впоследствии отклоняется?


В качестве примечания, IME также необходимо разрешить ESP:iptables -A INPUT -p esp -j ACCEPT
fukawi2

@ fukawi2 Да, но это не относится к этому вопросу.
Майкл Хэмптон

Ответы:


14

Код сетевого фильтра только повторно собирает фрагменты для вас перед фильтрацией пакетов, если ваши правила брандмауэра используют отслеживание соединений (то есть правило брандмауэра с состоянием и использует -m conntrackили устарело -m state) или NAT. В противном случае все фрагменты обрабатываются отдельно, и вы получаете такие проблемы.

Это делает решение проблемы простым и очевидным (в любом случае, оглядываясь назад). Просто добавьте отслеживание соединения в соответствующие правила брандмауэра.

-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m conntrack --ctstate NEW -m udp -p udp --dport 500 -j ACCEPT
-A INPUT -m conntrack --ctstate NEW -m udp -p udp --dport 4500 -j ACCEPT

Или для более старых систем Linux (например, RHEL 5 и более ранних):

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 500 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 4500 -j ACCEPT
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.