NFS clientaddr over VPN: beslis op minorversie, niet op gewoonte

clientaddr is een van die mountopties die nog lang in een commandoregel wordt gekopieerd nadat de reden ervoor verdwenen is. Het vertelt een NFSv4.0-server waar hij de client terug moet roepen. Het kiest de server niet, bindt niet elk verzoek aan een bronadres en stuurt geen verkeer een tunnel in. Op een laptop met meerdere adressen zijn drie vragen nodig om te beslissen of het überhaupt geldt.

Drie voorwaarden bepalen of de optie ertoe doet

De eerste is de onderhandelde minorversie, omdat 4.1 en 4.2 callbacks verschillend afhandelen. De tweede is of de server het adres kan bereiken dat u zou adverteren; een gerouteerde tunnel staat dat meestal toe en een vertaald pad meestal niet. De derde is of de fout die u najaagt überhaupt een callbackfout is.

Ze in de verkeerde volgorde beantwoorden is hoe mensen een callbackadres aan een 4.2-mount toevoegen en concluderen dat de optie kapot is.

Lees eerst de minorversie

nfsstat -m

Voor een bestaande mount drukt dit de mountinformatie en vlaggen af, inclusief de effectieve versie als vers=4.0, vers=4.1 of vers=4.2. Een notitie die alleen “NFSv4” zegt, laat het ene detail weg dat bepaalt of deze optie relevant is. Lees het getal, niet het woord.

Als de versietekst van een serverstandaard komt en niet van uw commandoregel, vraag dan welke minorversie is onderhandeld. Een server kan een hogere minorversie weigeren en terugvallen, en juist die terugval is het geval waarin een callback plotseling telt. De mountregel die u schreef beschrijft misschien niet de mount die u hebt.

Adverteer voor 4.0 een adres dat de server kan bereiken

Een NFSv4.0-server kan een aparte verbinding terug naar de client nodig hebben, bijvoorbeeld wanneer hij een delegatie terugroept. Met meerdere interfaces of een ongebruikelijke routingtabel kan de automatische ontdekking van een callbackadres er een kiezen die de server niet kan gebruiken.

mount -t nfs -o vers=4.0,clientaddr=10.8.0.6 10.8.0.1:/export /mnt/share

Het adres vóór de dubbele punt is de server en blijft de bestemming. Het callbackadres hoort bij de client en moet bereikbaar zijn vanaf de serverkant van de tunnel. Een loopbackadres wijst de server terug naar zichzelf. Een privé-clientadres zonder retourroute is net zo onbruikbaar, ook al ziet het er op de client correct uit.

Gebruik dit als illustratie, niet als reden om een werkende mount te verlagen. Vervang de adressen en het exportpad en houd de authenticatie en andere opties die de server vereist. Ze weglaten om één voorbeeld te laten passen is een andere wijziging met een ander resultaat, en op een server die een beveiligingstype afdwingt faalt het voordat een callback wordt geprobeerd.

4.1 en 4.2 gebruiken de optie niet

Linux NFSv4.1 en 4.2 dragen callbacks over verbindingen die de client heeft opgezet, en 4.1 noemt die voorziening de backchannel. Ze zijn er niet van afhankelijk dat de server een nieuwe verbinding naar een geadverteerd adres opent, dus clientaddr herstelt geen callbackpad van 4.1 of 4.2.

Dat betekent niet dat 4.1 en 4.2 geen callbackproblemen hebben. Het betekent dat de diagnose anders is: onderzoek de opgezette sessie en de staat van de backchannel in plaats van te zoeken naar een inkomende callbackpoort die nooit had moeten bestaan. Een ontbrekende inkomende regel is de verwachte toestand, geen fout om te corrigeren.

Scheid een mountfout van een callbackfout

Stel eerst vast of de client de NFS-dienst bereikt en of de server de export en het authenticatieverzoek accepteert. Een time-out vóór die uitwisseling zegt niets over een callbackadres. Eén wijzigen terwijl de mount nog steeds mislukt brengt het onderzoek niet dichterbij, en het verbergt de oorspronkelijke fout achter een nieuwe mountoptie.

Pas wanneer het bewijs een mislukte 4.0-callback toont, doet het geadverteerde adres ertoe, samen met het retourpad van de server, de listener aan de clientkant en enige filtering daartussen. Het getal in de mountoptie wijzigen kan die paden niet creëren; het kan alleen naar een bestaand pad wijzen. Schrijf op welke van die vier u hebt geverifieerd, want het volgende rapport komt zonder een ervan.

Een NFS-root bij vroege opstart is een aparte omgeving met eigen voorwaarden: de initramfs heeft de hulpmiddelen en het netwerk nodig voordat de mount kan plaatsvinden. Een mount die na aanmelding werkt, bewijst niets over die volgorde, en de fout bij het opstarten noemt zelden de initramfs of het netwerk.