Solucionar problemas de conectividade TCP/IP

Experimente nosso Agente virtual. Ele pode ajudar a identificar e corrigir rapidamente os problemas comuns de replicação do Active Directory.

Aplica-se a: Versões com suporte do cliente Windows e do Windows Server

Este artigo fornece um guia completo para solucionar erros de conectividade TCP/IP.

Sintomas e análise

Você pode encontrar problemas de conectividade no nível do aplicativo ou pode enfrentar erros de tempo limite. Confira alguns cenários comuns:

• Conectividade do aplicativo com um servidor de banco de dados
• Erros de tempo limite do SQL
• Erros de tempo limite do aplicativo BizTalk
• Falhas no protocolo RDP
• Falhas de acesso ao compartilhamento de arquivos
• Conectividade geral

Quando houver suspeita de um problema relacionado à rede, recomendamos coletar uma captura de pacote de rede. Essa captura pode ser filtrada para identificar a conexão TCP problemática e determinar a causa da falha.

Durante o processo de solução de problemas, você pode encontrar um TCP RESET na captura de rede, o que pode indicar um problema de rede.

Introdução do TCP

O TCP é caracterizado como um protocolo confiável e orientado a conexão. Ele garante confiabilidade através do processo de handshake. Uma sessão TCP é iniciada com um handshake de três vias, seguido pela transferência de dados, e termina com um fechamento de quatro vias.

• Um fechamento de quatro vias, em que o remetente e o destinatário concordam em fechar a sessão, é conhecido como fechamento normal. Isso é identificado pelo sinalizador FIN no cabeçalho TCP sendo definido como 1.

• Após o fechamento de quatro vias, a máquina aguarda 4 minutos (por padrão) antes de liberar a porta. Isso é denominado como TIME_WAIT estado. Durante esse estado TIME_WAIT, todos os pacotes pendentes para a conexão TCP podem ser processados. Depois que o estado TIME_WAIT for concluído, todos os recursos alocados para a conexão serão liberados.

• Uma redefinição de TCP é um fechamento abrupto de sessão, causando a liberação imediata de recursos alocados e o apagamento de todas as informações de conexão. Isso é identificado pelo sinalizador RESET no cabeçalho TCP que está sendo definido como 1. Um rastreamento de rede coletado simultaneamente na origem e no destino ajuda a determinar o fluxo do tráfego e identificar o ponto de falha.

As seções a seguir descrevem cenários nos quais um RESET pode ocorrer.

Perda de pacotes pela rede

Quando um peer TCP envia pacotes sem receber uma resposta, o peer retransmite os dados. Se ainda não houver resposta, a sessão será encerrada com um ACK RESET, indicando que o aplicativo reconhece os dados trocados, mas fecha a conexão devido à perda de pacotes.

Rastreamentos de rede simultâneos na origem e no destino podem verificar esse comportamento. No lado da origem, você pode ver os pacotes retransmitidos. No lado do destino, esses pacotes não estão presentes. Esse cenário indica que um dispositivo de rede entre a origem e o destino está descartando os pacotes.

Cenário 1: Perda de pacotes durante o handshake TCP inicial

Se o handshake TCP inicial falhar devido a quedas de pacotes, o pacote TCP SYN será retransmitido três vezes por padrão.

Observação

O número de vezes que o pacote TCP SYN é retransmitido pode ser diferente com base no sistema operacional. Isso é determinado pelo valor Max SYN Retransmissions nos parâmetros TCP Global , que podem ser visualizados usando o comando netsh int tcp show global.

Suponha que uma máquina de origem com o endereço IP 10.10.10.1 esteja se conectando ao destino com o endereço IP 10.10.10.2 pela porta TCP 445. Veja a seguir uma captura de tela do rastreamento de rede coletado no computador de origem, que mostra o handshake TCP inicial em que o pacote TCP SYN é enviado e retransmitido pela origem, pois nenhuma resposta foi recebida do destino.

A mesma conversa TCP vista no rastreamento de rede coletado no destino mostra que nenhum dos pacotes acima foi recebido pelo destino. Isso implica que o pacote TCP SYN foi descartado na rede intermediária.

Se os pacotes TCP SYN estiverem chegando ao destino, mas o destino não responder, verifique se a porta TCP à qual está conectada está no estado LISTENING na máquina de destino. Isso pode ser verificado na saída do comando netstat -anob.

Se a porta estiver escutando e ainda não houver resposta, pode haver uma queda na WFP (Plataforma de Filtragem do Windows).

Cenário 2: Perda de pacotes durante a transferência de dados após o estabelecimento da conexão TCP

Em um cenário em que um pacote de dados enviado após o estabelecimento da conexão TCP é descartado pela rede, o TCP retransmite o pacote cinco vezes por padrão.

