Solicitações de conexão interrompidas com SYN_SENT, após algumas tentativas

Question

Mudamos de escritório e configuramos a infraestrutura de LAN / WAN no novo local.

Quando inicio conexões SSH com meu servidor (que está na nuvem, não na LAN), ele funciona bem para as primeiras 3 ou 4 solicitações em intervalos curtos (como 4 chamadas em 5 segundos), outras conexões ficam suspensas em SYN_SENT status. Mais tarde pedidos todos pendurar com SYN_SENT até o que parece ser um tempo limite. Depois disso, funcionará novamente algumas vezes.

Nenhuma alteração foi feita no servidor e diferentes clientes locais se comportam dessa maneira. Então, acho que a diferença está na infraestrutura de TI, não nos dois pontos finais.

Quais possíveis explicações existem para esse comportamento? Onde devo procurar uma solução?

Nós usamos um firewall Zyxel ZyWall que tivemos que redefinir - isso tem algum filtro que poderia explicar esse comportamento?

    

Answer 1

As regras do iptables no servidor tinham uma cadeia de regras "anti ssh bruteforce" que usa o módulo "recente" para descartar conexões depois que 4 tentativas foram feitas dentro de 1 minuto. Essa regra tinha uma exceção na cadeia INPUT , para permitir todo o ssh do nosso IP de face. Conforme nos movemos, o IP do rosto mudou e a regra teve que ser adaptada. Para referência, é assim que eu fiz isso

Listar todas as regras do iptables

# iptables -L --line-numbers

Observe a regra de aceitação na cadeia INPUT , que foi configurada para aceitar todas as conexões ssh de nosso endereço IP anterior (anterior) e a regra anti bruteforce que desconecta conexões ssh após várias tentativas na cadeia SSH_CHECK :

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
...
14   ACCEPT     tcp  --  old.myISP.com      anywhere tcp dpt:ssh
...
Chain SSH_CHECK (1 references)
num  target     prot opt source               destination
...
3    DROP       all  --  anywhere             anywhere            recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: RECENT_SSH side: source

Editando as regras em /etc/iptables.rules

Alterar

-A INPUT -s 123.45.67.8/32 -p tcp -m tcp --dport 22 -j ACCEPT

para

-A INPUT -s 111.222.33.44 -p tcp -m tcp --dport 22 -j ACCEPT

em que 111.222.33.44 é o novo IP da face. E leia nas regras adaptadas:

 # iptables-restore < /etc/iptables.rules