TCP RST aleatório em determinados sites, o que está acontecendo?

Question

Versão resumida: uma máquina do Windows Server 2012 na minha rede está recebendo TCP RSTs persistentes, porém intermitentes, ao se conectar a determinados sites. Não sei de onde eles estão vindo. Confira o log do wireshark para minha análise & perguntas.

Versão longa:

Nós executamos um proxy web em cache em um de nossos servidores para atender nosso pequeno escritório. Um colega relatou ter recebido muitos erros de "Redefinição de conexão" ou "A página não pode ser exibida" ao se conectar a determinados sites, mas essa atualização geralmente corrige isso.

Eu verifiquei o comportamento do navegador e, mais diretamente, tentei um navegador não-proxy no próprio servidor. Mas pings & traceroutes para sites problemáticos não mostram nenhum problema, os problemas pareciam estar limitados a conexões tcp.

Em seguida, criei um script para testar os sites afetados, enviando-lhes solicitações HTTP HEAD diretamente por meio de cURL & verificando quantas vezes eles conseguem. Um teste típico se parece com isto: (isto é não-rodado, rodando diretamente no servidor ruim)

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, somente cerca de 60% das solicitações são bem-sucedidas, o restante não retorna nada, com um código de erro curl de: "erro cURL (56): Falha ao receber dados do peer" O mau comportamento é consistente para os sites que eu testei (nenhum site já "melhorou") e é bastante persistente, estou resolvendo problemas há uma semana, e colegas de trabalho relatam que o problema está lá há meses, aparentemente. / p>

Eu testei o script de solicitação HEAD em outras máquinas em nossa rede: sem problemas, todas as conexões passam por todos os sites da minha lista de teste. Então eu configurei um proxy na minha área de trabalho pessoal, e quando eu executo as solicitações HEAD do servidor problemático, todas as conexões passam. Então, 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 nossos sites de intranet (192.168.x.x) descarta conexões.
• Nenhum site ipv6 que testei descarta conexões. (Nós somos dual-stack)
• Apenas uma pequena minoria de sites ipv4 da Internet descarta conexões.
• Todo site que usa o cloudflare como um CDN (que testei) descarta conexões. (mas o problema não parece ser exclusivo dos sites cloudflare)

Esse ângulo não estava se tornando nada útil, então, em seguida, instalei wireshark para ver o que estava acontecendo quando uma solicitação falhou. Um pedido HEAD com falha é assim: (screenshot maior aqui: link )

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 que eu estou lendo isso (me corrija se eu estiver errado, isso não é realmente minha área) é isso:

• Abrimos uma conexão tcp para o servidor da Web
• ACK do servidor web
• O pedido HTTP HEAD é enviado
• Existe um pacote RST, marcado como do IP do servidor web, que mata a conexão.
• O servidor da Web envia ACK
• Servidor Web (tenta) para responder à solicitação HEAD com dados HTTP válidos (a resposta de 951 bytes contém o cabeçalho HTTP correto)
• O servidor Web retransmite (várias vezes por vários segundos) a resposta HTTP válida, mas não pode ser bem-sucedida porque 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 não gerou o RST, o que diabos aconteceu?

Coisas que tentei que não tiveram efeito:

• Desativando o agrupamento de NIC
• Alterando o adaptador de rede (o NIC de substituição estava funcionando)
• Atribuindo um ip estático
• Desativando o ipv6.
• Desativando quadros jumbo.
• Conectando o servidor diretamente ao nosso modem uma noite, ignorando nossos switches & roteador.
• 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 um servidor de arquivos, mas há um apache e um par de DBs)
• Bater a cabeça na mesa (repetidamente)

Suspeito que algo no servidor esteja gerando os pacotes RST, mas, para minha vida, não consigo encontrá-lo. Eu me sinto como se soubesse: por que é só esse servidor? OU porque apenas alguns sites? ajudaria muito. Enquanto eu ainda estou curioso, estou cada vez mais inclinado a nuke de órbita & começar de novo.

Idéias / Sugestões?

-Obrigado

    

Answer 1

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 notados quando foi implantado pela primeira vez. O mais grave deles era que muitos firewalls deixavam pacotes ou retornavam um RST ao receber um pacote SYN com o conjunto de bits ECN.

Como resultado, a maioria dos sistemas operacionais desabilitou 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 corrigiram seus firewalls .

Até o Windows Server 2012 ser lançado. Microsoft ativado ECN por padrão começando com esta versão do sistema operacional.

Infelizmente, ninguém recentemente fez qualquer teste significativo das respostas dos sites da Internet à ECN, por isso é difícil avaliar se os problemas observados no início dos anos 2000 ainda existem, mas eu suspeito strongmente que eles são e que o seu tráfego é , pelo menos em parte do tempo, passando por esse equipamento.

Após habilitar ECN na minha área de trabalho e disparar o Wireshark, levei apenas alguns segundos até obter um exemplo de host do qual obtive um RST para um pacote com SYN e ECN, embora a maioria dos hosts pareça funcionar bem . Talvez eu vá escanear a internet ...

Você pode tentar desabilitar o ECN no seu servidor para ver se o problema desaparece. Isso também tornará você incapaz de usar o DCTCP, mas em um escritório pequeno é altamente improvável que você esteja fazendo isso ou tenha alguma necessidade de fazê-lo.

netsh int tcp set global ecncapability=disabled