Les pages se chargent mais les envois bloquent sur un VPN : quelle cause gagne

Les pages se chargent, le VPN signale qu'il est connecté, et un envoi de fichier se fige au même endroit à chaque fois. Quatre explications correspondent à cette description : un problème de taille de paquet, un problème de résolution de noms, une limite applicative et un tunnel qui se réinitialise sans cesse. Chacune peut être confirmée ou écartée par une observation différente, donc la décision consiste à choisir le bon test plutôt qu'à deviner la cause.

Quatre candidats et une forme

Commencez par la forme de la panne, car elle élimine la majeure partie de la liste avant même d'ouvrir un outil. Un blocage qui survient à une taille constante est un problème de taille jusqu'à preuve du contraire. Un blocage à des points aléatoires est un problème de perte ou de stabilité. Une panne avant l'ouverture de la connexion est un problème de noms.

Le quatrième candidat est l'application. Les limites d'envoi, les délais d'attente des requêtes et les plafonds de taille du corps du proxy produisent des pannes qui, depuis le navigateur, ressemblent à des défauts réseau, et elles arrivent généralement sous forme de rejet plutôt que de blocage.

Notez la forme observée avant de tester quoi que ce soit. « S'arrête à peu près au même nombre d'octets, à chaque fois, tunnel actif » est un point de départ bien plus solide que « les envois ne fonctionnent pas ».

Ensuite, gardez le chemin fixe pendant les tests. Changer la sortie, le protocole et le serveur en même temps produit un résultat que vous ne pouvez attribuer à aucun d'eux. Une variable par exécution, et notez-la.

Coupez la taille en deux avant de toucher à la politique

Le discriminant le moins coûteux est une sonde qui fait varier un seul nombre. Envoyez des pings sans fragmentation de taille croissante vers la destination, envoyez un fichier que vous contrôlez au même service, puis comparez où chacun s'arrête.

ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/upload

La première commande indique si un paquet de taille pleine traverse le chemin. Avec une MTU de 1500 octets, la plus grande charge utile ICMP qui ne se fragmente pas est de 1472 octets, et un tunnel prélève encore davantage sur ce budget avant que le paquet intérieur ne commence. La seconde vous donne une taille et une durée pour un transfert au niveau applicatif, et c'est le nombre qui compte vraiment.

Lisez le couple ensemble. Des sondes qui échouent au-delà d'un seuil et un envoi qui s'arrête près de ce même seuil forment une histoire cohérente. Des sondes qui réussissent toutes alors que l'envoi bloque à un nombre d'octets que le chemin transporte manifestement pointent vers l'application ou le serveur, et aucun travail sur la MTU n'y changera rien. Ce résultat négatif vaut autant qu'un résultat positif. Il élimine la branche la plus coûteuse de l'enquête.

Vérifiez ensuite la stabilité pendant le transfert, car un tunnel qui renouvelle sa clé au milieu d'un gros envoi produit une panne qui semble dépendre de la taille sans que ce soit le cas. La lecture de la durée de fonctionnement est le moyen le moins coûteux de le confirmer.

Choisissez entre une réparation et un contournement

Si les preuves pointent vers la taille, il y a deux réponses honnêtes et une malhonnête. Les honnêtes consistent à rétablir la découverte de MTU du chemin en autorisant le retour ICMP nécessaire, ou à plafonner la taille de segment annoncée pour que les pairs envoient des segments plus petits. La malhonnête consiste à abaisser la MTU d'une interface à une valeur copiée sur un forum sans jamais vérifier ce qu'elle a changé.

Le choix dépend de ce que vous contrôlez. Sur un réseau que vous exploitez, autoriser les messages ICMP est la correction la plus propre car elle maintient le mécanisme en fonctionnement pour chaque protocole. Sur un chemin que vous ne contrôlez pas, le plafonnement est l'option pratique, et il doit être appliqué de façon étroite plutôt que sur tout le serveur.

Si les preuves pointent vers l'application, corrigez l'application ou sa configuration de proxy. Une réponse 413 et une connexion figée sont des pannes différentes, et la seconde est généralement un délai d'attente quelque part dans une chaîne qui comprend un proxy avec ses propres limites.

Dans tous les cas, conservez les valeurs d'origine et retestez après avoir annulé. Un changement qui coïncide avec un transfert réussi n'est pas la preuve qu'il l'a causé, et la possibilité d'annuler est ce qui sépare un diagnostic d'une coïncidence.

Consignez la décision pour qu'elle survive au prochain incident

Quatre faits suffisent : la forme observée de la panne, les résultats des sondes, le changement effectué et le résultat du nouveau test. Avec eux, la personne suivante peut dire si le problème est le même ou s'il s'agit d'un nouveau portant le même symptôme.

Notez aussi le contexte du chemin, car un constat de MTU est propre à un lien. Un portable qui fonctionne à la maison et échoue à l'hôtel a deux chemins, et une correction appliquée à l'un d'eux ne dit rien de l'autre.

Enfin, résistez au résumé selon lequel « le VPN a cassé les envois ». Le tunnel était présent dans le cas qui fonctionnait comme dans celui qui échouait ; ce qui a changé, c'est la taille du paquet que le chemin devait transporter, ou l'endroit où le transfert a été arrêté. Nommer le mécanisme réel est ce qui rend la note utile.