OpenVPN の UDP トンネル内で TCP を使う NFS：二つの転送

UDP を運ぶトンネルの中で TCP を使う NFS の会話を運ぶことは、二つの転送を同時に名指しするために人を混乱させるものの、まったく矛盾していません。TCP はクライアントと NFS サーバーの間のファイルサービスの会話です。UDP は VPN の端点の間の暗号化された回線です。どちらも他方について何も含意しません。

デバッグを始める前に両方を別々に書き留めてください——障害の多くは、誰かが間違った層を変えることから始まります。

二つの層、二つの設定

マウントオプション proto=tcp は、NFS クライアントが NFS サーバーとどう話すかを表します。VPN プロファイルの proto udp 設定は、トンネルの端点がカプセル化されたパケットをどう交換するかを表します。マウントオプションを変えてもトンネルは変わりませんし、トンネルの転送を変えても、NFS クライアントが合意した内容は変わりません。有効なマウントオプションは fstab の行ではなく nfsstat -m で確認し、VPN の転送は実際に使われているプロファイルで確認してください。

そのうえで、両方を別々の項目として障害記録に残します。見かけの改善は、どの層が変わったかを記録が示す場合にだけ追跡できます。

閲覧は一括読み取りではない

ディレクトリの一覧は、一部の操作が完了したことを証明します。持続的な読み取り、書き込み、ロック、あるいは記憶域のバックエンドが同じ条件で完了することを証明するものではありません。大きなファイルの途中での停止は、決して成功しないマウントとは別の観察であり、指し示す層も異なります。

失敗している操作を正確に書き留めてください。パス、方向、停止のおおよその位置、クライアント、サーバー、VPN のログにある最後の関連イベントを記録し、そのうえで通信が続く場所と止まる場所を比べます。

MTU は仮説であり、診断ではない

トンネルが大きなセグメントを運ぶとき、パケットサイズに依存する損失は現実的な可能性であり、閲覧はできるが読み取りで止まるという型をまさに生み出します。しかしその型は MTU の問題を証明しません——サーバーが遅いとき、ファイアウォールが長時間の接続をタイムアウトで切るとき、ディスクが混んでいるときにも同じ形が現れるからです。どこでも MTU を下げて勝利を宣言するのではなく、統制のとれた検査で仮説を試してください。

タイムアウトそれ自体は、UDP を入れ替えるべきかどうかについて何も語りません。それは複数の持ち主がありうる症状です。

一度に一つの変数だけを変える

転送を比べるときは、NFS の作業負荷と他のすべての設定を一定に保ってください。同じ保守時間帯にマウントの転送、トンネルのプロトコル、MTU を変えると、誰にも原因を帰せない結果になります。同じファイル操作を変更の前後で実行し、各段階で結果を記録します。

以前の値もチケットに残してください。変更で状況が悪化したとき、切り戻しは文書化された数値であるべきで、以前どうだったかという誰かの記憶ではありません。

失敗した層を読む

トンネルが生きていて NFS の要求が待っているなら、VPN は失敗していません——失敗したのはファイルサービスです。トンネルが落ちたなら、NFS の要求の失敗は原因ではなく結果です。二つの層のログ行を突き合わせることが、この二つの場合を区別する最速の方法であり、ファイルマネージャーから推測するより優れています。

結論は層ごとに一文ずつ、二文で書いてください。それだけで、次に読む人はどちらの転送がどちらかを導き直さずに試験を再現できます。