Diretrizes de solução de problemas de comunicação TCP/IP

Artigo
12/26/2023

Experimente nosso Agente Virtual – ele pode ajudá-lo a identificar e corrigir rapidamente problemas comuns de replicação do Active Directory.

Este artigo foi projetado para ajudar você a solucionar problemas de comunicação TCP/IP.

Ferramentas de solução de problema

O comando ping é útil para testar a conectividade básica. No entanto, você não deve confiar nele para provar a conectividade geral. Telnet e PsPing são mais úteis, pelos seguintes motivos:

Essas ferramentas podem testar a conectividade com a camada do aplicativo usando TCP ou UDP (somente PsPing) como o protocolo de transporte.
Você pode especificar qual porta será usada. Portanto, você pode navegar por portas abertas em um firewall.
Você pode se conectar a qualquer porta de "escuta" no nó de destino para verificar o acesso à porta de um aplicativo específico.

Lista de verificação de solução de problemas

Etapa 1: capturar um diagrama de rede

Capture um diagrama de rede que detalha os dispositivos que estão no caminho para a área afetada. Especificamente, observe os seguintes dispositivos:

Firewalls
IPS (Proteção contra Intrusões/Sistemas de Prevenção)
DPI (inspeção de pacotes profundos)
Aceleradores da WAN

O diagrama pode ajudá-lo a visualizar e identificar onde procurar a causa do problema.

Etapa 2: Rastreamentos de rede

Os rastreamentos de rede são úteis para ver o que está ocorrendo no nível da rede quando o problema ocorre.

Etapa 3: pingar o endereço IP local do computador

Tente pingar o endereço IP local do computador.

Se o nó não puder pingar seu IP local, a pilha local não estará funcionando. Observe todas as mensagens de erro exibidas.

Se você receber um erro de Falha Geral , esse erro significa que não há interfaces válidas para processar a solicitação. Esse problema pode ser causado por um problema de hardware ou um problema de pilha.

Verifique se você vê um caractere "X" vermelho ou um ponto de exclamação amarelo no ícone Conexão de Rede na bandeja do sistema. Um X vermelho indica que o Windows não está detectando uma conexão de rede. Um ponto de exclamação amarelo indica que o NSCI (Indicador de Status de Conexão de Rede) falhou em uma investigação marcar.

Para solucionar esse problema, verifique se o adaptador de rede relata conectividade. Verifique se o adaptador de rede está conectado e se a porta de comutador em que o nó está conectado não está em um estado de erro. Você pode alterar cabos, alternar portas e adaptadores de rede para restringir onde esse problema ocorre. No entanto, em última análise, o problema está fora do sistema operacional. Para investigar mais, entre em contato com os fornecedores de hardware.

Um problema também pode ocorrer entre o driver de rede e o Windows. Esse problema normalmente é devido a uma corrupção na pilha. Use as seguintes etapas de solução de problemas:

Verifique se os bits mais recentes no nó (TCP/IP, NDIS, AFD, Winsock e assim por diante).
Redefina IP e Winsock executando os comandos a seguir. Faça backup de toda a configuração de rede.
```
netsh -c interface dump > C:\netConfig.txt
netsh int ip reset
netsh winsock reset
```
Reinicie o nó.
Restaure as configurações de rede após a reinicialização. Essa operação só funcionará se os nomes da interface não tiverem sido alterados ou o script for atualizado para usar os novos nomes.
```
netsh -f C:\netConfig.txt
```
Desinstale ou reinstale o driver do adaptador de rede, conforme apropriado.
Verifique e remova drivers de filtro de terceiros (por exemplo, antivírus).
Tente iniciar o computador no Modo de Segurança com Rede. Se o Modo Seguro com Rede funcionar, execute um processo de "inicialização limpo" desabilitando todos os aplicativos e serviços de terceiros no MSConfig e, em seguida, reabilitando-os um por um até que o problema retorne. Em seguida, você pode entrar em contato com o fornecedor para obter suporte.
1. Se nenhum desses itens for bem-sucedido, o problema provavelmente será uma corrupção no registro.
2. Se você tiver uma cópia de backup do registro (como um backup físico ou um ponto de restauração do sistema), poderá tentar restaurar o nó para uma configuração de trabalho anterior. Capturar a causa raiz da corrupção pode ser difícil e extremamente demorado. Mesmo que a corrupção seja encontrada, saber o que causou é ainda mais desafiador. Modificar a chave de registro corrompida manualmente coloca o nó em um estado sem suporte. Como tal, recomendamos que o cliente restaure ou recarregue o nó para corrigir a corrupção.

Se o NSCI falhar em sua investigação marcar (ponto de exclamação amarelo), isso não indica necessariamente um problema de conectividade. Verifique se a comunicação típica está ocorrendo como deveria.

Se assim for, a investigação deve se concentrar especificamente em por que o NCSI está falhando em suas verificações de investigação. Os detalhes para isso são abordados em um tópico separado.
Caso contrário, investigue os problemas de conectividade primeiro porque isso provavelmente será corrigido depois que a conectividade for restaurada.

