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

At føre en NFS-samtale, der bruger TCP, inde i en tunnel, der bærer UDP, er helt konsistent, og det forvirrer folk, fordi det navngiver to transportlag på én gang. TCP er filtjenestens samtale mellem klienten og NFS-serveren. UDP er den krypterede bærer mellem VPN-endepunkterne. Ingen af dem siger noget om den anden.

Skriv begge ned hver for sig, før du fejlfinder noget; de fleste af disse hændelser begynder med, at nogen ændrer det forkerte lag.

To lag, to indstillinger

Mount-indstillingen proto=tcp beskriver, hvordan NFS-klienten taler med NFS-serveren. Indstillingen proto udp i VPN-profilen beskriver, hvordan tunnelens endepunkter udveksler indkapslede pakker. At ændre en mount-indstilling ændrer ikke tunnelen, og at ændre tunnelens transport ændrer ikke det, NFS-klienten har forhandlet. Bekræft de effektive mount-indstillinger med nfsstat -m i stedet for fstab-linjen, og bekræft VPN-transporten ud fra den profil, der faktisk bruges.

Skriv dem derefter i hændelsesnotaterne som to separate felter. En tilsyneladende forbedring kan kun spores, hvis notatet siger, hvilket lag der blev ændret.

Gennemsyn er ikke masselæsning

En mappeliste beviser, at nogle operationer blev fuldført. Det beviser ikke, at en vedvarende læsning, en skrivning, en lås eller lagerbackend vil fuldføre under de samme forhold. En stilstand midt i en stor fil er en anden observation end et mount, der aldrig lykkes, og de peger på forskellige lag.

Beskriv den fejlende operation præcist: sti, retning, det omtrentlige punkt for stilstanden og den sidste relevante hændelse i klientens, serverens og VPN-loggen. Sammenlign derefter, hvor trafikken fortsætter, og hvor den stopper.

MTU er en hypotese, ikke en diagnose

Pakningsstørrelsesafhængigt tab er en reel mulighed, når en tunnel bærer store segmenter, og det giver præcis mønsteret, hvor gennemsyn virker, og læsning går i stå. Det mønster beviser dog ikke et MTU-problem, fordi den samme form vises, når en server er langsom, når en firewall lukker en langvarig forbindelse på timeout, eller når en disk er travl. Test hypotesen med en kontrolleret prøve i stedet for at sænke MTU overalt og erklære sejr.

En timeout i sig selv siger intet om, hvorvidt UDP skal skiftes ud. Det er et symptom med flere mulige ejere.

Ændr én variabel ad gangen

Når du sammenligner transportlag, skal NFS-arbejdsbelastningen og alle andre indstillinger holdes stabile. At ændre mount-transporten, tunnelprotokollen og MTU i samme vedligeholdelsesvindue giver et resultat, som ingen kan tilskrive. Kør den samme filoperation før og efter, og noter resultatet ved hvert trin.

Gem også de tidligere værdier i sagen. Hvis en ændring gør tingene værre, bør tilbagerulningen være et dokumenteret tal i stedet for nogens erindring om, hvordan det var før.

Læs det lag, der fejlede

Hvis tunnelen er oppe, og NFS-anmodningen venter, fejlede VPN ikke; filtjenesten gjorde. Hvis tunnelen faldt, er NFS-anmodningens fiasko en konsekvens snarere end en årsag. At sammenholde loglinjer fra begge lag er den hurtigste måde at skelne de to tilfælde, og det slår at gætte ud fra filhåndteringen.

Skriv konklusionen som to sætninger, én pr. lag. Det er nok til, at den næste person kan genskabe testen uden at udlede igen, hvilket transportlag der er hvilket.