¿Fallo de DNS ou problema de MTU? Onde se detén realmente a petición

Dous fallos producen a mesma frase do usuario: o sitio non funciona. Ocorren en capas distintas, e a diferenza decide que cambia vostede. Un fallo de resolución de nome detense antes de que exista calquera conexión. Un fallo de tamaño de paquete ocorre despois de que o nome se resolveu e despois de que o handshake se completou, por iso a páxina comeza a cargar e despois colga. Atope a etapa antes de atopar o axuste.

Dous fallos en capas distintas

A resolución converte un nome nun enderezo, e nada máis da conexión pode comezar ata que o consiga. Os problemas de MTU da ruta ocorren máis tarde, cando se descarta un paquete maior que o límite dalgún enlace e o emisor nunca o sabe. Un é unha consulta; o outro é un fallo de entrega que só aparece por riba dun certo tamaño.

Os síntomas difiren dunha forma que pode observar sen ferramentas. Un fallo de DNS é inmediato e constante: o navegador di que non se atopa o servidor. Un fallo de MTU é parcial: a páxina comeza, chegan algúns recursos e unha resposta grande ou unha subida atáscase.

Se o seu síntoma é parcial, deixe de mirar o DNS.

Etapa 1: ¿resólvese o nome sequera

Use as ferramentas de consulta da plataforma co nome de host exacto que usa a aplicación. Un nome privado da oficina pode requirir un resolutor interno, e o DNS seguro propio do navegador pode comportarse de forma distinta ao resolutor do sistema operativo, así que ambos poden discrepar sobre o mesmo nome.

Pregunte ao resolutor que usaría o sistema operativo e despois compare:

dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53

Se a resolución falla, o problema é esa política e a súa accesibilidade. Non envía nomes privados a resolutores públicos arbitrarios só para obter unha comparación, porque a comparación mesma filtra os nomes que quería manter internos.

Etapa 2: onde se detén a transferencia

Se o nome se resolve e a conexión comeza, rexistre onde se detén a operación. Unha páxina que se debuxa e despois colga nun recurso, unha subida que morre nun punto constante ou unha descarga grande que nunca remata mentres as peticións pequenas funcionan son todos síntomas con forma de tamaño. Unha resposta que nunca comeza ten outra forma.

Manteña fixos o extremo e o destino da aplicación mentres compara, ou estará medindo dúas variables á vez. Nesta etapa seguen a ser posibles outras causas: erros do servizo, perda, comportamento do filtro e reconexións do túnel producen atascos.

Un atasco repetible vale máis que dez anecdóticos.

Por que o MTU só doe despois do handshake

O handshake TCP usa paquetes pequenos, así que ten éxito nunha ruta que non pode levar un segmento de tamaño completo. O fallo aparece cando o emisor envía un paquete grande co bit de non fragmentar, un enlace o descarta e a mensaxe ICMP que informaría do límite nunca chega porque un filtro a comeu. O emisor reintenta o mesmo tamaño e a transferencia atáscase.

Por iso o síntoma depende do tamaño e é repetible en lugar de aleatorio. Tamén explica por que facer ping ao host non demostra nada, porque un eco ICMP pequeno pode cruzar unha ruta que non levará unha carga de tamaño completo. Sondee o tamaño desde ambos os extremos da ruta se pode. Un límite que só aparece nunha dirección é unha asimetría de encamiñamento e non un MTU de túnel.

Sondee o tamaño explicitamente en lugar de inferilo:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

Cambie unha capa e despois demostre

Para os nomes, cambie a política do resolutor e execute a mesma consulta outra vez. Para o tamaño, use o procedemento de MTU cos valores orixinais rexistrados e unha reversión lista, porque limitar o MSS sen coñecer o MTU real do túnel cambia un atasco por outro.

Unha páxina que carga unha vez despois de cambiar varios axustes non identifica a reparación. Cambie unha cousa, execute a mesma proba outra vez e garde o resultado xunto á primeira etapa fallida que rexistrou.

Ese rexistro é o que evita que o DNS, o tamaño de paquete e a autenticación se convertan nun montón de solucións provisionais permanentes que ninguén pode explicar. Probar cunha IP crua é un bo exemplo de atallo que cambia a identidade TLS, e desactivar a verificación do certificado para que unha comparación saia ben non é un diagnóstico.