Etapa 4: Solucionar problemas de mensagens de erro que ocorrem durante o teste de ping ou telnet

Se o nó puder pingar ou telnet em nós na mesma sub-rede ou segmento de rede, isso confirmará que a conectividade externa está funcionando. Outros testes ainda são necessários para entender se existe um problema básico de conectividade.

Se o nó não puder ping/telnet para nós no mesmo segmento de sub-rede/rede. Observe todas as mensagens de erro exibidas.

Erro inacessível do host de destino significa que as solicitações do ARP enviadas pelo nó não estão recebendo uma resposta.
Reúna um rastreamento de dois lados dos nós que você está testando entre eles. Verifique se a solicitação ARP enviada pelo nó de origem atinge o nó de destino e se o nó de destino responde de acordo. Essa resposta deve ser vista de volta no rastreamento de origem. Se esse processo falhar, o problema provavelmente será uma configuração incorreta ou outras questões que afetam a infraestrutura.

Possíveis causas podem ser:
1. VLANs incorretas ou incompatíveis.
2. Uma configuração incorreta da porta de comutador (porta de tronco versus acesso).
3. Outros problemas de hardware.
O erro de tempo limite de solicitação significa que a solicitação ARP recebeu uma resposta, mas a Solicitação de Eco do ICMP enviada pelo nó não está recebendo uma resposta de eco ICMP. Isso, sozinho, não indica um problema. O tráfego ICMP pode ser bloqueado pela rede ou pelo software de firewall nos nós. Pode ser benéfico desativar os perfis de firewall (Windows) ou desabilitá-los por meio do método compatível do fornecedor de firewall para testar o ICMP.
1. Telnet e PsPing são mais adequados para testes. Execute Telnet ou PsPing do nó de origem para o nó de destino em uma porta de escuta (como 445).
2. Se a etapa 1 for bem-sucedida, a conectividade externa estará funcionando. Continue testando a conectividade básica.
3. Se a etapa 1 não for bem-sucedida (e se os perfis de firewall estiverem desabilitados), reúna um rastreamento de cenário de dois lados netsh netconnection para solucionar problemas ainda mais.

Etapa 5: Ping ou Telnet para o gateway padrão

Quando o nó pode pingar seu gateway padrão, a conectividade externa (como conectividade off-box) é possível a partir do nó de origem. Outros testes ainda seriam necessários para entender se existe um problema básico de conectividade. Se o nó não puder pingar ou Telnet no gateway padrão, isso significa que as respostas do ICMP serão desabilitadas no roteador.

Etapa 6: verificar problemas que afetam o nó de destino específico

Se o nó de origem puder pingar, Telnet ou PsPing para outros nós na sub-rede de destino, a conectividade básica e o roteamento dentro da infraestrutura estão funcionando. Esse resultado aponta para um problema que afeta o nó de destino específico.

Tente Telnet ou PsPing para a porta específica na qual o aplicativo está escutando (por exemplo, porta TCP 445 para SMB). Se a conexão for bem-sucedida, a conectividade básica no nível do aplicativo poderá ser confirmada. Nessa situação, você precisará entrar em contato com o fornecedor de aplicativos para ajudar a investigar por que o aplicativo não se conecta.

Observação

O fornecedor de aplicativos pode ser a Microsoft se o problema for uma falha na conexão com um compartilhamento, por exemplo. Nessas situações, seria útil usar o rastreamento de cenário netconnection netconnection de dois lados para coletar informações adicionais e ajudá-lo a verificar se não há problemas na pilha de rede.
Se a conexão com a porta específica não for bem-sucedida:
1. Verifique se a porta está em um estado de "escuta":
  CMD: netstat -nato | findstr :<port>
  Powershell: Get-NetTcpConnection -LocalPort <port>
2. Desabilite temporariamente todos os perfis de firewall. (Observação: desabilite apenas os perfis. Não desabilite o serviço.)
  Se isso for bem-sucedido, o firewall deverá ser reconfigurado para permitir o tráfego do aplicativo em sua porta específica.
3. Remova todos os aplicativos de terceiros um de cada vez e teste entre cada remoção.
  Se isso for bem-sucedido, entre em contato com o fornecedor do software problemático.
4. Experimente o modo de segurança com rede.
  Se isso for bem-sucedido, isole a causa executando uma "inicialização limpo" do nó usando o MSConfig e habilitando aplicativos e serviços de terceiros um por um até que o problema se repita.
5. Quando você reproduz a tentativa de conexão, você deve executar um rastreamento de cenário netsh netconnection da origem para o nó de destino afetado. Um SDP de rede também seria benéfico.
Se o nó não puder pingar, Telnet ou PsPing para outros nós na sub-rede de destino, o problema provavelmente poderá estar relacionado à infraestrutura. Novamente, o ICMP pode ser bloqueado dentro do ambiente. Portanto, verifique a conectividade usando Telnet ou PsPing para se conectar a portas de escuta conhecida. Neste ponto, um rastreamento de rede de dois lados é necessário para mostrar onde a perda de pacote está ocorrendo na rede. Verifique se ambos os rastreamentos estão em execução antes de tentar o teste de conectividade para que o problema seja capturado.

