Qual comando testa a conectividade de dois ou mais pontos de rede?

Avançar para o conteúdo principal

Não há mais suporte para esse navegador.

Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.

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

• Artigo
• 10/12/2022
• 12 minutos para o fim da leitura

Neste artigo

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

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

• Firewalls
• IPS (Sistemas de Proteção contra Intrusões/Prevenção)
• DPI (inspeção profunda de pacotes)
• 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: Executar ping no endereço IP local do computador

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

Se o nó não puder executar ping em seu IP local, a pilha local não está 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 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 comutador 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 ocorre devido a uma corrupção na pilha. Use as seguintes etapas de solução de problemas:

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

2. Redefina o IP e o 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 da interface não foram 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" desabilitando todos os aplicativos e serviços de terceiros no MSConfig e habilitando-os novamente um por um até que o problema retorne. Em seguida, entre 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 isso é ainda mais desafiador. Modificar a chave do 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 a NSCI falhar na verificação de investigação (ponto de exclamação amarelo), isso não indicará necessariamente um problema de conectividade. Verifique se a comunicação típica está 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 executar ping ou telnet para nós na mesma sub-rede ou segmento de rede, isso confirmará que a conectividade externa está funcionando. Testes adicionais ainda são necessários para entender se existe um problema básico de conectividade.

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

1. Erro inacessível do host de destino significa que as solicitações ARP enviadas pelo nó não estão recebendo uma resposta.

2. Reúna um rastreamento de dois lados dos nós entre os que você está testando. Verifique se a solicitação ARP enviada pelo nó de origem atinge o nó de destino e se o nó de destino responde adequadamente. Essa resposta deve ser vista novamente no rastreamento de origem. Se esse processo falhar, o problema provavelmente será uma configuração incorreta ou outros problemas que afetam a infraestrutura.

   As possíveis causas podem ser:

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

3. O erro de solicitação de tempo limite significa que a solicitação ARP recebeu uma resposta, mas a Solicitação de Eco 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 útil desativar os perfis de firewall (Windows) ou desabilitá-los por meio do método com suporte 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 estará funcionando. Continue testando a conectividade básica.
   3. Se a etapa 1 não for bem-sucedida netsh netconnection (e se os perfis de firewall estiverem desabilitados), reúna um rastreamento de cenário de dois lados para solucionar mais problemas.

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

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

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

Se o nó de origem puder executar ping, 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.

1. Tente usar 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 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 ao se conectar a um compartilhamento, por exemplo. Nessas situações, seria útil usar o rastreamento de cenário netsh netconnection de dois lados para coletar informações adicionais e ajudá-lo 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. 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, contate 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 MSConfig e, em seguida, habilitando aplicativos e serviços de terceiros um a um até que o problema ocorra novamente.
   5. Ao reproduzir 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.

3. Se o nó não puder executar ping, 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 conhecidas. Neste ponto, um rastreamento de rede de dois lados é 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 e soluções comuns

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

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 comando netstat -a 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 ao ter zero (0) bytes nas filas de envio e recebimento. Se os dados são bloqueados em uma fila ou se o estado é irregular, a conexão provavelmente está com falha. Caso contrário, você provavelmente está enfrentando um atraso de software de rede ou de nível de 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 #PRE opção.

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

Erro 53 do sistema

O erro 53 do sistema 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 parecem estar instalados corretamente, use ping o comando junto com o computador remoto para verificar se seu 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 por nbtstat. nbtstat -n Se o nome usado por um computador remoto for o mesmo que o nome exibido pelo 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 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 formato "192.168.< Y, não é?>< 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 o problema.

Pré-requisitos

1. O TSSv2 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 TSSv2 não solicitará novamente).
2. Recomendamos a política de execução do RemoteSigned PowerShell do computador local.

Observação

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

• Defina RemoteSigned a 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 se aplicam apenas à sessão atual do PowerShell, depois que a janela do PowerShell fornecida na qual o TSSv2 é executado é fechada, a permissão atribuída para o nível de processo também voltará ao estado configurado anteriormente.

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

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

2. Abra a pasta C:\tss_tool de 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:

   TSSv2.ps1 -Start -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:\MSDATA , que pode ser carregada no workspace para análise.

Referência

• Solucionar problemas de conectividade TCP/IP
• Solucionar problemas de esgotamento de porta
• Solucionar problemas de RPC (Chamada de Procedimento Remoto)
• Coletar dados usando o Monitor de Rede
• Falha ao abrir propriedades TCP/IP do adaptador de rede
• SMB de host direto sobre TCP/IP
• Configurar a rede TCP/IP enquanto o NetBIOS está desativado
• O tráfego TCP é interrompido
• O intervalo de portas dinâmicas padrão para TCP/IP foi alterado
• As propriedades TCP/IP são revertidas para as configurações padrão

Qual comando testar a conectividade entre dois ou mais pontos de rede?

Qual comando que serve para testar a conectividade entre equipamentos de uma rede?

Como testa rede pelo CMD?

Como fazer testes de rede?