Versão curta: Uma máquina Windows Server 2012 na minha rede está recebendo RSTs TCP persistentes mas intermitentes ao conectar-se a determinados sites. Não sei de onde eles estão vindo. Confira o log do wireshark para minhas análises e perguntas.
Versão longa:
Executamos um proxy da Web em cache em um de nossos servidores para atender nosso pequeno escritório. Um colega de trabalho relatou ter recebido muitos erros de 'Redefinição de conexão' ou 'Página não pode ser exibida' ao se conectar a determinados sites, mas essa atualização geralmente o corrige.
Eu verifiquei o comportamento do navegador e, em seguida, mais diretamente, tentando um navegador sem proxy no próprio servidor. Mas pings e traceroutes para sites problemáticos não apresentam problemas, os problemas pareciam estar limitados às conexões tcp.
Em seguida, criei um script para testar os sites afetados enviando solicitações HTTP HEAD diretamente via cURL e verificando com que frequência eles são bem-sucedidos. Um teste típico se parece com o seguinte: (isto é sem violação, sendo executado diretamente no servidor inválido)
C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0 Response Code: NULL (0%)
20:22:02: Length: 0 Response Code: NULL (0%)
20:22:22: Length: 0 Response Code: NULL (0%)
20:22:42: Length: 0 Response Code: NULL (0%)
20:23:02: Length: 3173 Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174 Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: 0 Response Code: NULL (28.57%)
20:24:03: Length: 3171 Response Code: HTTP/1.1 302 Moved Temporarily (37.5%)
20:24:23: Length: 3173 Response Code: HTTP/1.1 302 Moved Temporarily (44.44%)
20:24:43: Length: 3172 Response Code: HTTP/1.1 302 Moved Temporarily (50%)
20:25:03: Length: 0 Response Code: NULL (45.45%)
A longo prazo, apenas cerca de 60% das solicitações são bem-sucedidas, as demais não retornam nada, com um código de erro de ondulação de: "erro cURL (56): falha ao receber dados do par" O mau comportamento é consistente para os sites nos quais eu teste (nenhum site "melhorou") e é bastante persistente, já venho solucionando problemas há uma semana e colegas relatam que o problema existe há meses.
Testei o script de solicitação HEAD em outras máquinas da nossa rede: sem problemas, todas as conexões passam por todos os sites da minha lista de testes. Em seguida, configurei um proxy na minha área de trabalho pessoal e, quando executo as solicitações HEAD do servidor problemático, todas as conexões passam. Portanto, seja qual for o problema, é muito específico para este servidor.
Em seguida, tentei isolar quais sites exibem o comportamento de redefinição de conexão:
- Nenhum dos sites da intranet (192.168.xx) descarta conexões.
- Nenhum site ipv6 que eu testei descarta conexões. (Somos pilha dupla)
- Apenas uma pequena minoria de sites IPv4 da Internet descarta conexões.
- Todo site que usa o cloudflare como CDN (que eu testei) descarta conexões. (mas o problema não parece exclusivo dos sites cloudflare)
Esse ângulo não estava se transformando em algo realmente útil, então instalei o wireshark para ver o que estava acontecendo quando uma solicitação falhou. Um pedido HEAD com falha é semelhante a este: (imagem maior aqui: http://imgur.com/TNfRUtX )
127 48.709776000 192.168.1.142 192.33.31.56 TCP 66 52667 > http [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=8960 WS=256 SACK_PERM=1
128 48.728207000 192.33.31.56 192.168.1.142 TCP 66 http > 52667 [SYN, ACK, ECN] Seq=0 Ack=1 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=128
129 48.728255000 192.168.1.142 192.33.31.56 TCP 54 52667 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
130 48.739371000 192.168.1.142 192.33.31.56 HTTP 234 HEAD / HTTP/1.1
131 48.740917000 192.33.31.56 192.168.1.142 TCP 60 http > 52667 [RST] Seq=1 Win=0 Len=0
132 48.757766000 192.33.31.56 192.168.1.142 TCP 60 http > 52667 [ACK] Seq=1 Ack=181 Win=42240 Len=0
133 48.770314000 192.33.31.56 192.168.1.142 TCP 951 [TCP segment of a reassembled PDU]
134 48.807831000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
135 48.859592000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
138 49.400675000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
139 50.121655000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
141 51.564009000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
143 54.452561000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
A maneira como estou lendo isso (me corrija se estiver errado, essa não é minha área) é:
- Abrimos uma conexão tcp com o servidor da web
- ACK do servidor da web
- A solicitação HTTP HEAD é enviada
- Há um pacote RST, marcado como do IP do servidor da web, que mata a conexão.
- Servidor da Web envia ACK
- Servidor da Web (tenta) responder à solicitação HEAD com dados HTTP válidos (a resposta de 951 bytes contém o cabeçalho HTTP correto)
- O servidor da Web retransmite (várias vezes ao longo de vários segundos) a resposta HTTP válida, mas não pode ser bem-sucedida, pois a conexão foi RST
Portanto, se o servidor da web enviou um RST válido, por que ele continua tentando preencher a solicitação? E se o servidor da web não gerou o RST, o que diabos fez?
Coisas que tentei que não surtiram efeito:
- Desativando a equipe da NIC
- Alterando o adaptador de rede (sabia-se que a NIC de substituição estava funcionando)
- Atribuindo um IP estático.
- Desabilitando o ipv6.
- Desativando quadros jumbo.
- Conectando o servidor diretamente ao modem uma noite, ignorando nossos switches e roteadores.
- Desativando o firewall do Windows.
- Redefinindo as configurações de TCP via netsh
- Desativando praticamente todos os outros serviços no servidor. (Usamos principalmente como servidor de arquivos, mas há um apache e alguns bancos de dados)
- Batendo a cabeça na mesa (repetidamente)
Suspeito que algo no servidor esteja gerando os pacotes RST, mas não consigo encontrá-lo por toda a vida. Sinto como se soubesse: por que é apenas esse servidor? OU por que apenas alguns sites? ajudaria muito. Enquanto ainda estou curioso, estou cada vez mais inclinado a sair da órbita e começar de novo.
Idéias / Sugestões?
-Obrigado
Respostas:
Sua captura de pacotes teve algo incomum: os bits ECN foram definidos no pacote SYN de saída.
A notificação explícita de congestionamento é uma extensão do protocolo IP que permite que os hosts reajam mais rapidamente ao congestionamento da rede. Foi introduzido pela primeira vez na Internet há 15 anos, mas havia problemas sérios observados quando foi implantado. O mais sério deles era que muitos firewalls descartavam pacotes ou retornavam um RST ao receber um pacote SYN com os bits de ECN definidos.
Como resultado, a maioria dos sistemas operacionais desativou o ECN por padrão, pelo menos para conexões de saída. Como resultado, suspeito que muitos sites (e fornecedores de firewall!) Simplesmente nunca consertaram seus firewalls .
Até o Windows Server 2012 ser lançado. A Microsoft ativou o ECN por padrão, começando com esta versão do sistema operacional.
Infelizmente, na memória recente, ninguém testou significativamente as respostas dos sites da Internet à ECN, por isso é difícil avaliar se os problemas observados no início dos anos 2000 ainda existem, mas suspeito fortemente que sim e que seu tráfego é, pelo menos, algumas vezes, passando por esse equipamento.
Depois de ativar o ECN na minha área de trabalho e, em seguida, inicializar o Wireshark, foram necessários apenas alguns segundos para eu pegar um exemplo de host a partir do qual eu recebi um RST em um pacote com SYN e ECN definido, embora a maioria dos hosts pareça funcionar bem. Talvez eu mesmo vá pesquisar na Internet ...
Você pode tentar desativar o ECN no servidor para ver se o problema foi resolvido. Isso também tornará você incapaz de usar o DCTCP, mas em um pequeno escritório, é altamente improvável que você esteja fazendo isso ou que precise fazer isso.
fonte