NFS över TCP inuti en OpenVPN UDP-tunnel: två transportlager

Att föra en NFS-konversation som använder TCP inuti en tunnel som bär UDP är helt konsekvent, och det förvirrar folk eftersom det namnger två transportlager samtidigt. TCP är filtjänstens konversation mellan klienten och NFS-servern. UDP är den krypterade bäraren mellan VPN-slutpunkterna. Ingen av dem säger något om den andra.

Skriv ned båda var för sig innan du felsöker något; de flesta av dessa incidenter börjar med att någon ändrar fel lager.

Två lager, två inställningar

Mountinställningen proto=tcp beskriver hur NFS-klienten talar med NFS-servern. Inställningen proto udp i VPN-profilen beskriver hur tunnelns slutpunkter utbyter inkapslade paket. Att ändra en mountinställning ändrar inte tunneln, och att ändra tunnelns transport ändrar inte det NFS-klienten har förhandlat. Verifiera de effektiva mountinställningarna med nfsstat -m i stället för fstab-raden, och verifiera VPN-transporten från profilen som faktiskt används.

Anteckna dem sedan i incidentanteckningarna som två separata fält. En skenbar förbättring går bara att spåra om anteckningen anger vilket lager som ändrades.

Bläddra är inte massläsning

En kataloglista bevisar att vissa operationer slutfördes. Den bevisar inte att en uthållig läsning, en skrivning, ett lås eller lagringsbackend kommer att slutföras under samma förhållanden. Ett stopp halvvägs genom en stor fil är en annan observation än en mount som aldrig lyckas, och de pekar på olika lager.

Beskriv operationen som misslyckas exakt: sökväg, riktning, ungefärlig punkt för stoppet och den senaste relevanta händelsen i loggarna för klienten, servern och VPN. Jämför sedan var trafiken fortsätter och var den stannar.

MTU är en hypotes, inte en diagnos

Paketstorleksberoende förlust är en reell möjlighet när en tunnel bär stora segment, och det ger exakt mönstret där bläddring fungerar och läsning fastnar. Det mönstret bevisar dock inte ett MTU-problem, eftersom samma form dyker upp när en server är långsam, när en brandvägg avslutar en långvarig anslutning på grund av timeout, eller när en disk är upptagen. Testa hypotesen med ett kontrollerat prov i stället för att sänka MTU överallt och utropa seger.

En timeout i sig säger ingenting om huruvida UDP bör bytas ut. Det är ett symptom med flera möjliga ägare.

Ändra en variabel i taget

När du jämför transportlager, håll NFS-arbetsbelastningen och alla andra inställningar stabila. Att ändra mounttransporten, tunnelprotokollet och MTU i samma underhållsfönster ger ett resultat som ingen kan tillskriva. Kör samma filoperation före och efter, och anteckna resultatet vid varje steg.

Spara även de tidigare värdena i ärendet. Om en ändring förvärrar läget bör återgången vara ett dokumenterat tal och inte någons minne av hur det var tidigare.

Läs lagret som misslyckades

Om tunneln är uppe och NFS-begäran väntar har VPN inte misslyckats; filtjänsten har. Om tunneln föll är NFS-begärans misslyckande en följd och inte en orsak. Att matcha loggrader från båda lagren är det snabbaste sättet att skilja dessa två fall, och det slår att gissa utifrån filhanteraren.

Skriv slutsatsen som två meningar, en per lager. Det räcker för att nästa person ska kunna upprepa testet utan att härleda på nytt vilket transportlager som är vilket.