NFS su TCP dentro un tunnel UDP OpenVPN: due trasporti

Portare una conversazione NFS che usa TCP dentro un tunnel che trasporta UDP è del tutto coerente, e confonde le persone perché nomina due trasporti insieme. TCP è la conversazione del servizio file tra il client e il server NFS. UDP è il trasporto cifrato tra gli estremi del VPN. Nessuno dei due implica nulla sull’altro.

Annotate entrambi separatamente prima di fare qualsiasi debug; la maggior parte di questi incidenti inizia quando qualcuno cambia lo strato sbagliato.

Due strati, due impostazioni

L’opzione di mount proto=tcp descrive come il client NFS parla con il server NFS. L’impostazione proto udp del profilo VPN descrive come gli estremi del tunnel si scambiano i pacchetti incapsulati. Cambiare un’opzione di mount non cambia il tunnel, e cambiare il trasporto del tunnel non cambia ciò che il client NFS ha negoziato. Verificate le opzioni di mount effettive con nfsstat -m invece che con la riga di fstab, e verificate il trasporto del VPN dal profilo realmente in uso.

Poi annotatele nelle note dell’incidente come due campi separati. Un miglioramento apparente è tracciabile solo se la nota indica quale strato è cambiato.

Sfogliare non è una lettura massiva

Un elenco di directory dimostra che alcune operazioni sono state completate. Non dimostra che una lettura prolungata, una scrittura, un lock o il backend di archiviazione si completeranno nelle stesse condizioni. Un blocco a metà di un file grande è un’osservazione diversa da un mount che non riesce mai, e puntano a strati diversi.

Descrivete con precisione l’operazione che fallisce: percorso, direzione, punto approssimativo del blocco e ultimo evento rilevante nei log del client, del server e del VPN. Poi confrontate dove il traffico continua e dove si ferma.

L’MTU è un’ipotesi, non una diagnosi

Una perdita dipendente dalla dimensione dei pacchetti è una possibilità reale quando un tunnel trasporta segmenti grandi, e produce esattamente il pattern in cui la navigazione funziona e la lettura si blocca. Quel pattern però non dimostra un problema di MTU, perché la stessa forma compare quando un server è lento, quando un firewall chiude per timeout una connessione di lunga durata o quando un disco è occupato. Verificate l’ipotesi con una sonda controllata invece di abbassare l’MTU ovunque e dichiarare vittoria.

Un timeout da solo non dice nulla sulla necessità di sostituire UDP. È un sintomo con diversi possibili responsabili.

Cambiate una variabile alla volta

Quando confrontate trasporti, mantenete stabili il carico NFS e ogni altra impostazione. Cambiare il trasporto di mount, il protocollo del tunnel e l’MTU nella stessa finestra di manutenzione produce un risultato che nessuno può attribuire. Eseguite la stessa operazione sui file prima e dopo, e registrate l’esito a ogni passo.

Conservate anche i valori precedenti nel ticket. Se una modifica peggiora le cose, il ritorno indietro dovrebbe essere un numero documentato e non il ricordo di qualcuno di com’era prima.

Leggete lo strato che ha fallito

Se il tunnel è attivo e la richiesta NFS attende, il VPN non ha fallito; ha fallito il servizio file. Se il tunnel è caduto, il fallimento della richiesta NFS è una conseguenza e non una causa. Confrontare le righe di log dei due strati è il modo più rapido per distinguere questi due casi, ed è meglio che indovinare dal gestore di file.

Scrivete la conclusione in due frasi, una per strato. Questo basta a chi viene dopo per riprodurre il test senza rideterminare quale trasporto sia quale.