Não é possível conectar-se à porta 80, todas as conexões estão presas SYN_RECV

Question

Não consigo me conectar ao servidor na porta 22 ou 80. Quando executo o netstat, vejo algumas conexões, todas presas no SYN_RECV. Googling revelou principalmente perguntas sobre o DDOS. Como há muito poucas conexões, isso parece improvável (embora eu esteja em um host compartilhado (slicehost)).

O que mais poderia estar causando isso?

    

Answer 1

Verifique se o seu /etc/hosts.deny não está corrompido . Isso aconteceu comigo uma vez e causou problemas extremamente bizarros com os serviços de netowkr pendurados.

Verifique suas regras de firewall ( sudo /sbin/iptables -nvL ). Você pode ter seu firewall configurado para permitir conexões de entrada, mas bloquear conexões de saída, fazendo com que as conexões de entrada sejam interrompidas.

Você pode se conectar a essas portas na própria máquina? Por exemplo, se você estiver conectado ao sistema, executar telnet localhost 80 faz alguma coisa?

Algo interessante em arquivos de log como /var/log/secure ou /var/log/messages ?

    

Answer 2

A única vez que vi isso antes, foi uma questão estranha de tempo. As conexões estavam ficando presas no estado semi-aberto (o que significa SYN_RECV) e penduradas. O que acabou sendo o problema foi duas vezes:

1. O servidor tinha uma máscara de rede incorreta (/ 16 em vez de / 24)
2. Havia dois dispositivos na sub-rede do servidor que emitem pacotes ARP de proxy

O que estava acontecendo era que a conexão inicial chega ao servidor. Ele responde, mas antes disso, ele precisa descobrir o endereço MAC do alvo. Devido à máscara de rede configurada incorretamente, ele tenta ARP para o endereço IP. O roteador então emitiu um proxy-arp dizendo que tinha esse endereço, então o servidor enviou o pacote SYN / ACK. Entre o momento em que o pacote foi enviado e quando chegou a hora de responder ao ACK do cliente, nosso load-balancer também emitiu um pacote Proxy ARP. O servidor atualizou devidamente sua tabela ARP. Então, quando ele respondeu ao pacote ACK, o fez através de um dispositivo completamente diferente. O dispositivo era stateful e não tinha uma conexão para este pacote ACK, então ele caiu no chão. Assim, a conexão parecia meio aberta no final do cliente.

    

Answer 3

Não sei qual foi o problema, mas meu provedor de hospedagem moveu minha VM para uma nova máquina e o problema foi resolvido.

    

Answer 4

Na maioria das vezes, o firewall é um culpado. Do service iptables stop e service ip6tables stop .

Se o serviço de parada não funcionar, faça o download do iptable.

iptables --flush