Le ping du VPN fonctionne mais le site se bloque : vérifiez la taille

Les réponses d'écho arrivent, le bureau à distance fonctionne, et le navigateur reste sur une page blanche jusqu'à abandonner. Deux explications correspondent à ce schéma, et ce ne sont pas des variantes d'un même problème : une politique qui n'a jamais autorisé le service, ou des paquets qui cessent de tenir dès que le transfert grossit. La réponse d'écho n'exclut ni l'une ni l'autre.

Allez de la plus petite question à la plus grande, et notez ce que chaque étape a réellement prouvé.

Une réponse d'écho répond à une question bien plus petite

Une réponse d'écho dit que la pile IP de la destination a répondu à une requête ICMP de votre source. Elle ne dit rien sur l'existence d'un écouteur TCP sur le port dont vous avez besoin, sur le fait qu'une politique autorise ce port, ni sur le fait que l'hôte de destination filtre le trafic indépendamment de la passerelle. Une passerelle qui autorise un service peut en écarter un autre alors que les deux cibles répondent au ping. Lisez la réponse comme un seul fait sur un seul paquet et un seul sens.

Confirmez la destination et le port du service avant d'interpréter quoi que ce soit d'autre. L'adresse que vous avez testée et celle qu'utilise l'application sont parfois des enregistrements différents, et un nom qui se résout en deux adresses rend cela probable.

Déterminez si la connexion a commencé

Une connexion refusée immédiatement est une réponse de l'écouteur ou de la politique : quelque chose a répondu et a dit non. Une connexion qui s'ouvre puis se bloque lorsque les données commencent à circuler pointe vers la taille. Une connexion qui ne termine jamais la poignée de main relève généralement de la politique ou du routage, et ressemble à un délai d'attente plutôt qu'à un refus.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Notez lequel de ces trois cas vous avez observé avant de toucher aux réglages MTU. Changer la taille du tunnel pour corriger une connexion refusée gaspille ce changement et masque la cause réelle pendant un temps.

Mesurez la taille avec un nombre énoncé

Lorsque le blocage apparaît sous charge, testez une taille de paquet avec le bit de non-fragmentation activé et énoncez l'arithmétique pour que le résultat signifie quelque chose. Sous Linux avec iputils, une charge utile de 1392 octets plus l'en-tête ICMP de 8 octets et l'en-tête IPv4 de 20 octets produit un paquet interne d'exactement 1420 octets. Énoncez cette arithmétique dans le ticket, car un ping nu qui atteint la passerelle ne prouve rien sur une application.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Les deux sondes sont des points de mesure, pas des recommandations de taille de tunnel. Si l'ICMP est filtré quelque part sur le chemin, un délai d'attente ne vous dit rien sur la taille, car le filtrage et un paquet trop gros se ressemblent côté client. Un succès ne dit rien non plus sur le sens inverse ni sur une autre destination.

Tenez compte du chemin extérieur

L'encapsulation ajoute ses propres en-têtes, si bien que le paquet sur le fil est plus grand que celui que vous avez mesuré à l'intérieur du tunnel. C'est l'écart entre les deux qui rend possibles à la fois une petite requête qui fonctionne et une grande qui échoue.

La découverte du MTU du chemin en IPv4 dépend du retour d'information sur les paquets qui ne peuvent pas être transmis sans fragmentation, et IPv6 utilise les messages Packet Too Big. La spécification IPv4 décrit ce mécanisme. Filtrer le retour d'information détruit la capacité de l'émetteur à apprendre et le laisse retransmettre des paquets qui ne tiendront jamais. C'est pourquoi une petite requête qui fonctionne et une grande qui échoue coexistent si facilement.

Changez un nombre et retestez l'application

Réduisez le MTU du tunnel, ou limitez la taille maximale de segment pour TCP, puis répétez le test d'application d'origine plutôt que la sonde. Une sonde qui réussit après le changement et une application qui se bloque encore sont un problème différent de forme semblable, et seul le test d'application les distingue.

Conservez l'arithmétique dans le registre du changement : la taille mesurée, la surcharge supposée et la valeur définie. Quiconque l'examinera plus tard pourra vérifier l'hypothèse au lieu de la redériver à partir d'une capture d'écran d'un ping.

Si l'application fonctionne à toutes les tailles que vous avez essayées, arrêtez d'ajuster des nombres et regardez la politique qui sépare le service qui fonctionne de celui qui échoue.