Compartilhar via

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

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

Este artigo foi criado para ajudá-lo a solucionar problemas de comunicação TCP/IP.

Ferramentas de solução de problemas

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 de 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 detalhe os dispositivos que estão no caminho para a área afetada. Especificamente, observe os seguintes dispositivos:

  • Firewalls
  • IPS (Sistemas de prevenção/proteção contra intrusões)
  • DPI (inspeção profunda de pacotes)
  • Aceleradores de 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: faça ping no endereço IP local do computador

Tente fazer ping no endereço IP local do computador.

Se o nó não puder fazer ping em seu IP local, a pilha local não está funcionando. Observe 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 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 verificação de investigação.

Para solucionar esse problema, verifique se o adaptador de rede relata a conectividade. Verifique se o adaptador de rede está conectado e se a porta do comutador em que o nó está conectado não está em um estado de erro. Você pode alterar cabos, portas de switch 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 geralmente ocorre devido a uma corrupção na pilha. Utilize as etapas de solução de problemas a seguir:

  1. Verifique os bits mais recentes no nó (TCP/IP, NDIS, AFD, Winsock e assim por diante).

  2. 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

  3. Reinicie o nó.

  4. Restaure as configurações de rede após a reinicialização. Essa operação só funcionará se os nomes das interfaces não tiverem sido alterados ou se o script for atualizado para usar os novos nomes.

    netsh -f C:\netConfig.txt

  5. Desinstale ou reinstale o driver do adaptador de rede, conforme apropriado.

  6. Verifique e remova drivers de filtro de terceiros (por exemplo, antivírus).

  7. Tente iniciar o computador no modo de segurança com rede. Se o modo de segurança com rede funcionar, execute um processo de "inicialização limpa" desativando todos os aplicativos e serviços de terceiros no MSConfig e reativando-os um por um até que o problema retorne. Você pode então entrar em contato com o fornecedor para obter suporte.

    1. Se nenhum desses itens for bem-sucedido, o problema provavelmente será um dano 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 que funcionava anteriormente. Detectar a causa raiz da corrupção pode ser difícil e extremamente demorado. Mesmo que a corrupção seja encontrada, saber o que a causou é ainda mais desafiador. Modificar a chave do registro corrompida manualmente coloca o nó em um estado sem suporte. Assim, recomendamos que o cliente restaure ou recarregue o nó para corrigir o dano.

Se o NSCI falhar na verificação de sondagem (ponto de exclamação amarelo), isso não indica necessariamente um problema de conectividade. Certifique-se de que a comunicação típica esteja ocorrendo como deveria.

  • Nesse caso, a investigação deve se concentrar especificamente no motivo pelo qual o NCSI está falhando nas 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, pois 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 fazer ping ou telnet para nós na mesma sub-rede ou segmento de rede, isso confirmará que a conectividade externa está funcionando. Mais testes ainda são necessários para entender se existe um problema básico de conectividade.

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

  1. O erro de host de destino inalcançável significa que as solicitações ARP enviadas pelo nó não estão recebendo uma resposta.

  2. Reúna um rastreamento bilateral dos nós entre os quais você está testando. Certifique-se de que a solicitação ARP enviada pelo nó de origem chegue ao nó de destino e que o nó de destino responda adequadamente. Essa resposta deve ser vista novamente no rastreamento de origem. Se esse processo falhar, o problema provavelmente será um erro de configuração ou outros problemas que afetam a infraestrutura.

    Causas possíveis podem ser:

    1. VLANs incorretas ou incompatíveis.
    2. Uma configuração incorreta de porta de comutador (tronco versus porta de acesso).
    3. Outros problemas de hardware.

  3. O erro de tempo limite da solicitação significa que a solicitação ARP obteve uma resposta, mas a solicitação de eco ICMP enviada pelo nó não está recebendo uma resposta de eco ICMP. Isso, por si só, não indica um problema. O tráfego ICMP pode ser bloqueado pelo software de rede ou firewall nos nós. Pode ser útil desativar os perfis de firewall (Windows) ou desabilitá-los por meio do método compatível do fornecedor do firewall para testar o ICMP.

    1. Telnet e PsPing são mais adequados para teste. 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 funcionará. 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 bilateral netsh netconnection para solucionar problemas adicionais.

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

