ローカル機器がVPNで消える：三つの別々の故障

VPNを起動すると機器一覧から消えるプリンターでも、そのアドレスには応答することがある。一覧は検出によって埋められ、名前はリゾルバーから来ることがあり、サービス自体はソケットを通じて到達するので、この三つは独立して壊れうる。どの層で何が動くかを比べれば、どの機能を変えるべきかが分かる。先にローカルアクセスの例外をすべて有効にすると、証拠が消えてしまう。

それが、存在しない機器と、単に広告されていない機器の違いだ。

検出・名前・到達性は三つの層

検出プロトコルはマルチキャストやブロードキャストに依存し、これらは既定ではルーティングされたトンネルを越えないため、機器は一覧から消えても完全に到達可能なままでいられる。名前解決は二つ目の層で、VPNはリゾルバーを変えることがあり、以前はローカルネットワークが応答していた名前が今は別の場所で解決されたり、まったく解決されなかったりする。到達性は三つ目で、ルート、ファイアウォール規則、待ち受けるサービスからなる。ほかの二つが正常でも、各層は個別に壊れうる。

下から上へ試す。到達性の確認を一度行うだけで切り分けは明らかになり、nc -vz 192.168.1.20 443 が成功すれば経路とサービスは正常で容疑者は名前、失敗すれば問題はルーティングとポリシーに移る。次に名前を尋ねる。最初に当たる故障が取り組むべき層であり、その上の層では補えない。

まずアドレスを、次にホスト名を尋ねる

アドレスが応答して名前が応答しないなら、問題はルーティングではなく解決だ。独自のリゾルバーを導入するVPNクライアントはローカル名にどのサーバーが応答するかを変えうるし、ローカルドメインを転送しないクライアントは名前を無応答のままにする。アドレスも失敗するなら問題は経路で、トンネル経由の既定ルート、クライアント側のローカル通信ブロック、物理インターフェースだけを許可するファイアウォール規則のいずれかである。

両方動くのに自動検出が動かないなら、機器はトンネル越しに自分を広告していないだけだ。これはマルチキャストベースの検出では想定される挙動で、設定の失敗ではない。アドレスで機器を追加するのが、たいてい正直な解決策だ。

ローカルアクセスの切り替えが実際に変えるもの

ローカルネットワークアクセスの設定は通常、直接接続されたサブネット宛ての通信をトンネルから迂回させるもので、クライアントによって動作が異なる。リモートオフィスへの転送を設定するものではなく、ホストのファイアウォールやアプリ自身の権限を変えるものでもない。重複するサブネットを明確にするものでもない。広く有効にする前に、その設定が何を対象とするかをクライアントの文書で読むこと。

信頼できる一台だけの狭い例外は、包括的な許可より優れている。とくにブロックが意図的な場合もあるゲストネットワークではそうで、プライベートアドレスは身元確認ではないので、選択は自分がいるネットワーク次第である。

ネットワークが重複するとき

自宅ネットワークとリモートネットワークが同じ範囲を使うと、ルーティングは曖昧になり、ローカルアクセスの切り替えでも例外でも解決できない。同じアドレスの二つのサービスには両方到達できず、どちらが勝つかは意図ではなく、ルートの具体性と順序で決まる。解決策はアドレス設計であり、クライアント設定ではない。プリンターに一晩費やす前に、範囲を確認すること。

リモートゲートウェイの向こう側の機器では、転送、ホストポリシー、戻り経路は運用者のものだ。クライアントのローカルなチェックボックスではどれも提供できず、それを求めるほうが切り替えを試すより生産的である。

どの層が壊れたのか、何を変えたのかを記録する。次の機器も同じ三か所のどこかで壊れる。