Mudamos os escritórios e configuramos a infraestrutura 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 no status SYN_SENT. Todas as solicitações posteriores ficam suspensas 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. Portanto, acho que a diferença está na infraestrutura de TI, não nos dois terminais.
Que possíveis explicações existem para esse comportamento? Onde devo procurar uma solução?
Usamos um firewall Zyxel ZyWall que tivemos que redefinir - ele possui algum filtro que possa explicar esse comportamento?
Responder1
As regras do iptables no servidor tinham uma cadeia de regras "anti ssh bruteforce" que usa o módulo "recente" para interromper conexões após 4 tentativas em 1 minuto. Essa regra teve uma exceção na INPUTcadeia, para permitir todo ssh do nosso IP facial. À medida que avançamos, o IP facial mudou e a regra teve que ser adaptada. Para referência, foi assim que eu fiz isso
Listar todas as regras do iptables
# iptables -L --line-numbers
Observe a regra de aceitação na INPUTcadeia, que foi definida para aceitar todas as conexões ssh do nosso endereço IP facial (anterior) e a regra anti-força bruta que descarta conexões ssh após várias tentativas na SSH_CHECKcadeia:
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
Mudar
-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
onde 111.222.33.44 é o novo IP facial. E leia nas regras adaptadas:
# iptables-restore < /etc/iptables.rules