NFS sur TCP dans un tunnel UDP OpenVPN : deux transports

Faire passer une conversation NFS qui utilise TCP dans un tunnel qui transporte UDP est parfaitement cohérent, et cela déroute parce que cela nomme deux transports à la fois. TCP est la conversation du service de fichiers entre le client et le serveur NFS. UDP est le transport chiffré entre les extrémités du VPN. Ni l’un ni l’autre n’implique quoi que ce soit sur l’autre.

Notez les deux séparément avant de déboguer quoi que ce soit ; la plupart de ces incidents commencent quand quelqu’un modifie la mauvaise couche.

Deux couches, deux réglages

L’option de montage proto=tcp décrit comment le client NFS parle au serveur NFS. Le réglage proto udp du profil VPN décrit comment les extrémités du tunnel échangent des paquets encapsulés. Changer une option de montage ne change pas le tunnel, et changer le transport du tunnel ne change pas ce que le client NFS a négocié. Vérifiez les options de montage effectives avec nfsstat -m plutôt qu’avec la ligne fstab, et vérifiez le transport du VPN à partir du profil réellement utilisé.

Notez-les ensuite dans les notes d’incident sous forme de deux champs distincts. Une amélioration apparente n’est traçable que si la note indique quelle couche a changé.

Parcourir n’est pas une lecture en masse

Une liste de répertoire prouve que certaines opérations se sont terminées. Elle ne prouve pas qu’une lecture soutenue, une écriture, un verrou ou le stockage sous-jacent aboutiront dans les mêmes conditions. Un blocage au milieu d’un gros fichier est une observation différente d’un montage qui n’aboutit jamais, et ils pointent vers des couches différentes.

Décrivez précisément l’opération qui échoue : chemin, sens, point approximatif du blocage et dernier événement pertinent dans les journaux du client, du serveur et du VPN. Comparez ensuite où le trafic continue et où il s’arrête.

Le MTU est une hypothèse, pas un diagnostic

Une perte dépendante de la taille des paquets est une possibilité réelle quand un tunnel transporte de grands segments, et elle produit exactement le schéma où la navigation fonctionne et la lecture se bloque. Ce schéma ne prouve pas pour autant un problème de MTU, car la même forme apparaît quand un serveur est lent, quand un pare-feu coupe une connexion longue durée par expiration ou quand un disque est occupé. Testez l’hypothèse avec une sonde contrôlée plutôt que de baisser le MTU partout et de déclarer la victoire.

Une expiration à elle seule ne dit rien sur la nécessité de remplacer UDP. C’est un symptôme qui a plusieurs propriétaires possibles.

Changez une variable à la fois

Lorsque vous comparez des transports, gardez la charge NFS et tous les autres réglages stables. Changer le transport de montage, le protocole du tunnel et le MTU dans la même fenêtre de maintenance produit un résultat que personne ne peut attribuer. Exécutez la même opération de fichier avant et après, et consignez le résultat à chaque étape.

Conservez aussi les valeurs précédentes dans le ticket. Si un changement aggrave les choses, le retour en arrière doit être un nombre documenté plutôt que le souvenir de quelqu’un sur l’état antérieur.

Lisez la couche qui a échoué

Si le tunnel est actif et que la requête NFS attend, le VPN n’a pas échoué ; le service de fichiers a échoué. Si le tunnel est tombé, l’échec de la requête NFS est une conséquence et non une cause. Rapprocher les lignes de journal des deux couches est le moyen le plus rapide de distinguer ces deux cas, et c’est mieux que deviner depuis le gestionnaire de fichiers.

Rédigez la conclusion en deux phrases, une par couche. Cela suffit à la personne suivante pour reproduire le test sans redéduire quel transport est lequel.