Todas as conexões desta rede ficam presas no estado SYN_RECV, conexões da minha casa ou telefone são apropriadamente ESTABELECIDAS

Question

Meu servidor (um linode VPS) de repente começou a expirar em todas as solicitações de ontem.

Sou muito inexperiente em redes e adoraria aprender um processo para depurar esses problemas de conectividade.

O que me confunde é que ontem, algumas pessoas (meu telefone, eu em casa, amigos em casa) podem acessar o site de forma consistente e vejo com netstat que uma conexão foi estabelecida. Eu desabilitei o Firewalls e configurei o iptables para aceitar todas as conexões para descartar quaisquer regras automáticas estranhas que colocassem o nosso IP na lista negra. Eu não tenho certeza se o seu relevante, mas um traceroute da rede local expira - traceroute de algumas máquinas fora do meu servidor.

Confirmei que várias configurações estão corretas, comparando com as configurações do meu servidor de desenvolvimento que estão funcionando corretamente.

Os arquivos a seguir correspondem ao meu ambiente de desenvolvimento (exceto para seus respectivos endereços IP):

/etc/hosts 
/etc/hosts.allow
/etc/hosts.deny
/etc/networking/interfaces 
ifconfig

O Apache está escutando na porta 80 e a configuração é exatamente igual ao meu servidor em funcionamento.

# server that doesn't work:
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      22008/apache2
tcp        0      0 69.164.201.172:80       71.56.137.10:57487      SYN_RECV    -

# server that does work
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      3334/apache2
tcp        0      0 72.14.189.46:80         71.56.137.10:57490      ESTABLISHED 20931/apache2

Minha tentativa de entender

Sempre que carrego a página uma vez, netstat -an | grep :80 revela todas as conexões no estado SYN_RECV.

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 69.164.201.172:80       71.56.137.10:56657      SYN_RECV
tcp        0      0 69.164.201.172:80       71.56.137.10:56669      SYN_RECV
tcp        0      0 69.164.201.172:80       71.56.137.10:56671      SYN_RECV

Portanto, o SYN_RECV significa que o servidor está aguardando que um ACK seja enviado de volta do cliente.
Como faço para depurar se um ACK está sendo enviado de volta? Como faço para depurar onde esta comunicação está falhando?

Veja como é um tcpdump quando tento carregar a página uma vez.

Na pasta abaixo, meu servidor está constantemente enviando pacotes para o cliente e não obtém resposta.

O que isso significa? Que o cliente não está recebendo a resposta? Ou talvez eu esteja engolindo a resposta em algum lugar no servidor? Como eu sei diminuir ainda mais o culpado?

tcpdump -i eth0 -n -tttt port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
2011-05-25 20:12:54.627417 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2011-05-25 20:12:54.627512 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:54.814463 IP 69.164.201.172.80 > 71.56.137.10.57157: Flags [S.], seq 604630211, ack 496040070, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:55.214482 IP 69.164.201.172.80 > 71.56.137.10.57158: Flags [S.], seq 998358186, ack 2224730755, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:57.624737 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2011-05-25 20:12:57.624793 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:59.014477 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:03.618790 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,nop,sackOK], length 0
2011-05-25 20:13:03.618866 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:05.014514 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:17.014504 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0

tcpdump para servidor funcional

Ao examinar o tcpdump para o meu servidor funcional, vejo a quarta e a última comunicação entre o servidor e o cliente.

00:00:00.000000 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [S], seq 34114118s [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
00:00:00.000110 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [S.], seq 2454858 win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
00:00:00.061827 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [.], ack 1, win 100:00:00.004292 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [P.], seq 1:597, ngth 596
00:00:00.000074 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], ack 597, win00:00:00.493990 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], seq 1:2921, ngth 2920
00:00:00.000024 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [P.], seq 2921:30, length 98
00:00:00.065135 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [.], ack 3019, wi00:00:00.034766 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [P.], seq 597:12925, length 699
00:00:00.000035 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], ack 1296, wi00:00:00.000457 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [P.], seq 3019:328, length 211
00:00:00.019196 IP 71.56.137.10.57262 > 72.14.189.46.80: Flags [S], seq 10674886s [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0

Quaisquer sugestões, explicações ou comentários seriam muito apreciados para que eu possa entender o TCP um pouco mais e espero ser um pouco mais útil na próxima vez que eu precisar depurar um problema como este.

Obrigado!

    

Answer 1

Para este olho cansado, parece que há algum tipo de problema de roteamento próximo ao servidor em questão. Os pacotes chegam ao longo de um caminho, mas parecem partir por um caminho diferente e algo com estado está nesse caminho e descartando os pacotes estranhos "ACK sem SYN".

Eu tive isso comigo uma vez. O que acabou sendo o caso foi que o servidor tinha uma má máscara de rede, então quando o tráfego de fora da sub-rede chegava, ele emitia uma solicitação ARP para obter o endereço MAC do nó. Infelizmente para mim, tanto o roteador quanto nosso balanceador de carga foram habilitados para o Proxy-ARP, e o balanceador de carga foi um pouco mais rápido no gatilho que o roteador. Assim, os pacotes SYN chegaram através do roteador, mas estavam tentando deixar a sub-rede através do balanceador de carga. Como o LB não tinha uma conexão para o pacote ACk, ele caiu no chão.

No seu caso, algumas rotas de rastreamento criteriosas podem iluminar os problemas do caminho da rede. Do servidor afetado, tente rastrear os IPs que causam o problema e faça o mesmo a partir desses mesmos IPs. Se você está conseguindo caminhos diferentes, pode ser onde está.

    

Answer 2

só teve o mesmo problema.

No meu caso, isso foi uma configuração incorreta da rede.

O servidor

foi configurado com 10.0.1.111 255.255.254.0 e o cliente foi configurado com 10.0.0.15 255.255.255.0. Alterar a máscara de rede no lado do cliente para / 23 resolveu meu problema.

Espero que isso possa ajudar.

considera o tcpdump