NFS bakom en VPN: montering vid start eller automatisk montering vid behov?

Två konfigurationer löser samma problem och misslyckas i motsatta riktningar. Att montera delningen vid start ger varje tjänst ett filsystem som antingen finns där eller en anledning till varför starten stannade. En automatisk montering vid behov ger maskinen en snabb start och lämnar väntan till den som först rör vid sökvägen. Bakom en VPN är den andra oftast den bättre affären, och skälet är att tunneln påtvingar en ordning som startsekvensen inte kan se.

Montering vid start kontra automatisk montering

En montering vid start är lätt att tänka igenom. Filsystemsmålet väntar på monteringen, tjänster som deklarerar beroende av den startar efteråt, och om servern inte nås väntar maskinen eller misslyckas beroende på alternativen. Allt nedströms ärver det enda beslutet.

En automatisk montering vänder på det. Sökvägen finns direkt, den egentliga monteringen sker när något öppnar den, och tjänster som startar tidigt blockeras inte på en tunnel som ännu inte är uppe.

Jämförelsen handlar om vem som ska absorbera fördröjningen. En arbetsstation som behöver delningen innan användaren kan arbeta bör nog vänta. En bärbar dator som startar i en väska, eller en server vars delning är valfri, bör inte.

Inget av alternativen reparerar en saknad rutt. Båda avgör bara när felet observeras.

fstab-raden, alternativ för alternativ

Anta att en befintlig OpenVPN-klientinstans är [email protected], att servern är files.corp.example och att monteringspunkten är /mnt/work. Ersätt alla tre med de auktoriserade värdena från din egen anläggning. En användbar rad ser ut så här:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev markerar monteringen som nätverkskrävande, och den namnger ingen tunnel alls. nofail håller delningen valfri för det vanliga filsystemsmålet. x-systemd.automount skapar utlösaren vid behov i stället för att montera direkt.

x-systemd.requires= är delen som binder monteringsförsöket till VPN-enheten, och den hör till monteringsoperationen, inte till utlösaren. Att lägga bred ordning på själva den automatiska monteringsenheten är sättet folk skapar cykler som systemd sedan klagar på i ett språk ingen läser två gånger.

x-systemd.mount-timeout=30s begränsar det inledande monteringskommandot. Det begränsar inget som händer efteråt, och det är det vanligaste missförståndet om det här alternativet.

Vad «startad» inte betyder

Kontrollera vad aktiv betyder för den VPN-enhet du namngav. En tunneltjänst kan rapportera sig som startad innan rutten till filservern finns eller innan det privata namnet löses upp, och att ordna efter den köper dig då ingenting. Det är i detta gap nästan varje misslyckat försök bor. Det är också osynligt om du inte tittar på rutten och resolvern i stället för enhetens tillstånd.

Använd anslutningens ägares egen beredskapssignal som ytterligare förutsättning där en finns. En fast sömn är en gissning som fungerar på ditt skrivbord och misslyckas i ett långsammare nätverk eller efter en återanslutning.

Undersök de genererade enheterna för sökvägen i exemplet: mnt-work.automount och mnt-work.mount. Efter en granskad fstab-ändring, ladda om systemd och hantera dessa enheter direkt i stället för att köra ett brett monteringskommando som övar på orelaterade poster.

En varning till hör hemma här. En tjänst som rör /mnt/work vid start utlöser fortfarande monteringen och väntar fortfarande på den, så att markera delningen som valfri gör inte varje program tålmodigt.

Efter monteringen är det ett annat fel

När NFS är monterat styr filsystemets återförsöks- och återhämtningsbeteende vad ett senare avbrott gör med en läsning eller en skrivning. Tidsgränsen för montering du satte har inget inflytande på det.

En mjuk montering förkortar vissa väntetider och ändrar felsemantiken, med dataintegritetskonsekvenser som är lätta att förbise när målet är en snabbare start. Att välja den för att vinna två sekunders starttid är sällan en bra affär. Om kravet verkligen är en avgränsad operation under ett avbrott är det ett beslut på programnivå, inte en fstab-flagga.

Bestäm vad som ska hända med en process som är mitt i en skrivning när tunneln faller, och skriv ned det. Det svaret är mer användbart än någon alternativsträng.

Testa fyra tillstånd, inte ett

En normal start med tunneln tillgänglig är det lätta fallet och bevisar nästan ingenting. Det bekräftar att strängen är rätt stavad och inget mer. Testa den första åtkomsten utan VPN, sedan återhämtningen när den kommer upp, sedan ett kontrollerat avbrott efter en lyckad montering.

Fyra tillstånd, fyra observationer, och anteckningarna går bredvid fstab-posten. Nästa person ärver beteende i stället för en konfiguration de måste rekonstruera.