NFS clientaddr su VPN: decidere per la versione minore, non per abitudine
clientaddr annuncia un indirizzo di richiamata solo per NFSv4.0. Leggete la versione minore negoziata, controllate il percorso di ritorno e separatelo dagli errori di mount.
clientaddr è una di quelle opzioni di mount che vengono copiate in una riga di comando molto tempo dopo che la ragione è sparita. Dice a un server NFSv4.0 dove richiamare il client. Non sceglie il server, non lega ogni richiesta a un indirizzo sorgente e non spinge il traffico in un tunnel. Su un portatile con più indirizzi, per decidere se si applica del tutto servono tre domande.
Tre condizioni decidono se l’opzione conta
La prima è la versione minore negoziata, perché 4.1 e 4.2 gestiscono le richiamate in modo diverso. La seconda è se il server può raggiungere l’indirizzo che annuncereste, cosa che un tunnel instradato di solito consente e un percorso tradotto di solito no. La terza è se l’errore che state inseguendo è davvero un errore di richiamata.
| Condition | If yes | If no |
|---|---|---|
| Version is 4.0 | The option can matter | Skip it; inspect the session instead |
| Server can reach the address | Advertise it | Fix reachability first |
| Failure is a callback | Diagnose callback path | Look at mount and export |
Rispondere fuori ordine è il modo in cui la gente finisce per aggiungere un indirizzo di richiamata a un mount 4.2 e concludere che l’opzione è rotta.
Leggete prima la versione minore
nfsstat -mPer un mount esistente, questo stampa le informazioni e i flag del mount, inclusa la versione effettiva come vers=4.0, vers=4.1 o vers=4.2. Una nota che dice solo “NFSv4” omette l’unico dettaglio che decide se questa opzione è pertinente. Leggete il numero, non la parola.
Se la stringa di versione proviene da un valore predefinito del server e non dalla vostra riga di comando, chiedete quale versione minore è stata negoziata. Un server può rifiutare una versione minore superiore e ripiegare, e proprio quel ripiego è il caso in cui una richiamata conta all’improvviso. La riga di mount che avete scritto potrebbe non descrivere il mount che avete.
Per 4.0, annunciate un indirizzo che il server può raggiungere
Un server NFSv4.0 può aver bisogno di una connessione separata verso il client, per esempio quando richiama una delega. Con più interfacce o una tabella di routing inusuale, la scoperta automatica di un indirizzo di richiamata può sceglierne uno che il server non può usare.
mount -t nfs -o vers=4.0,clientaddr=10.8.0.6 10.8.0.1:/export /mnt/shareL’indirizzo prima dei due punti è il server e resta la destinazione. L’indirizzo di richiamata appartiene al client e deve essere raggiungibile dal lato server del tunnel. Un indirizzo di loopback rimanda il server a se stesso. Un indirizzo privato del client senza rotta di ritorno è altrettanto inutilizzabile, anche se sul client sembra corretto.
Usatelo come illustrazione, non come motivo per declassare un mount funzionante. Sostituite gli indirizzi e il percorso di export, e conservate l’autenticazione e le altre opzioni richieste dal server. Ometterle per far stare un esempio è un’altra modifica con un altro risultato, e su un server che impone un tipo di sicurezza fallisce prima che si tenti qualsiasi richiamata.
4.1 e 4.2 non usano l’opzione
Linux NFSv4.1 e 4.2 trasportano le richiamate su connessioni stabilite dal client, e 4.1 chiama questo meccanismo il backchannel. Non dipendono dall’apertura da parte del server di una nuova connessione verso un indirizzo annunciato, quindi clientaddr non ripara un percorso di richiamata 4.1 o 4.2.
Ciò non significa che 4.1 e 4.2 non abbiano problemi di richiamata. Significa che la diagnosi è diversa: esaminate la sessione stabilita e lo stato del suo backchannel invece di cercare una porta di richiamata in ingresso che non sarebbe mai dovuta esistere. Una regola in ingresso mancante è lo stato atteso, non un difetto da correggere.
Sepate un errore di mount da un errore di richiamata
Stabilite prima se il client raggiunge il servizio NFS e se il server accetta l’export e la richiesta di autenticazione. Un timeout prima di quello scambio non dice nulla su un indirizzo di richiamata. Cambiarne uno mentre il mount continua a fallire non avvicina l’indagine e nasconde l’errore originale dietro una nuova opzione di mount.
Solo quando le prove mostrano una richiamata 4.0 fallita l’indirizzo annunciato conta, insieme al percorso di ritorno del server, all’ascoltatore lato client e a qualsiasi filtraggio tra loro. Cambiare il numero nell’opzione di mount non può creare quei percorsi; può solo puntare a uno che esiste già. Annotate quale di quei quattro avete verificato, perché il prossimo rapporto arriverà senza nessuno di essi.
Una radice NFS all’avvio iniziale è un ambiente a parte con i propri prerequisiti: l’initramfs ha bisogno degli strumenti e della rete prima che il mount possa avvenire. Un mount che funziona dopo l’accesso non dimostra nulla su quella sequenza, e l’errore all’avvio raramente menziona l’initramfs o la rete.