VPNハンドシェイクの手順：トラフィックが流れる前に何が起きるか

接続ボタンを押すと、独立して成功または失敗する四つの作業が始まる。クライアントはリスナーに到達し、相手が誰かを合意し、鍵を導出し、そのうえで動作するトンネルをシステムの残りに引き渡す必要がある。失敗した接続の多くは間違った作業で診断される。だから最初のエラーは三回目の再試行より重要である。

まずリスナーに到達する

IDが交換される前に、クライアントは名前を解決し、ルートを選び、ポートへのトランスポートを開く。すべてに応答するキャプティブポータル、閉じたポート、誤ったホスト名はどれもここで失敗し、いずれも認証の問題ではない。パスワードを変えても三つのどれも直らない。資格情報に触れる前に、エラーの最初の行を読むこと。

タイムアウト、証明書の拒否、アカウントの拒否は、三つの異なる検査を要する三つの異なる障害である。まずこれらを切り分けることが、ネットワークの問題を資格情報の問題としてデバッグしてしまうのを防ぐ。

相手を証明し、それから鍵を導出する

どのプロトコルも、設定された公開鍵か証明書チェーンによって、意図したサーバーを認識する手段を必要とする。ユーザーログインはその検査への追加であって、代替ではない。パスワードを受け入れるサーバーは、自分自身の身元について何も証明していない。だからクライアントに入力した共有シークレットは、誰が応答したかの検証の代わりにならない。

次に交換はプロトコル自身の入力からトラフィック鍵を導出し、ログインパスワードは通常、各パケットに押される鍵ではない。長期的なID素材と短命なセッション鍵は、寿命も役割も異なる。前方秘匿性が扱うのはまさにこの分離である。

トラブルシューティング中は検証を有効にしておくこと。検査を無効にした後に接続するトンネルは、その検査が何かをしていたという以外に何も証明しておらず、変更した内容を記録して次のテストの前に元に戻すこと。

三つのプロトコル、三つの会話

TLSベースのOpenVPN展開では、制御チャネルがセキュリティパラメーターを交渉する一方でデータチャネルがトンネルのトラフィックを運ぶため、データチャネルのオプションと証明書の問題は別の場所に住んでいる。IKEv2は両方の参加者を認証し、その後で独自の寿命を持つIPsecセキュリティアソシエーションを確立する。WireGuardはNoiseベースの交換で鍵を導出し、状態機械を意図的に小さく保つ。三つのどれを動かしているかを知ることが、どのログを読む価値があるかを決める。

見た目が似たクライアントは、その下のメッセージが交換可能であることを意味せず、ある製品にある設定フィールドが別の製品に対応物を持たないこともある。両者の間でプロファイルをコピーすることは移行ではなく推測である。

ハンドシェイクがしないこと

ルート、名前解決、宛先ポリシーはいずれもその後に残る。相手が正しく認証されトンネルが上がっていても、サブネットのルートが欠けているために内部サイトへ到達できないことがある。それを弱い暗号化とみなすと誤った層を探すことになり、通常は何も直さない暗号方式の変更で終わる。

鍵の更新と再接続も、ほとんどの状態表示では同じように見え、どちらも停止中に通常のトラフィックが遮断されたかどうかを教えてくれない。その問いに答えるのはクライアントの失敗ポリシーだけなので、アイコンではなくポリシーを読むこと。

上の順序で段階を進め、最初にエラーを出す段階で停止する。後続の各段階は前の段階の状態を引き継ぐので、第三段階の失敗は第四段階について何も語らない。

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal