Diagnosticar rede em dez minutos

"Deve ser a rede" é a frase mais dita e menos verificada em incidentes. Na maioria das vezes é o serviço. Mas ela é dita porque ninguém no time sabe checar.

Este é o roteiro para checar. Seis comandos, em ordem, subindo pelas camadas. Cada um elimina uma hipótese.

Primeiro: entenda o sintoma#

Antes dos comandos, o tipo de falha já te diz muito:

→ Timeout total, nada responde → camada 3 ou 4. Roteamento, firewall, serviço fora.

→ Conecta e trava → camada 4 ou o serviço não está respondendo.

→ Erro de certificado → TLS.

→ Resposta HTTP com código de erro → camada 7. A rede está bem; o problema é a aplicação.

→ Funciona às vezes → perda de pacote, um nó ruim atrás de um balanceador, ou DNS com múltiplos registros e um deles quebrado.

Essa classificação leva dez segundos e economiza muito.

Passo 1: resolve o nome?#

dig api.exemplo.com
dig +trace api.exemplo.com

Se não resolve, é DNS. Acabou a investigação, e você já sabe para quem falar.

O +trace mostra a cadeia completa, da raiz ao servidor autoritativo. Útil quando a resposta está inconsistente entre lugares.

Repare no TTL da resposta. Se você acabou de mudar o registro e o TTL é de 1800 segundos, metade dos clientes vai continuar batendo no IP antigo por meia hora.

As falhas clássicas de DNS:

→ TTL alto na hora da migração. Abaixe com antecedência.

→ Cache eterno no processo. Muitas linguagens fazem cache de DNS no processo e ignoram TTL. O servidor muda de IP e a aplicação nunca percebe até reiniciar.

→ ndots em Kubernetes. O padrão é 5, o que significa que um nome com menos de cinco pontos é testado contra vários sufixos de busca antes de resolver. Uma chamada externa pode virar quatro ou cinco consultas. Em volume, isso derruba o DNS do cluster. Confira com cat /etc/resolv.conf dentro do pod.

Passo 2: chega no destino?#

mtr -rwzbc 100 api.exemplo.com

ping resolve pouco, porque muita rede bloqueia ou despriorizava ICMP. Prefira mtr, que mostra latência e perda salto a salto.

Como ler: perda num salto intermediário que não se propaga para os seguintes normalmente é o roteador despriorizando ICMP, e dá para ignorar. Perda que começa num salto e continua até o destino é problema real naquele trecho.

Passo 3: a porta abre?#

nc -zv api.exemplo.com 443

Se o nome resolve e a porta não abre, é firewall, security group, network policy, ou o serviço não está escutando.

Em nuvem, esse é o passo que mais frequentemente encontra o problema, e a causa costuma ser um security group que permite a saída mas não a entrada, ou uma NACL que bloqueia o retorno.

Passo 4: o TLS fecha?#

openssl s_client -connect api.exemplo.com:443 -servername api.exemplo.com

Aqui você vê a cadeia de certificados, a validade e o nome apresentado.

Os problemas comuns: certificado expirado (ainda acontece, muito); cadeia incompleta, que funciona no seu navegador, com o intermediário em cache, e falha no servidor que não tem; e SNI errado, quando o mesmo IP hospeda vários domínios.

O -servername existe justamente para testar o SNI.

Passo 5: o HTTP responde, e onde vai o tempo?#

curl -w "dns:%{time_namelookup} conn:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -o /dev/null -s https://api.exemplo.com/rota

Este é o comando mais útil da lista, porque ele decompõe o tempo por fase.

→ time_namelookup alto → DNS

→ time_connect alto → latência de rede ou fila no destino

→ time_appconnect alto → handshake TLS

→ time_starttransfer alto com os anteriores baixos → o servidor está lento. A rede está bem.

Essa última linha é a que mais frequentemente encerra a discussão sobre "é a rede".

Rode duas vezes seguidas: a segunda deve ser mais rápida por causa do cache de DNS.

Passo 6: como está a conexão por dentro?#

ss -ti
ss -tan | awk '{print $1}' | sort | uniq -c

O primeiro mostra as conexões TCP com detalhes: janela, tempo de ida e volta estimado, e retransmissões. Retransmissão alta é perda de pacote, e perda de pacote destrói vazão muito além do que a porcentagem sugere, porque o TCP interpreta como congestionamento e reduz a janela.

O segundo conta os estados, e ele resolve uma confusão clássica:

→ Muito CLOSE_WAIT = bug seu. O outro lado fechou e a sua aplicação não chamou close. Cada uma segura um descritor.

→ Muito TIME_WAIT = normal em serviço de alto volume. Aparece no lado que fechou, dura cerca de 60 segundos por desenho. Vira problema só quando as portas efêmeras acabam, e a correção certa não é mexer no kernel: é parar de abrir conexão nova a cada chamada.

O bug fantasma: MTU#

Um caso que merece menção porque é difícil e recorrente.

Sintoma: a conexão estabelece, requisições pequenas funcionam, e requisições grandes travam sem erro.

Causa: o MTU do caminho é menor que o do seu host, o que é comum com VPN, túnel e algumas redes de nuvem. O pacote grande precisa ser fragmentado, o roteador envia um ICMP "fragmentação necessária" (tipo 3, código 4), e alguém no caminho bloqueia ICMP.

O remetente nunca fica sabendo. O pacote some. E o sintoma parece aplicação.

Correção: MSS clamping no roteador, ou reduzir o MTU. Diagnóstico: ping -M do -s 1400 variando o tamanho até achar onde para de passar.

Guarde o retrato de normalidade#

O conselho mais útil deste artigo:

Rode os seis comandos contra o seu serviço mais crítico enquanto ele está saudável. Salve a saída num arquivo versionado.

Na próxima vez que der problema, você vai ter com o que comparar, que é exatamente a coisa que sempre falta às três da manhã.