Problemas e soluções comuns

A conexão TCP/IP com um host parece ter sido interrompida

Esse problema ocorre porque os dados são bloqueados em filas TCP e UDP ou há problemas de atraso de software no nível da rede ou do usuário.

Para solucionar esse problema, use o netstat -a comando para mostrar o status de todas as atividades em portas TCP e UDP no computador local.
O estado de uma boa conexão TCP é estabelecido ao ter zero (0) bytes nas filas de envio e recebimento. Se os dados forem bloqueados em uma fila ou se o estado estiver irregular, a conexão provavelmente será falha. Caso contrário, você provavelmente está enfrentando um atraso de rede ou software no nível do usuário.

Tempos de conexão longos ao usar Lmhosts para resolução de nomes

Esse problema ocorre porque o arquivo Lmhosts é analisado sequencialmente para localizar entradas sem a opção #PRE.

Para solucionar esse problema, coloque entradas usadas com frequência perto da parte superior do arquivo e as entradas #PRE perto da parte inferior. Se uma entrada for adicionada ao final de um arquivo Lmhosts grande, marque a entrada em Lmhosts como uma entrada pré-carregada usando a opção #PRE. Em seguida, execute o nbtstat -R comando para atualizar o cache de nome local imediatamente.

Erro do sistema 53 ocorreu

O erro do sistema 53 será retornado se a resolução de nomes falhar para um nome de computador específico quando o net use comando for usado.

Se o computador estiver na sub-rede local, verifique se o nome está escrito corretamente e se o computador de destino também está executando TCP/IP. Se o computador não estiver na sub-rede local, verifique se seu nome e mapeamento de endereço IP estão disponíveis no arquivo Lmhosts ou no banco de dados WINS. Se todos os elementos TCP/IP aparecerem instalados corretamente, use o ping comando junto com o computador remoto para verificar se o software TCP/IP está funcionando.

Não é possível se conectar a um servidor específico

Esse problema ocorre porque a resolução de nomes do NetBIOS não está resolvendo o nome ou o endereço IP errado está sendo resolvido.

Para solucionar esse problema, use o nbtstat -n comando no servidor para determinar quais nomes o servidor registrou na rede. O nome do computador ao qual você está tentando se conectar deve estar na lista exibida. Se o nome não estiver listado, experimente um dos outros nomes de computador exclusivos exibidos por nbtstat. Se o nome usado por um computador remoto for o mesmo que o nome exibido pelo nbtstat -n comando, verifique se o computador remoto tem uma entrada para o nome do servidor que está no servidor WINS ou no arquivo Lmhosts.

Não é possível adicionar um gateway padrão

Esse problema ocorre porque o endereço IP do gateway padrão não está na mesma ID de rede IP que seu endereço IP.

Para solucionar esse problema, determine se o gateway padrão está localizado na mesma rede lógica que o adaptador de rede do computador comparando o endereço IP do gateway padrão com as IDs de rede de qualquer um dos adaptadores de rede do computador.

Por exemplo, um computador tem um único adaptador de rede configurado com um endereço IP de 192.168.0.33 e uma máscara de sub-rede de 255.255.0.0. Isso exige que o gateway padrão seja do formulário "192.168.<y>.<z>" porque a parte da ID de rede da interface IP é 192.168.0.0.

Coleta de dados

Antes de entrar em contato com o suporte da Microsoft, você pode coletar informações sobre seu problema.

Pré-requisitos

O TSS deve ser executado por contas com privilégios de administrador no sistema local e o EULA deve ser aceito (uma vez que o EULA é aceito, o TSS não solicitará novamente).
Recomendamos a política de execução do PowerShell do computador RemoteSigned local.

Observação

Se a política de execução atual do PowerShell não permitir a execução do TSS, execute as seguintes ações:

Defina a RemoteSigned política de execução para o nível do processo executando o cmdlet PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned.
Para verificar se a alteração entra em vigor, execute o cmdlet PS C:\> Get-ExecutionPolicy -List.
Como as permissões de nível de processo só se aplicam à sessão atual do PowerShell, uma vez que a janela determinada do PowerShell em que o TSS é executado é fechada, a permissão atribuída para o nível do processo também voltará para o estado configurado anteriormente.

Coletar informações importantes antes de entrar em contato com o suporte da Microsoft

Baixe o TSS em todos os nós e descompacte-o na pasta C:\tss .
Abra a pasta C:\tss de um prompt de comando do PowerShell elevado.
Inicie os rastreamentos no servidor de origem e destino usando o seguinte cmdlet:
```
TSS.ps1 -Scenario NET_General
```
Aceite o EULA se os rastreamentos forem executados pela primeira vez na origem ou no servidor de destino.
Permitir gravação (PSR ou vídeo).
Reproduza o problema antes de entrar no Y.

Observação

Se você coletar logs no cliente e no servidor, aguarde essa mensagem em ambos os nós antes de reproduzir o problema.
Insira Y para concluir a coleção de logs depois que o problema for reproduzido.

Os rastreamentos serão armazenados em um arquivo zip na pasta C:\MS_DATA , que pode ser carregado no workspace para análise.