Suponha que uma máquina de origem com o endereço IP 192.168.1.62 tenha estabelecido uma conexão com a máquina de destino com o endereço IP 192.168.1.2 na porta TCP 445. A máquina de origem está enviando dados (pacote SMB Negotiate) que estão sendo retransmitidos cinco vezes, conforme visto abaixo. Depois de nenhuma resposta do destino, a máquina de origem está enviando um ACK-RST para fechar essa conexão TCP.

Fonte 192.168.1.62 traço lateral:

Você não veria nenhum dos pacotes acima chegando ao destino.

Você precisa envolver sua equipe de rede interna para investigar os diferentes saltos entre a origem e o destino e verificar se algum dos saltos está potencialmente causando quedas de pacotes.

Parâmetro incorreto no cabeçalho TCP

Esse comportamento ocorre quando dispositivos intermediários na rede modificam pacotes, fazendo com que o TCP na extremidade receptora os rejeite. Por exemplo, o número de sequência TCP pode ser alterado ou os pacotes podem ser reproduzidos por um dispositivo intermediário com um número de sequência TCP modificado.

Um rastreamento de rede simultâneo na origem e no destino pode ajudar a identificar quaisquer modificações nos cabeçalhos TCP.

Comece comparando os rastreamentos de origem e destino para detectar quaisquer alterações nos pacotes ou a presença de novos pacotes chegando ao destino em nome da origem.

Nesses casos, recomendamos procurar assistência da equipe de rede interna para identificar quaisquer dispositivos que estejam modificando ou reproduzindo pacotes para o destino. Os culpados comuns incluem dispositivos Riverbed ou aceleradores WAN.

Redefinição no nível do aplicativo

Quando você determinar que as redefinições não são devido a quedas de pacotes, parâmetros incorretos ou modificações de pacotes (conforme identificado por meio de rastreamentos de rede), você pode concluir que o problema é uma redefinição no nível do aplicativo.

As redefinições no nível do aplicativo são caracterizadas pelo sinalizador ACK (Confirmação) sendo definido como 1 junto com o sinalizador Redefinir (R). Isso indica que o servidor confirma o recebimento do pacote, mas não aceita a conexão por algum motivo. Esse problema geralmente ocorre quando o aplicativo que recebe o pacote encontra algo inaceitável nos dados.

Nas capturas de tela abaixo, você pode observar que os pacotes na origem e no destino são idênticos, sem modificações ou quedas. No entanto, uma redefinição explícita é enviada pelo destino para a origem.

Rastreamento do lado da origem:

Rastreamento do lado do destino:

Um pacote TCP sinalizado ACK+RST também pode ocorrer quando um pacote TCP SYN é enviado. O pacote TCP SYN é iniciado pela máquina de origem para estabelecer uma conexão em uma porta específica. No entanto, se o servidor de destino não quiser aceitar o pacote por qualquer motivo, o servidor responderá com um pacote ACK+RST.

Nesses casos, é essencial investigar o aplicativo que está causando a redefinição (identificado por números de porta) para entender por que a conexão está sendo redefinida.

Observação

As informações acima referem-se a redefinições de uma perspectiva TCP e não UDP. O UDP é um protocolo sem conexão e os pacotes são enviados de forma não confiável. Consequentemente, retransmissões ou redefinições não são observadas ao usar o UDP como protocolo de transporte. No entanto, o UDP utiliza o ICMP como um protocolo de relatório de erros. Quando um pacote UDP é enviado para uma porta que não está listada no destino, o destino responderá imediatamente com uma mensagem ICMP "Host de destino inacessível: porta inacessível".

10.10.10.1  10.10.10.2  UDP UDP:SrcPort=49875,DstPort=3343
 
10.10.10.2  10.10.10.1  ICMP    ICMP:Destination Unreachable Message, Port Unreachable,10.10.10.2:3343

Durante a solução de problemas de conectividade TCP/IP, você pode observar no rastreamento de rede que uma máquina recebe pacotes, mas não responde a eles. Isso pode indicar uma queda na pilha de rede do servidor de destino.

Para determinar se o Firewall do Windows local está descartando o pacote, habilite a auditoria para a WFP (Plataforma de Filtragem do Windows) no computador usando o comando a seguir.

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable

Em seguida, você pode examinar os logs de eventos de segurança para identificar uma queda de pacote em uma porta TCP e endereço IP específicos, juntamente com uma ID de filtro WFP associada.

Em seguida, execute o comando netsh wfp show state que gera um arquivo wfpstate.xml .

Você pode abrir esse arquivo usando o Bloco de Notas e filtrar a ID encontrada nos logs de eventos (por exemplo, 2944008 no evento de exemplo). O resultado revela o nome da regra de firewall associado à ID do filtro que está bloqueando a conexão.