NFS over TCP inne i ein OpenVPN UDP-tunnel: to transportlag

Å føre ein NFS-samtale som brukar TCP inne i ein tunnel som ber UDP er heilt konsistent, og det forvirrar folk fordi det nemner to transportlag samtidig. TCP er filtjenesta si samtale mellom klienten og NFS-tenaren. UDP er den krypterte bæreren mellom VPN-endepunkta. Ingen av dei seier noko om den andre.

Skriv ned begge kvar for seg før du feilsøkjer noko; dei fleste av desse hendingane byrjar med at nokon endrar feil lag.

To lag, to innstillingar

Mount-innstillinga proto=tcp skildrar korleis NFS-klienten snakkar med NFS-tenaren. Innstillinga proto udp i VPN-profilen skildrar korleis endepunkta i tunnelen byter innkapsla pakkar. Å endre ei mount-innstilling endrar ikkje tunnelen, og å endre transporten i tunnelen endrar ikkje det NFS-klienten har forhandla. Stadfest dei effektive mount-innstillingane med nfsstat -m i staden for fstab-linja, og stadfest VPN-transporten frå profilen som faktisk blir brukt.

Skriv dei deretter i hendingsnotata som to separate felt. Ei tilsynelatande betring kan berre sporast om notatet seier kva lag som vart endra.

Å bla gjennom er ikkje masselesing

Ei mappeliste beviser at nokre operasjonar vart fullførte. Det beviser ikkje at ei vedvarande lesing, ei skriving, ein lås eller lagringsbakenden vil bli fullført under dei same tilhøva. Eit stopp midt i ei stor fil er ei anna observasjon enn ein mount som aldri lukkast, og dei peikar på ulike lag.

Skildr operasjonen som feilar presist: sti, retning, omtrentleg punkt for stoppet og den siste relevante hendinga i loggane til klienten, tenaren og VPN. Samanlikn deretter kvar trafikken held fram og kvar han stoppar.

MTU er ein hypotese, ikkje ein diagnose

Tap som er avhengig av pakkestorleik er ein reell moglegheit når ein tunnel ber store segment, og det gir nøyaktig mønsteret der bla gjennom fungerer og lesing stoppar. Det mønsteret beviser likevel ikkje eit MTU-problem, fordi same forma dukkar opp når ein tenar er treg, når ein brannmur avsluttar ei langvarig tilkopling på timeout, eller når ein disk er opptatt. Test hypotesen med ei kontrollert prøve i staden for å senke MTU overalt og erklære siger.

Ein timeout i seg sjølv seier ingenting om kvidt UDP bør bytast ut. Det er eit symptom med fleire moglege eigarar.

Endre éin variabel om gongen

Når du samanliknar transportlag, hald NFS-arbeidslasta og alle andre innstillingar stabile. Å endre mount-transporten, tunnelprotokollen og MTU i same vedlikehaldsvindauge gir eit resultat ingen kan tilskrive. Køyr den same filoperasjonen før og etter, og noter resultatet ved kvart steg.

Ta vare på dei tidlegare verdiane i saka òg. Viss ei endring gjer ting verre, bør tilbakerullinga vere eit dokumentert tal i staden for nokon si erindring om korleis det var før.

Les laget som feila

Viss tunnelen er oppe og NFS-førespurnaden ventar, feila ikkje VPN; filtjenesta gjorde det. Viss tunnelen fall, er fiaskoen til NFS-førespurnaden ein konsekvens og ikkje ei årsak. Å samanhalde logglinjer frå begge lag er den raskaste måten å skilje desse to tilfella, og det slår å gjette frå filhandsamaren.

Skriv konklusjonen som to setningar, éi per lag. Det er nok til at neste person kan gjenskape testen utan å finne ut på nytt kva transportlag som er kva.