Échec DNS ou problème MTU ? Où la requête s'arrête vraiment

Deux échecs produisent la même phrase chez l'utilisateur : le site ne fonctionne pas. Ils se produisent sur des couches différentes, et cette différence décide de ce que vous changez. Un échec de résolution de nom s'arrête avant qu'une connexion existe. Un échec de taille de paquet survient après la résolution du nom et après la fin de la poignée de main, c'est pourquoi la page commence à charger puis se bloque. Trouvez l'étape avant de trouver le réglage.

Deux échecs sur des couches différentes

La résolution transforme un nom en adresse, et rien d'autre dans la connexion ne peut commencer avant qu'elle réussisse. Les problèmes de MTU du chemin surviennent plus tard, quand un paquet plus grand que la limite d'un lien est jeté et que l'émetteur n'en est jamais informé. L'un est une recherche ; l'autre est un échec de livraison qui n'apparaît qu'au-delà d'une certaine taille.

Les symptômes diffèrent d'une manière que vous pouvez observer sans aucun outil. Un échec DNS est immédiat et constant : le navigateur dit que le serveur est introuvable. Un échec MTU est partiel : la page commence, certaines ressources arrivent, et une grande réponse ou un envoi se bloque.

Si votre symptôme est partiel, arrêtez de regarder le DNS.

Étape 1 : le nom se résout-il seulement

Utilisez les outils de recherche de la plateforme avec le nom d'hôte exact que l'application utilise. Un nom privé au bureau peut exiger un résolveur interne, et le DNS sécurisé propre au navigateur peut se comporter autrement que le résolveur du système d'exploitation, si bien que les deux peuvent être en désaccord sur le même nom.

Interrogez le résolveur que le système d'exploitation utiliserait, puis comparez :

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

Si la résolution échoue, le problème tient à cette politique et à son accessibilité. N'envoyez pas de noms privés à des résolveurs publics arbitraires juste pour obtenir une comparaison, car la comparaison elle-même divulgue les noms que vous vouliez garder internes.

Étape 2 : où le transfert s'arrête

Si le nom se résout et que la connexion commence, notez où l'opération s'arrête. Une page qui s'affiche puis se bloque sur une ressource, un envoi qui meurt à un point constant, ou un grand téléchargement qui ne finit jamais alors que les petites requêtes fonctionnent sont tous des symptômes en forme de taille. Une réponse qui ne démarre pas du tout a une autre forme.

Gardez le point de terminaison et la destination de l'application fixes pendant la comparaison, sinon vous mesurez deux variables à la fois. D'autres causes restent possibles à cette étape : erreurs de service, perte, comportement du filtre et reconnexions en chaîne du tunnel produisent tous des blocages.

Un blocage reproductible vaut plus que dix anecdotes.

Pourquoi le MTU ne nuit qu'après la poignée de main

La poignée de main TCP utilise de petits paquets, elle réussit donc sur un chemin qui ne peut pas porter un segment de taille pleine. L'échec apparaît quand l'émetteur envoie un grand paquet avec le bit de non-fragmentation, qu'un lien le jette et que le message ICMP qui aurait signalé la limite n'arrive jamais parce qu'un filtre l'a mangé. L'émetteur réessaie alors la même taille et le transfert se bloque.

C'est pourquoi le symptôme dépend de la taille et se reproduit au lieu d'être aléatoire. Cela explique aussi pourquoi un ping vers l'hôte ne prouve rien, car un petit écho ICMP peut traverser un chemin qui ne portera pas une charge de taille pleine. Sondez la taille depuis les deux extrémités du chemin si vous pouvez. Une limite qui n'apparaît que dans un sens est une asymétrie de routage et non un MTU de tunnel.

Sondez la taille explicitement au lieu de la déduire :

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

Changez une couche, puis prouvez-le

Pour les noms, changez la politique du résolveur et relancez la même recherche. Pour la taille, utilisez la procédure MTU avec les valeurs d'origine consignées et un retour arrière prêt, car brider le MSS sans connaître le MTU réel du tunnel échange un blocage contre un autre.

Une page qui charge une fois après plusieurs réglages modifiés n'identifie pas la réparation. Changez une chose, relancez le même test et gardez le résultat à côté de la première étape en échec que vous avez notée.

C'est cette trace qui empêche le DNS, la taille des paquets et l'authentification de devenir un tas de contournements permanents que personne ne peut expliquer. Tester par IP brute est un bon exemple de raccourci qui change l'identité TLS, et désactiver la vérification du certificat pour faire réussir une comparaison n'est pas un diagnostic.