Pourquoi les pages OpenConnect se bloquent jusqu’à ce que vous baissiez le MTU du tunnel

La connexion réussit, la page d’accueil du portail s’affiche, puis un widget du tableau de bord ou un rapport reste sur waiting for host jusqu’à ce que le navigateur abandonne. Les sites publics se chargent normalement tout du long, et aucun identifiant n’a changé. Le fait que de petites réponses arrivent pendant que les grosses calent est la signature d’un plafond de taille de paquet, et non d’une règle d’accès. Confirmez cette lecture avant de modifier quoi que ce soit d’autre dans le profil.

Séparez un problème de taille d’un problème de politique

Commencez par écarter un refus. Si la passerelle vous avait refusé, la connexion aurait échoué tout de suite au lieu de charger une page à moitié. Un tunnel qui monte puis cale uniquement sur les transferts plus gros vous dit que le chemin extérieur ne peut pas porter le paquet intérieur.

Le mécanisme est l’encapsulation. Chaque paquet intérieur gagne des en-têtes de tunnel, si bien qu’une charge utile qui tenait dans la liaison physique devient un paquet extérieur qui n’y tient plus, et tout ce qui porte le bit do-not-fragment est jeté sans réponse que le navigateur puisse interpréter.

Mesurez le plafond avec des sondes do-not-fragment

Mesurez le plafond au lieu de le deviner. Envoyez des sondes qui refusent la fragmentation et descendez la charge utile palier par palier jusqu’à ce qu’une réponse revienne, en partant d’une commande comme ping -M do -s 1472 host. Une réponse qui se plaint qu’une fragmentation est nécessaire alors que DF est activé signifie que la valeur est encore trop élevée. Répétez à 1462, puis à 1452, et arrêtez-vous à la première taille qui répond. Notez le nombre avec l’hôte que vous avez sondé, car la réponse appartient à ce chemin et non au protocole en général.

Sondez l’adresse vers laquelle le tunnel envoie réellement le trafic. Une sonde extérieure vers le nom public de la passerelle et une sonde intérieure vers un serveur interne mesurent des sauts différents, et le filtrage ICMP sur l’une ou l’autre peut faire passer un chemin sain pour cassé.

Appliquez la valeur à l’appareil du tunnel

Appliquez le résultat à l’interface créée par le client, pas à l’adaptateur Wi-Fi. Sur un client Linux, c’est ip link set dev tun0 mtu 1300 suivi de ip link show tun0 pour confirmer que la valeur a été prise. Utilisez le nom d’appareil que le client rapporte, car il varie selon l’implémentation et selon la façon dont le tunnel a été construit.

Baisser le MTU du tunnel réduit la charge utile que porte chaque paquet, donc le débit massif baisse un peu, et c’est le prix à payer pour ne pas envoyer les grosses réponses dans un trou noir. Un nombre plus petit n’est pas automatiquement plus sûr. Changer l’adaptateur physique à la place répartit les dégâts sur toutes les connexions de cette liaison tout en laissant les paquets intérieurs surdimensionnés tout aussi surdimensionnés.

Utilisez d’abord les demandes de MTU du client

Quand vous contrôlez l’appel, le client peut demander une taille au lieu d’être corrigé après coup. --mtu demande un MTU de tunnel au serveur, et --base-mtu déclare le MTU du chemin sous-jacent pour que la passerelle puisse dériver le chiffre du tunnel. Les deux sont des demandes, et le manuel du client ne promet pas que la passerelle en honorera une seule.

Cette distinction fixe votre ordre de travail. Essayez d’abord la demande et inspectez l’interface qu’elle produit, puis revenez au réglage local de l’appareil si la valeur choisie par la passerelle cale encore.

Vérifiez avec le transfert qui a échoué, puis rendez-le persistant

Une modification locale d’ip link tient jusqu’à ce que le client reconstruise le tunnel, ce qui arrive à la reconnexion ou à la reprise suivante. Placez la valeur là où la connexion démarre : un wrapper qui lance le client puis ajuste l’appareil, une unité systemd avec une étape ExecStartPost, ou l’option du client quand la passerelle l’accepte. Gardez-la à côté du profil dans le contrôle de version pour que la personne suivante voie pourquoi le nombre est là.

Testez avec la requête qui a échoué, pas avec la page d’accueil. Ouvrez le rapport, récupérez la pièce jointe ou lancez la récupération du dépôt qui s’est bloquée, et notez exactement où elle s’arrête si elle s’arrête encore. Une page qui s’affiche après le changement prouve peu, car elle s’affichait aussi avant.

Si le même transfert cale au même endroit, la théorie du MTU n’est pas prouvée. Capturez le trafic sur le tunnel et vérifiez quel côté cesse d’envoyer avant de changer à nouveau le nombre, et gardez la valeur précédente notée pour qu’un retour arrière reste une seule commande.