¿Fallo de DNS o problema de MTU? Dónde se detiene realmente la petición

Dos fallos producen la misma frase del usuario: el sitio no funciona. Ocurren en capas distintas, y la diferencia decide qué cambia usted. Un fallo de resolución de nombre se detiene antes de que exista cualquier conexión. Un fallo de tamaño de paquete ocurre después de que el nombre se resolvió y después de que el handshake se completó, por eso la página empieza a cargar y luego se cuelga. Encuentre la etapa antes de encontrar el ajuste.

Dos fallos en capas distintas

La resolución convierte un nombre en una dirección, y nada más de la conexión puede empezar hasta que lo consiga. Los problemas de MTU de la ruta ocurren más tarde, cuando se descarta un paquete mayor que el límite de algún enlace y el emisor nunca se entera. Uno es una consulta; el otro es un fallo de entrega que solo aparece por encima de cierto tamaño.

Los síntomas difieren de una forma que puede observar sin herramientas. Un fallo de DNS es inmediato y constante: el navegador dice que no se encuentra el servidor. Un fallo de MTU es parcial: la página empieza, llegan algunos recursos y una respuesta grande o una subida se atasca.

Si su síntoma es parcial, deje de mirar el DNS.

Etapa 1: ¿se resuelve el nombre siquiera

Use las herramientas de consulta de la plataforma con el nombre de host exacto que usa la aplicación. Un nombre privado de la oficina puede requerir un resolutor interno, y el DNS seguro propio del navegador puede comportarse de forma distinta al resolutor del sistema operativo, así que ambos pueden discrepar sobre el mismo nombre.

Pregunte al resolutor que usaría el sistema operativo y luego compare:

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

Si la resolución falla, el problema es esa política y su accesibilidad. No envíe nombres privados a resolutores públicos arbitrarios solo para obtener una comparación, porque la comparación misma filtra los nombres que quería mantener internos.

Etapa 2: dónde se detiene la transferencia

Si el nombre se resuelve y la conexión empieza, registre dónde se detiene la operación. Una página que se dibuja y luego se cuelga en un recurso, una subida que muere en un punto constante o una descarga grande que nunca termina mientras las peticiones pequeñas funcionan son todos síntomas con forma de tamaño. Una respuesta que no empieza nunca tiene otra forma.

Mantenga fijos el extremo y el destino de la aplicación mientras compara, o estará midiendo dos variables a la vez. En esta etapa siguen siendo posibles otras causas: errores del servicio, pérdida, comportamiento del filtro y reconexiones del túnel producen atascos.

Un atasco repetible vale más que diez anecdóticos.

Por qué el MTU solo duele después del handshake

El handshake TCP usa paquetes pequeños, así que tiene éxito en una ruta que no puede llevar un segmento de tamaño completo. El fallo aparece cuando el emisor envía un paquete grande con el bit de no fragmentar, un enlace lo descarta y el mensaje ICMP que habría informado del límite nunca llega porque un filtro se lo comió. El emisor reintenta el mismo tamaño y la transferencia se atasca.

Por eso el síntoma depende del tamaño y es repetible en lugar de aleatorio. También explica por qué hacer ping al host no demuestra nada, porque un eco ICMP pequeño puede cruzar una ruta que no llevará una carga de tamaño completo. Sondee el tamaño desde ambos extremos de la ruta si puede. Un límite que solo aparece en una dirección es una asimetría de enrutamiento y no un MTU de túnel.

Sondee el tamaño explícitamente en lugar de inferirlo:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

Cambie una capa y luego demuéstrelo

Para los nombres, cambie la política del resolutor y ejecute la misma consulta otra vez. Para el tamaño, use el procedimiento de MTU con los valores originales registrados y una reversión lista, porque limitar el MSS sin conocer el MTU real del túnel cambia un atasco por otro.

Una página que carga una vez después de cambiar varios ajustes no identifica la reparación. Cambie una cosa, ejecute la misma prueba otra vez y guarde el resultado junto a la primera etapa fallida que registró.

Ese registro es lo que evita que el DNS, el tamaño de paquete y la autenticación se conviertan en un montón de soluciones provisionales permanentes que nadie puede explicar. Probar con una IP cruda es un buen ejemplo de atajo que cambia la identidad TLS, y desactivar la verificación del certificado para que una comparación salga bien no es un diagnóstico.