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

Å føre en NFS-samtale som bruker TCP inne i en tunnel som bærer UDP er helt konsistent, og det forvirrer folk fordi det navngir to transportlag samtidig. TCP er filtjenestens samtale mellom klienten og NFS-serveren. UDP er den krypterte bæreren mellom VPN-endepunktene. Ingen av dem sier noe om den andre.

Skriv ned begge hver for seg før du feilsøker noe; de fleste av disse hendelsene begynner med at noen endrer feil lag.

To lag, to innstillinger

Mount-innstillingen proto=tcp beskriver hvordan NFS-klienten snakker med NFS-serveren. Innstillingen proto udp i VPN-profilen beskriver hvordan tunnelens endepunkter utveksler innkapslede pakker. Å endre en mount-innstilling endrer ikke tunnelen, og å endre tunnelens transport endrer ikke det NFS-klienten har forhandlet. Bekreft de effektive mount-innstillingene med nfsstat -m i stedet for fstab-linjen, og bekreft VPN-transporten fra profilen som faktisk brukes.

Skriv dem deretter i hendelsesnotatene som to separate felt. En tilsynelatende forbedring kan bare spores hvis notatet sier hvilket lag som ble endret.

Bla gjennom er ikke masselesing

En mappeliste beviser at noen operasjoner ble fullført. Det beviser ikke at en vedvarende lesing, en skriving, en lås eller lagerbackend vil fullføres under de samme forholdene. Et stopp midt i en stor fil er en annen observasjon enn et mount som aldri lykkes, og de peker på forskjellige lag.

Beskriv operasjonen som feiler presist: sti, retning, omtrentlig punkt for stoppet og den siste relevante hendelsen i loggene til klienten, serveren og VPN. Sammenlign deretter hvor trafikken fortsetter og hvor den stopper.

MTU er en hypotese, ikke en diagnose

Pakningsstørrelsesavhengig tap er en reell mulighet når en tunnel bærer store segmenter, og det gir nøyaktig mønsteret der bla gjennom fungerer og lesing stopper. Det mønsteret beviser likevel ikke et MTU-problem, fordi samme form vises når en server er treg, når en brannmur avslutter en langvarig forbindelse på timeout, eller når en disk er opptatt. Test hypotesen med en kontrollert prøve i stedet for å senke MTU overalt og erklære seier.

En timeout i seg selv sier ingenting om hvorvidt UDP bør byttes ut. Det er et symptom med flere mulige eiere.

Endre én variabel om gangen

Når du sammenligner transportlag, hold NFS-arbeidsbelastningen og alle andre innstillinger stabile. Å endre mount-transporten, tunnelprotokollen og MTU i samme vedlikeholdsvindu gir et resultat ingen kan tilskrive. Kjør den samme filoperasjonen før og etter, og noter resultatet ved hvert steg.

Ta vare på de tidligere verdiene i saken også. Hvis en endring gjør ting verre, bør tilbakerullingen være et dokumentert tall i stedet for noens erindring om hvordan det var før.

Les laget som feilet

Hvis tunnelen er oppe og NFS-forespørselen venter, feilet ikke VPN; filtjenesten gjorde det. Hvis tunnelen falt, er NFS-forespørselens fiasko en konsekvens og ikke en årsak. Å sammenholde logglinjer fra begge lag er den raskeste måten å skille de to tilfellene, og det slår å gjette fra filbehandleren.

Skriv konklusjonen som to setninger, én per lag. Det er nok til at neste person kan gjenskape testen uten å utlede på nytt hvilket transportlag som er hvilket.