Falha de DNS ou problema de MTU? Onde o pedido realmente para
Um nome que nunca é resolvido falha antes de qualquer ligação; um bloqueio de MTU começa depois do handshake. Descubra primeiro a etapa e depois mude uma camada e volte a testar.
Duas falhas produzem a mesma frase do utilizador: o site não funciona. Acontecem em camadas diferentes, e a diferença decide o que vai mudar. Uma falha de resolução de nome para antes de existir qualquer ligação. Uma falha de tamanho de pacote acontece depois de o nome estar resolvido e de o handshake terminar, é por isso que a página começa a carregar e depois bloqueia. Descubra a etapa antes de descobrir a configuração.
Duas falhas em camadas diferentes
A resolução transforma um nome num endereço, e nada mais na ligação pode começar até isso ter sucesso. Os problemas de MTU do caminho acontecem mais tarde, quando um pacote maior do que o limite de qualquer ligação é descartado e o emissor nunca é informado. Um é uma consulta; o outro é uma falha de entrega que só aparece acima de um certo tamanho.
Os sintomas diferem de uma forma que pode observar sem qualquer ferramenta. Uma falha de DNS é imediata e constante: o navegador diz que o servidor não foi encontrado. Uma falha de MTU é parcial: a página começa, alguns recursos chegam e uma resposta grande ou um envio bloqueia.
Se o seu sintoma é parcial, pare de olhar para o DNS.
Etapa 1: o nome resolve-se sequer
Use as ferramentas de consulta da plataforma com o nome de anfitrião exato que a aplicação usa. Um nome privado no escritório pode exigir um resolvedor interno, e o DNS seguro do próprio navegador pode comportar-se de forma diferente do resolvedor do sistema operativo, por isso os dois podem discordar sobre o mesmo nome.
Pergunte ao resolvedor que o sistema operativo usaria e depois compare:
dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53
Se a resolução falhar, o problema está nessa política e na sua acessibilidade. Não envie nomes privados para resolvedores públicos arbitrários só para obter uma comparação, porque a comparação em si divulga os nomes que queria manter internos.
Etapa 2: onde a transferência para
Se o nome for resolvido e a ligação começar, registe onde a operação para. Uma página que é apresentada e depois bloqueia num recurso, um envio que morre num ponto constante, ou uma transferência grande que nunca termina enquanto os pedidos pequenos funcionam são todos sintomas com forma de tamanho. Uma resposta que nunca começa tem outra forma.
Mantenha o ponto final e o destino da aplicação fixos durante a comparação, caso contrário está a medir duas variáveis ao mesmo tempo. Outras causas continuam possíveis nesta etapa: erros do serviço, perda, comportamento do filtro e reconexões do túnel produzem todos bloqueios.
Um bloqueio repetível vale mais do que dez anedóticos.
Porque é que o MTU só prejudica depois do handshake
O handshake TCP usa pacotes pequenos, por isso tem sucesso num caminho que não consegue transportar um segmento de tamanho completo. A falha aparece quando o emissor envia um pacote grande com o bit de não fragmentação, uma ligação descarta-o e a mensagem ICMP que teria reportado o limite nunca chega porque um filtro a comeu. O emissor tenta então o mesmo tamanho e a transferência bloqueia.
É por isso que o sintoma depende do tamanho e é repetível em vez de aleatório. Também explica porque é que fazer ping ao anfitrião não prova nada, porque um eco ICMP pequeno pode atravessar um caminho que não vai transportar uma carga de tamanho completo. Meça o tamanho a partir das duas pontas do caminho, se puder. Um limite que só aparece numa direção é uma assimetria de encaminhamento e não um MTU de túnel.
Meça o tamanho explicitamente em vez de o inferir:
ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20
Mude uma camada e depois prove-o
Para os nomes, mude a política do resolvedor e execute a mesma consulta outra vez. Para o tamanho, use o procedimento de MTU com os valores originais registados e uma reversão pronta, porque limitar o MSS sem conhecer o MTU real do túnel troca um bloqueio por outro.
Uma página que carrega uma vez depois de várias configurações alteradas não identifica a reparação. Mude uma coisa, execute o mesmo teste outra vez e guarde o resultado ao lado da primeira etapa falhada que registou.
É esse registo que impede o DNS, o tamanho do pacote e a autenticação de se tornarem uma pilha de contornos permanentes que ninguém consegue explicar. Testar com um IP cru é um bom exemplo de atalho que muda a identidade TLS, e desativar a verificação do certificado para uma comparação passar não é um diagnóstico.