NFS sobre TCP dins d’un túnel UDP d’OpenVPN: dos transports
El protocol de muntatge i el protocol del túnel són ajustos separats. Anoteu-los tots dos i després decidiu si l’aturada és del servei de fitxers o del transport.
Portar una conversa NFS que fa servir TCP dins d’un túnel que porta UDP és del tot coherent, i confon la gent perquè anomena dos transports alhora. TCP és la conversa del servei de fitxers entre el client i el servidor NFS. UDP és el transport xifrat entre els extrems del VPN. Cap dels dos no implica res sobre l’altre.
Anoteu-los tots dos per separat abans de depurar res; la majoria d’aquests incidents comencen quan algú canvia la capa equivocada.
Dues capes, dos ajustos
L’opció de muntatge proto=tcp descriu com el client NFS parla amb el servidor NFS. L’ajust proto udp del perfil VPN descriu com els extrems del túnel intercanvien paquets encapsulats. Canviar una opció de muntatge no canvia el túnel, i canviar el transport del túnel no canvia el que ha negociat el client NFS. Confirmeu les opcions de muntatge efectives amb nfsstat -m en lloc de la línia d’fstab, i confirmeu el transport VPN des del perfil que s’utilitza realment.
Després anoteu-los a les notes de l’incident com dos camps separats. Una millora aparent només es pot rastrejar si la nota diu quina capa ha canviat.
Navegar no és una lectura massiva
Un llistat de directori demostra que algunes operacions s’han completat. No demostra que una lectura sostinguda, una escriptura, un bloqueig o el sistema d’emmagatzematge es completin en les mateixes condicions. Una aturada a mig camí d’un fitxer gran és una observació diferent d’un muntatge que no reeix mai, i apunten a capes diferents.
Descriviu l’operació que falla amb precisió: camí, direcció, punt aproximat de l’aturada i l’últim esdeveniment rellevant als registres del client, del servidor i del VPN. Després compareu on el trànsit continua i on s’atura.
L’MTU és una hipòtesi, no un diagnòstic
La pèrdua dependent de la mida del paquet és una possibilitat real quan un túnel porta segments grans, i produeix exactament el patró de «navegar funciona, llegir s’atura». Ara bé, aquest patró no demostra un problema d’MTU, perquè la mateixa forma apareix quan un servidor va lent, quan un tallafoc fa caducar una connexió de llarga durada o quan un disc està ocupat. Proveu la hipòtesi amb una sonda controlada en lloc de baixar l’MTU a tot arreu i declarar la victòria.
Un temps d’espera per si sol no diu res sobre si cal substituir UDP. És un símptoma amb diversos possibles responsables.
Canvieu una variable alhora
En comparar transports, manteniu la càrrega NFS i tots els altres ajustos estables. Canviar el transport de muntatge, el protocol del túnel i l’MTU en la mateixa finestra de manteniment produeix un resultat que ningú no pot atribuir. Executeu la mateixa operació de fitxer abans i després, i anoteu el resultat a cada pas.
Guardeu també els valors anteriors al tiquet. Si un canvi empitjora les coses, la marxa enrere hauria de ser un número documentat i no el record d’algú de com era abans.
Llegiu la capa que ha fallat
Si el túnel està actiu i la petició NFS espera, el VPN no ha fallat; ha fallat el servei de fitxers. Si el túnel ha caigut, el fracàs de la petició NFS és una conseqüència i no una causa. Aparellar línies de registre de les dues capes és la manera més ràpida de distingir aquests dos casos, i és millor que endevinar-ho des del gestor de fitxers.
Escriviu la conclusió en dues frases, una per capa. Això n’hi ha prou perquè la següent persona reprodueixi la prova sense tornar a deduir quin transport és quin.