NFS über TCP in einem OpenVPN-UDP-Tunnel: zwei Transportschichten

Eine NFS-Konversation, die TCP verwendet, in einem Tunnel zu führen, der UDP trägt, ist völlig stimmig, und es verwirrt Menschen, weil dabei zwei Transportwege gleichzeitig benannt werden. TCP ist die Konversation des Dateidienstes zwischen dem Client und dem NFS-Server. UDP ist der verschlüsselte Träger zwischen den VPN-Endpunkten. Keiner von beiden sagt etwas über den anderen aus.

Schreiben Sie beides getrennt auf, bevor Sie irgendetwas debuggen; die meisten dieser Vorfälle beginnen damit, dass jemand die falsche Schicht ändert.

Zwei Schichten, zwei Einstellungen

Die Mount-Option proto=tcp beschreibt, wie der NFS-Client mit dem NFS-Server spricht. Die Einstellung proto udp im VPN-Profil beschreibt, wie die Tunnel-Endpunkte gekapselte Pakete austauschen. Eine Mount-Option zu ändern, ändert den Tunnel nicht, und den Transport des Tunnels zu ändern, ändert nicht, was der NFS-Client ausgehandelt hat. Bestätigen Sie die wirksamen Mount-Optionen mit nfsstat -m statt anhand der fstab-Zeile, und bestätigen Sie den VPN-Transport aus dem Profil, das tatsächlich verwendet wird.

Tragen Sie beides dann in den Vorfallnotizen als zwei getrennte Felder ein. Eine scheinbare Verbesserung lässt sich nur nachvollziehen, wenn die Notiz angibt, welche Schicht geändert wurde.

Durchblättern ist kein Massenlesen

Eine Verzeichnisauflistung belegt, dass einige Vorgänge abgeschlossen wurden. Sie belegt nicht, dass ein länger dauerndes Lesen, ein Schreiben, eine Sperre oder das Speicher-Backend unter denselben Bedingungen abschließen. Ein Stillstand mitten in einer großen Datei ist eine andere Beobachtung als ein Mount, der nie gelingt, und sie deuten auf unterschiedliche Schichten hin.

Beschreiben Sie den fehlschlagenden Vorgang präzise: Pfad, Richtung, ungefährer Punkt des Stillstands und das letzte relevante Ereignis in den Protokollen von Client, Server und VPN. Vergleichen Sie dann, wo der Datenverkehr weiterläuft und wo er stoppt.

MTU ist eine Hypothese, keine Diagnose

Paketgrößenabhängiger Verlust ist eine reale Möglichkeit, wenn ein Tunnel große Segmente trägt, und er erzeugt genau das Muster, dass Surfen funktioniert und Lesen hängen bleibt. Dieses Muster beweist jedoch kein MTU-Problem, denn dieselbe Form erscheint, wenn ein Server langsam ist, eine Firewall eine langlebige Verbindung per Timeout beendet oder eine Festplatte beschäftigt ist. Prüfen Sie die Hypothese mit einer kontrollierten Messung, statt überall die MTU zu senken und den Sieg zu erklären.

Ein Timeout allein sagt nichts darüber aus, ob UDP ausgetauscht werden sollte. Es ist ein Symptom mit mehreren möglichen Verursachern.

Ändern Sie jeweils eine Variable

Halten Sie beim Vergleichen von Transporten die NFS-Last und jede andere Einstellung stabil. Wenn Sie den Mount-Transport, das Tunnel-Protokoll und die MTU im selben Wartungsfenster ändern, erhalten Sie ein Ergebnis, das niemand zuordnen kann. Führen Sie denselben Dateivorgang vorher und nachher aus und halten Sie das Ergebnis bei jedem Schritt fest.

Bewahren Sie auch die bisherigen Werte im Ticket auf. Wenn eine Änderung die Lage verschlechtert, sollte der Rückfallweg eine dokumentierte Zahl sein und nicht jemandes Erinnerung daran, wie es früher war.

Lesen Sie die Schicht, die fehlgeschlagen ist

Wenn der Tunnel steht und die NFS-Anfrage wartet, ist nicht das VPN fehlgeschlagen, sondern der Dateidienst. Wenn der Tunnel abgebrochen ist, ist das Scheitern der NFS-Anfrage eine Folge und keine Ursache. Abgeglichene Protokollzeilen aus beiden Schichten sind der schnellste Weg, diese beiden Fälle zu unterscheiden, und das ist besser als Raten aus dem Dateimanager.

Schreiben Sie die Schlussfolgerung als zwei Sätze, einen pro Schicht. Das genügt, damit die nächste Person den Test nachvollziehen kann, ohne erneut herzuleiten, welcher Transport welcher ist.