Por que o iptables descarta / log mesmo se o pacote apropriado deve ser aceito?

Question

Estou montando um servidor rodando o Debian Jessie com alguns aplicativos como o iptables firewall, o fail2ban, o openvpn, o apache, ...

O firewall iptables é configurado no caminho, que registra todos os pacotes que são descartados. Um pequeno trecho da configuração do iptables:

...
-A INPUT -m comment --comment "003 accept related established rules IPv4" -m state --state RELATED,ESTABLISHED -j ACCEPT
...
-A INPUT -p tcp -m multiport --dports 1194 -m comment --comment "303 allow incoming OpenVPN" -m state --state NEW -j ACCEPT
...
-A INPUT -m comment --comment "900 IPv4 log dropped input chain" -j LOG --log-prefix "[IPTABLES INPUT IPv4] DROP " --log-level 6
-A INPUT -m comment --comment "910 IPv4 deny all other input requests" -j DROP

O OpenVPN (que usa a porta 1194) funciona bem. Posso conectar, usar a conexão e trabalhar por horas, até o momento em que preciso transferir uma quantidade maior de dados. Neste ponto, algumas linhas como as seguintes aparecem no log:

Mar 02 20:39:27 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress> DST=<ServerIPAddress> LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=20713 DF PROTO=TCP SPT=61941 DPT=1194 WINDOW=3040 RES=0x00 ACK URGP=0
Mar 02 20:39:27 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress> DST=<ServerIPAddress> LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=20718 DF PROTO=TCP SPT=61941 DPT=1194 WINDOW=3040 RES=0x00 ACK URGP=0 
Mar 02 20:39:27 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress> DST=<ServerIPAddress> LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=20719 DF PROTO=TCP SPT=61941 DPT=1194 WINDOW=3040 RES=0x00 ACK URGP=0 

[Esses logs são coletados do fail2ban e o servidor fecha a conexão com meu computador local.]

P: Por que esses pacotes são descartados (e registrados)? Isso significa: por que esses pacotes não são processados pela regra 'RELATED, ESTABLISHED'?

O que eu fiz até agora: ler documentação, pensar sobre o problema ;-), verificar as regras várias vezes, pesquisei na Internet - mas sem nenhum resultado.

Editar: talvez isso seja importante: a lista DROP criada pelo fail2ban tem cerca de 500 entradas.

Edit: Eu quero saber o motivo (é por isso que estou usando 'Por que' na minha pergunta). Não estou interessado em soluções alternativas.

Editar: Esse comportamento não está limitado ao OpenVPN, usar outros protocolos (por exemplo, ssh) tem o mesmo problema.

Editar: Para dar uma impressão, dê uma olhada na captura de tela do wireshark: o pacote em destaque foi descartado / registrado - todos os outros pacotes da captura de tela não.

Aqui está o log apropriado:

Mar 03 10:16:23 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress>.117 DST=<ServerIPAddress>.116 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=11550 DF PROTO=TCP SPT=63526 DPT=1194 WINDOW=32038 RES=0x00 ACK URGP=0 

Eu usei o ID do IP (11550) para encontrar o pacote no wireshark. E este é o único pacote IP com este ID.

Editar: o IP do servidor é um IP fixo. Meu endereço IP atribuído dinamicamente não foi alterado durante o teste. As conexões são iniciadas pelo computador local em direção ao servidor. A configuração é a seguinte:

=================      ===================      ===============
| LocalComputer | ---- | NAT Router .117 | ---- | Server .116 |
=================      ===================      ===============
   Private IP            Dynam. Assigned            Fixed IP
                       but fixed during test

    

Answer 1

O rastreador de conexão não rastreia apenas se os pacotes são da mesma conexão, mas também verifica se há algum tempo (como ACK atrasado ou SEQ tarde demais).

É possível ativar o registro do rastreador de conexão com:

echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid

Isso me mostrou que todos os pacotes descartados e registrados são do tipo:

nf_ct_tcp: ACK is under the lower bound (possible overly delayed ACK) ...

Existe uma discussão onde encontrei estas sugestões.

Atualmente, não sei por que isso acontece, mas isso pode ser outra pergunta ...

    

Answer 2

Como você tem essas iptables entradas de log e elas não correspondem às suas regras RELATED,ESTABLISHED , o rastreador de conexão está relatando vê-las como o início de novas sessões não relacionadas a algo anterior. Normalmente (mas nem sempre) isso pode acontecer quando a sessão passou mais tempo ociosa do que o tempo limite do rastreador de conexão. Outros dispositivos NAT entre seus terminais podem ter expirado e gerado novos números de portas ou seu outro terminal pode ter seu endereço IP alterado (possível em redes baseadas em DHCP de ISPs), portanto, não é necessariamente o rastreador de conexão de terminal que está com falha .

Existem três opções que lembram,

1. Habilite o ping keepalive dentro da configuração do OpenVPN. No mínimo, tente ping 10 . Se preferir, e dependendo de como o seu cliente / servidor está configurado, você pode preferir keepalive 10 60 . Consulte a página de manual para obter detalhes realmente importantes. (Isso não resolverá o problema se o par de endereço IP / porta de um terminal for alterado.)

2. Desative a configuração fail2ban que corresponde ao tráfego do OpenVPN em 1194 / tcp.

3. Garanta que você evite imprimir uma mensagem de log de iptables para o tráfego do OpenVPN em 1194 / tcp, portanto fail2ban não tem nada para acionar.