Como podem os endereços IPV4 privados passarem do iptables NAT (tcp RST, FIN)

Question

Eu tenho um roteador executando uma tradução NAT simples usando o iptables iptables -t nat -o -j MASQUERADE

Isso funciona bem quase todo o tempo, exceto por um caso particular em que alguns pacotes TCP RST e FIN estão deixando o roteador não-NAT.

Neste cenário, configurei 1 ou 2 computadores clientes transmitindo vídeo em Flash (por exemplo, www.nasa.gov/ntv) No roteador eu, em seguida, derrubar e restabelecer a interface pública (que é um modem) Como esperado, os streams do Flash param. Depois que a conexão for restabelecida e eu tentar atualizar as páginas do Flash, vejo alguns pacotes TCP RST e [FIN, ACK] deixando a interface pública (suponho que o Flash tente recuperar seu fluxo).

Eu não sei como esses pacotes podem deixar o roteador não-NAT

    

Answer 1

Obrigado pela dica. Eu era exatamente o que eu precisava para me colocar no caminho certo.

A causa raiz foi o encaminhamento não filtrado entre lan e interface pública. Quando a interface pública foi demolida, as entradas do conntrack foram apagadas. Os clientes então tentaram reavivar suas conexões e acabaram enviando pacotes RST e FIN. Como o NAT é configurado apenas em conexões NOVAS, esses pacotes deixam o roteador inalterado.

Eu tive que alterar minha regra de encaminhamento para permitir que pacotes NOVOS, ESTABELECIDOS e RELACIONADOS fossem encaminhados da LAN privada.

    

Answer 2

Eliminar o [RST, ACK] e [FIN, ACK] não funcionará. Existem muitos aplicativos, como upload de ftp, que simplesmente não conseguirão concluir a transferência do FTP. Os comentários do gscott são o método correto, mas um requisito adicional é necessário. Você deve torná-los rigorosos, aplicando a política

iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -P INPUT DROP

Com isso, você precisa especificar todas as suas regras, ou os pacotes serão descartados.

    

Answer 3

Isso pode ser um bug no alvo do iptables MASQUERADE. Em seu cenário, parece que você tem os seguintes eventos coincidentes:

• os pacotes pertencem a uma conexão já presente na tabela de estados
• a entrada de estado inclui uma fonte de endereço NAT que não pertence mais ao sistema

Assim, uma tentativa de mascarar o pacote pode falhar devido a um endereço inválido para ser mascarado, portanto, o pacote está sendo roteado inalterado.

O comportamento esperado do destino MASQUERADE seria ter as entradas de estado correspondentes desmarcadas quando uma interface fica inativa ou o endereço é alterado, portanto, essa situação não deveria ter ocorrido. Mas tem havido um bug antigo relatado para o iptables , que soa como poderia desencadear um tipo similar de comportamento.

Para solucionar mais, anote o endereço IP público do roteador, reproduza o problema e observe a tabela de estados usando egrep 12.34.56.78 /proc/net/ip_conntrack (onde 12.34.56.78 é o endereço IP que você anotou anteriormente). Se você obtiver linhas conntrack com o endereço IP antigo apesar do endereço da interface pública ter mudado, provavelmente você está correndo para um bug do iptables - considere atualizar seu kernel / iptables e reportar o problema para a equipe do netfilter.

    

Answer 4

FYI

Uma outra maneira de impedir que os pacotes ACK, ACK e RST, que entram na rede pública, os bloqueiem na cadeia de saída

iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL RST,ACK -j DROP
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL FIN,ACK -j DROP 
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL FIN -j DROP
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL RST -j DROP

Isso me ajudou a impedir pacotes falsos.