Quando o nó puder realizar ping em seu gateway padrão, a conectividade externa (como conectividade off-box) será possível no nó de origem. Mais testes ainda são necessários para entender se existe um problema básico de conectividade. Se o nó não puder fazer ping ou Telnet para seu gateway padrão, isso significa que as respostas ICMP estão desabilitadas no roteador.

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

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

  1. Tente fazer Telnet ou PsPing para a porta específica em que 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ê terá que entrar em contato com o fornecedor do aplicativo para ajudar a investigar por que o aplicativo não se conecta.

    Observação

    O fornecedor do aplicativo pode ser a Microsoft se o problema for uma falha na conexão com um compartilhamento, por exemplo. Nessas situações, seria útil fazer o rastreamento do cenário netsh netconnection de dois lados para coletar informações adicionais e ajudar a verificar se não há problemas na pilha de rede.

  2. Se a conexão com a porta específica não for bem-sucedida:

    1. Certifique-se de que a porta esteja 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: desative 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 limpa" do nó usando o MSConfig e, em seguida, habilitando aplicativos e serviços de terceiros um por um até que o problema ocorra novamente.
    5. Ao reproduzir a tentativa de conexão, você deve executar um rastreamento de cenário de netsh netconnection da origem para o nó de destino afetado. Um SDP de rede também seria benéfico.

  3. Se o nó não puder fazer ping, Telnet ou PsPing para outros nós na sub-rede de destino, o problema provavelmente poderá estar relacionado à infraestrutura. Novamente, o ICMP pode estar bloqueado no ambiente. Portanto, verifique a conectividade usando telnet ou PsPing para se conectar a portas de escuta conhecidas. Neste ponto, um rastreamento de rede de duas pontas é necessário para mostrar onde a perda de pacotes 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 comuns e soluções

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

Esse problema ocorre porque os dados estã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 nas portas TCP e UDP no computador local.
O estado de uma boa conexão TCP é estabelecido com zero (0) bytes nas filas de envio e recebimento. Se os dados estiverem bloqueados em qualquer fila ou se o estado for irregular, a conexão provavelmente estará com falha. Caso contrário, você provavelmente está enfrentando um atraso de rede ou software no nível do usuário.

Longos tempos de conexão 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 as entradas usadas com frequência na parte superior do arquivo e as entradas #PRE na 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 comando nbtstat -R para atualizar o cache de nome local imediatamente.

Ocorreu o erro de sistema 53

O erro de 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 o nome e o mapeamento de endereço IP estão disponíveis no arquivo Lmhosts ou no banco de dados WINS. Se todos os elementos TCP/IP parecerem estar 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 NetBIOS não está resolvendo o nome ou o endereço IP incorreto 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, tente um dos outros nomes de computador exclusivos exibidos pelo 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 em seu 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 requer que o gateway padrão esteja no formato "192.168.<y>.<z>" porque a parte do 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 o problema.

Pré-requisitos

  1. O TSS deve ser executado por contas com privilégios de administrador no sistema local e o EULA deve ser aceito (depois que o EULA for aceito, o TSS não solicitará novamente).
  2. 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, depois que a janela do PowerShell especificada na qual o TSS é executado for fechada, a permissão atribuída para o nível de processo também voltará ao estado configurado anteriormente.

Reúna informações importantes antes de entrar em contato com o suporte da Microsoft

  1. Baixe o TSS em todos os nós e descompacte-o na pasta C:\tss .

  2. Abra a pasta C:\tss em um prompt de comando do PowerShell com privilégios elevados.

  3. Inicie os rastreamentos no servidor de origem e de destino usando o seguinte cmdlet:

    TSS.ps1 -Scenario NET_General

  4. Aceite o EULA se os rastreamentos forem executados pela primeira vez no servidor de origem ou de destino.

  5. Permitir gravação (PSR ou vídeo).

  6. Reproduza o problema antes de inserir 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.

  7. Insira Y para concluir a coleta 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.

Referência