Por que o iptables rejeita o segundo fragmento e os subsequentes de um pacote permitido?

8

Eu tenho dois hosts que estão tentando configurar uma conexão IPSec entre si. Para isso, eles precisam se comunicar nas portas UDP 500 e 4500, então eu os abri nos firewalls em ambas as extremidades (mostrado na parte relevante):

-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

No entanto, a troca de chaves nunca é bem-sucedida. Cada lado continua tentando retransmitir os pacotes UDP repetidamente, nunca ouvindo uma resposta, até que eles finalmente desistem.

Eu iniciei tcpdump em uma ponta e observei que o pacote UDP estava sendo fragmentado e que uma porta ICMP inacessível estava sendo retornada depois que o segundo fragmento chegou.

Um exemplo de uma troca falhada (higienizada para sua proteção):

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]

O firewall registrou o seguinte em relação a este pacote:

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

Fiquei com a impressão de que o Linux reagrupou automaticamente os fragmentos antes de passá-los para o filtro de pacotes. Então, por que esses fragmentos não estão sendo reagrupados e, portanto, o segundo fragmento subsequentemente rejeitado?

    
por Michael Hampton 26.08.2013 / 06:53

1 resposta

14

O código do netfilter apenas remonta fragmentos para você antes da filtragem de pacotes if suas regras de firewall usam o controle de conexão (ou seja, a regra de firewall é stateful e usa -m conntrack ou o obsoleto -m state ) ou NAT. Caso contrário, todos os fragmentos serão processados separadamente e você terá problemas como este.

Isso torna a resolução do problema fácil e óbvia (em retrospecto, de qualquer forma). Basta adicionar o rastreamento de conexão às regras de firewall em questão.

-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

Ou para sistemas Linux mais antigos (por exemplo, RHEL 5 e anterior):

-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
    
por 26.08.2013 / 06:53