VPN 越しの NFS clientaddr：習慣ではなくマイナー版で判断する
clientaddr がコールバックアドレスを通知するのは NFSv4.0 だけです。ネゴシエートされたマイナー版を読み、戻り経路を確認し、マウントの失敗と切り分けてください。
clientaddr は、理由が消えたずっと後になってもコマンドラインにコピーされ続けるマウントオプションの一つです。NFSv4.0 サーバーに、クライアントをどこへ呼び戻すかを伝えます。サーバーを選ぶわけでも、すべての要求を送信元アドレスに束縛するわけでも、トラフィックをトンネルに流し込むわけでもありません。複数のアドレスを持つノート PC では、そもそも適用されるのかを決めるのに三つの問いが必要です。
三つの条件が、このオプションが重要かどうかを決める
一つ目は、4.1 と 4.2 でコールバックの扱いが違うため、ネゴシエートされたマイナー版です。二つ目は、通知しようとするアドレスにサーバーが到達できるかどうかで、ルーティングされたトンネルなら通常は可能で、変換された経路なら通常は不可能です。三つ目は、追っている障害がそもそもコールバックの障害なのかどうかです。
| 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 |
順序を間違えて答えると、人は 4.2 のマウントにコールバックアドレスを足して、オプションが壊れていると結論づけます。
まずマイナー版を読む
nfsstat -m既存のマウントでは、これはマウント情報とフラグを出力し、有効なバージョンを vers=4.0、vers=4.1、vers=4.2 として示します。 “NFSv4” とだけ書かれたメモは、このオプションが関係するかを決める唯一の詳細を落としています。言葉ではなく数字を読んでください。
バージョン文字列がコマンドラインではなくサーバーの既定値から来た場合は、どのマイナー版でネゴシエートされたかを尋ねてください。サーバーはより高いマイナー版を拒否してフォールバックすることがあり、そのフォールバックこそがコールバックが急に重要になるケースです。書いたマウント行が、実際のマウントを表していないかもしれません。
4.0 では、サーバーが到達できるアドレスを通知する
NFSv4.0 サーバーは、たとえば委任を回収するときに、クライアントへ戻る別の接続を必要とすることがあります。複数のインターフェースや普通ではないルーティングテーブルがあると、コールバックアドレスの自動検出が、サーバーに使えないものを選ぶことがあります。
mount -t nfs -o vers=4.0,clientaddr=10.8.0.6 10.8.0.1:/export /mnt/shareコロンの前のアドレスはサーバーで、宛先のままです。コールバックアドレスはクライアントに属し、トンネルのサーバー側から到達できなければなりません。ループバックアドレスはサーバーを自分自身へ向けます。戻り経路のないプライベートなクライアントアドレスも、クライアント側では正しく見えても同じく使えません。
動作しているマウントを降格する理由ではなく、あくまで例として使ってください。アドレスとエクスポートパスを置き換え、サーバーが要求する認証やその他のオプションは保ってください。一つの例に合わせるためにそれらを落とすのは別の結果を生む別の変更で、セキュリティ種別を強制するサーバーではコールバックを試みる前に失敗します。
4.1 と 4.2 はこのオプションを使わない
Linux の NFSv4.1 と 4.2 は、クライアントが確立した接続の上でコールバックを運び、4.1 はその仕組みをバックチャネルと呼びます。サーバーが通知されたアドレスへ新しい接続を開くことには依存しないので、clientaddr は 4.1 や 4.2 のコールバック経路を修復しません。
だからといって、4.1 と 4.2 にコールバックの問題がないわけではありません。診断が違うという意味で、存在するはずのなかった着信コールバックポートを探すのではなく、確立されたセッションとそのバックチャネルの状態を調べてください。着信ルールがないのは想定された状態で、直すべき障害ではありません。
マウントの失敗とコールバックの失敗を切り分ける
まず、クライアントが NFS サービスに到達するか、サーバーがエクスポートと認証要求を受け入れるかを確かめてください。そのやり取りの前のタイムアウトは、コールバックアドレスについて何も語りません。マウントがまだ失敗している間に一方を変えても調査は進まず、元のエラーが新しいマウントオプションの陰に隠れます。
証拠が 4.0 のコールバックの失敗を示したときにだけ、通知されたアドレスが、サーバーの戻り経路、クライアント側のリスナー、そして両者の間のあらゆるフィルタリングとともに重要になります。マウントオプションの数字を変えてもそれらの経路は作れず、すでにある経路を指せるだけです。次の報告はそのどれも伴わずに届くので、四つのうちどれを確認したかを書き留めてください。
起動初期の NFS ルートは、マウントが起きる前に initramfs へツールとネットワークを必要とする、独自の前提を持つ別の環境です。ログイン後に動くマウントはその順序について何も証明せず、起動時の失敗は initramfs にもネットワークにも触れないことがほとんどです。