Tutorial de Linux / Diagnostique a conectividade de rede passo a passo

Diagnostique a conectividade no Linux verificando interfaces e endereços, rotas, resolução de nomes, conexões de transporte e respostas de aplicativos nessa ordem. Um único resultado de ping não estabelece se toda uma rede ou serviço web está funcionando.

Para endereços e rotas padrão, veja Endereços IP, DNS e portas. Para uma falha apenas no SSH, também inspecione o host, porta e chaves em SSH e transferência de arquivos, em inglês.

Os exercícios de configuração do sistema usam uma VM convencional Ubuntu 26.04 LTS ou Rocky Linux 9 como ambiente de referência. Contêineres, WSL e outras versões podem diferir na configuração de serviços e pacotes. Prepare a recuperação do console e registre suas versões usando a aula de preparação da máquina virtual, em inglês.

Registre o escopo antes de alterar qualquer coisa

Registre a máquina de origem, o nome de destino, a porta, o horário de início e o erro exato. Compare um site com vários sites, um cliente com outro e IPv4 com IPv6, onde relevante. Observe as diferenças de VPN e proxy e alterações recentes. Antes de reiniciar a rede em um servidor remoto, estabeleça acesso ao console ou outro caminho de gerenciamento.

Inspecione interfaces, endereços e rotas

ip -brief link
ip -brief address
ip route
ip -6 route

O status administrativo UP não prova que o destino esteja acessível. Inspecione informações de link, como LOWER_UP, os endereços esperados e a rota aplicável. Em uma VM, verifique se a interface de rede virtual (NIC) está conectada e se o modo de tradução de endereços de rede (NAT) ou de ponte (bridge) corresponde ao seu plano. Não presuma que a interface seja chamada eth0.

Após obter o endereço IPv4 real do destino, substitua ACTUAL_IPV4_ADDRESS por esse endereço em ip route get ACTUAL_IPV4_ADDRESS. O comando mostra a interface selecionada, o próximo salto e o endereço de origem. A mensagem “Network is unreachable” (rede inacessível) aponta mais para roteamento do que para DNS. Uma rota selecionada ainda não prova que o próximo salto ou destino está respondendo.

Use o ping como uma pista de conectividade

ping -c 3 127.0.0.1
ping -c 3 example.com

O primeiro comando envia ao loopback mensagens Echo do Protocolo de Mensagens de Controle da Internet (ICMP); o segundo resolve um nome e envia requisições Echo para esse destino. O ICMP pode ser filtrado enquanto o acesso à web ainda funciona. Por outro lado, uma resposta não valida uma porta web, certificado ou resposta HTTP. Use um pequeno número de requisições para um destino de laboratório aprovado.

Separe falhas de resolução das falhas de conexão

getent ahosts example.com
curl -I -v --connect-timeout 5 --max-time 15 https://example.com/
printf "exit=%s\n" "$?"

Se getent não retornar nenhum endereço, investigue a configuração do serviço de nomes. A saída detalhada do curl separa seleção de endereço, conexão, TLS e manipulação de resposta. Os códigos de saída comumente incluem 6 para falha de resolução de nome, 7 para falha de conexão, 28 para timeout e 60 para falha de validação de certificado. Desativar a verificação de certificado com -k não corrige a causa.

Por padrão, o curl pode encerrar com sucesso após transferir uma resposta HTTP 404 ou 500. Use --fail-with-body em uma versão suportada, ou --fail, quando os erros HTTP devem gerar status de falha. Leia tanto o status HTTP quanto o status de saída do processo. -I envia uma requisição HEAD; um servidor pode rejeitá-la com 403 ou 405 mesmo quando um GET funciona. A presença de um proxy também muda o caminho observado. Oculte cookies, cabeçalhos e endereços privados antes de compartilhar a saída detalhada.

Verifique o endereço de escuta no servidor

ss -lnt
ss -lnu
sudo ss -lntp

Um serviço que escuta em 127.0.0.1:8080 aceita conexões diretas apenas localmente. 0.0.0.0:8080 cobre interfaces IPv4; se [::]:8080 também lida com IPv4 depende das configurações de socket e do sistema. Detalhes do processo podem exigir privilégios. Um socket UDP vinculado não é equivalente a uma troca de requisição-resposta validada.

Faça uma alteração justificada pelas evidências

Registre a configuração original, altere um item e repita o mesmo teste do mesmo cliente para o mesmo destino. Reverta uma alteração ineficaz antes de testar outra hipótese. Isso preserva evidências e ajuda a evitar a criação de uma segunda falha.

Para distinguir uma falha HTTP sem um site externo, confirme que python3 e curl estão instalados na VM de prática, instalando-os por meio do gerenciador de pacotes se necessário. Execute o seguinte servidor em um terminal. Ele serve apenas a pasta temporária recém-criada e fica restrito a 127.0.0.1; é um exercício local, não um servidor de produção. Se a porta 18080 estiver ocupada, escolha outra porta livre e altere-a em ambos os comandos.

lab=$(mktemp -d "$HOME/linux-http-check.XXXXXX") &&
python3 -m http.server 18080 --bind 127.0.0.1 --directory "$lab"

Após o servidor iniciar, execute isto em outro terminal interativo na mesma VM. Os exemplos com printf pressupõem que o shell continue após uma falha: um script com set -e pode terminar antes de mostrar o status. Espere HTTP 404 e status 22 do curl: uma conexão TCP e a resposta HTTP foram recebidas, mas o arquivo solicitado está ausente. Pare o servidor com Ctrl+C e, em seguida, repita. Sem um serviço em escuta, o curl normalmente reporta falha na conexão (7); um ambiente que espera até o tempo limite da conexão pode reportar 28. Leia o status imediatamente e verifique se nenhum outro servidor ocupou a porta.

curl --fail --show-error --connect-timeout 2 --max-time 5 http://127.0.0.1:18080/missing-file
printf "exit=%s\n" "$?"

Referências oficiais

• Opções oficiais do curl e códigos de saída
• Referência de configuração de rede do kernel