VPNリクエストが選ぶIPv6送信元と、それが重要な理由

VPNアドレスを追加し、リクエストがそれを使うと期待しましたが、サーバーは依然として古いプレフィックスを記録していました。トンネル側で何かが失敗したわけではなく、ホストは、あなたが睨んでいた経路を参照する前に、送信元アドレスの選択を済ませていたのです。IPv6の送信元選択は、ホストの候補アドレス同士による別個の順序立った競争であり、最長一致プレフィックスはその終盤にある一つの規則にすぎません。望む結果を得るには、どの規則がすでに勝ったのかを知る必要があります。規則そのものは退屈で厳密であり、順番に読むべき理由もそこにあります。

検索は二回、一回ではない

宛先の選択は次のホップと出力インターフェースを決めます。次に送信元の選択が、ホストのアドレスのどれをヘッダーに載せるかを決めますが、両方ともプレフィックスを使うのに、この二つの問いは別々の仕組みが答えます。物理アドレス、一時アドレス、VPNアドレスの三つを持つホストには、どの宛先に対しても候補が三つあり、VPNへ向かう経路が三番目を自動的に指名するわけではありません。

正しい経路と誤った送信元がこれほど簡単に同居するのはそのためで、同じリクエストがブラウザーからと強制バインドからで振る舞いを変えるのもそのためです。両者を結びつける証拠が得られるまで、二つの検索は別物として扱ってください。

規則を順序立った競争として読む

RFC 6724は規則を順に並べており、それぞれは前の規則が残した同点を崩すだけです。出力インターフェースの優先とラベルの一致は、プレフィックスの比較よりずっと前に現れ、したがって、経路が使うインターフェース上のアドレスは、より良いプレフィックス一致でも消せない優位をすでに得ています。非推奨とスコープも関与するため、古いアドレスが誰もポリシーを変えないまま選ばれなくなることがあります。

実務的な読み方は、宛先だけから勝者を推論することはできない、というものです。候補を列挙し、規則を順にたどり、決定が実際にどこで下されたのかを見てください。

これは問題のうち送信元側の半分だという点にも注意してください。二つのプレフィックス比較を混同すると、厳密に聞こえて誤ったアドレスを予測する説明が生まれます。チケットでプレフィックスという語を使うときは、どちらの比較を指すのかを明言してください。

アプリケーションのバインドが問いを変える

アプリケーションは特定の送信元アドレスを要求でき、有効な明示的選択は問いを「ホストはどのアドレスを好むか」から「そのアドレスは宛先に到達して戻れるか」へ移します。送信元にバインドするツールや、選ばれたアドレスについて補助データを求めるツールはこれを直接示し、接続が実際にどのアドレスを使ったかを証明する最速の方法になります。その実験は、設定した内容ではなく、カーネルが決めた内容を報告するため、経路表を三度読むより優れています。変更後に繰り返し、二つの答えを比べてください。

これにより送信元バインドは診断ツールであると同時に回避策にもなり、VPNアドレスにバインドしてリクエストが成功するかを見てください。成功すれば経路は正常で、問題は選択でした。失敗すれば、戻り経路か対向側のポリシーが最初から問題だったのです。

対向側がその送信元を受け入れるか確認する

ホストが何を選んでも、それはVPNの保護範囲と、対向側の戻り経路およびアクセス規則に適合しなければなりません。セレクターの外にある送信元はトンネルに入り、対向側で破棄されることがあり、これは片方向の障害に見えて経路制御のせいにされます。モードを変えても候補アドレスの中から選ばれるわけではないため、暗号化の設定に触れる前に、選ばれた内側の送信元と保護範囲を比較してください。

外側の端点アドレスも推論の中では別に扱ってください。それはVPN参加者間の転送を識別するものであり、内側のアプリケーションパケットの送信元ではありません。

四つの観察で判断する

使われた宛先、資格のあるローカル送信元、実際に選ばれた送信元、有効な出力経路を記録します。ほぼすべての事例を説明するのに四行で足り、理論を蒸し返さずに正常なホストと故障したホストを比較できます。実装が独自のローカルな優先順位を追加するため、選択の段階では、標準の名前ではなくオペレーティングシステム自身が対応する表示を使ってください。

答えがまだ意外なら、順序があなたの頭の中のモデルがしないことをしているのであり、対処はアルゴリズムと論争することではなく入力を変えることです。四つの観察をチケットに書き込めば、次の読み手があなたの結論を再現できます。