VPN 経由の IPv6：委任されたプレフィックスはアドレスプールではない

同じ日に、トンネル越しの IPv6 を必要とするノートパソコンと、自社ルーターの背後の機器に IPv6 を望む小さな拠点から、二つの依頼が届きます。どちらもアドレスで答えられ、二つ目はそのあと一週間失敗し続けます。役割が異なり、仕組みも設定も、機能を証明する確認も異なります。この手順書は両者を切り離します。

ステップ一：どちらの役割を担うかを決める

単一のホストには、トンネルインターフェース上のアドレスが一つ必要で、遠い側への経路があり、下流に番号を振るものはありません。トンネルの背後のルーターには、配布できるネットワーク全体と、遠い側でそのアドレスを自分へ戻す経路が必要です。トンネルの背後に何があるかが、その後のすべての判断を左右します。

設定を開く前に、この問いに答えてください。このステップ以降のすべては、どちらの答えを出したかによって決まります。

ステップ二：単一ホストのアドレス割り当て

トンネルのアドレスを割り当て、製品が期待するプレフィックス長を確認し、クライアントが遠隔の範囲への経路を設定するか、ローカルのデフォルトゲートウェイへ送ってしまうかを点検します。トンネルインターフェースの /128 はポイントツーポイントの接続では正常ですが、そこでの /64 は誰も委任していないネットワークを主張することになります。問いを決める出力は二つ、両端で読むアドレステーブルとルーティングテーブルです。誤ったインターフェースを指す経路がこのステップで最も多い誤りなので、両方を並べて読んでください。

両端のアドレステーブルとルーティングテーブルで確認し、それから要求を一つ送ります。要求が正しく出て何も戻らないなら、不具合はクライアントのアドレスではなく、遠い側の経路にあります。

ステップ三：トンネルの背後のルーターへの委任

プレフィックスの委任はアドレス割り当てとは別の仕組みで、独自の要求と独自のリースを持ちます。委任する側は、下流のネットワークに十分な大きさのプレフィックスを渡すよう設定する必要があり、要求するルーターはそのプレフィックスから内側のインターフェースに番号を振る必要があります。

モバイルクライアントにサービスするプールが委任できると決めつけないでください。多くの VPN 製品は単一のアドレスを割り当てるだけで委任の役割をまったく持たず、あなたのエッジに届いたプロバイダーのプレフィックスも自動的にピアへ渡されることはありません。二つは別の場所で設定されるため、どのプールがどの役割を担うかを記録してください。

ステップ四：戻り経路を明示する

両端が、どのピアがどのプレフィックスを運ぶかで合意する必要があります。遠い側で、委任されたネットワークの経路をトンネルへ向けて追加し、重複する範囲がすでにそれを主張していないことを確認します。

戻り経路のない有効なプレフィックスは、整ったアドレス計画と、つながらないという結果を生みます。アクセス規則のない経路は、意図した以上に拠点を露出させるので、二つの変更を同じ作業枠で組にし、中途半端に適用された状態を利用者から遠ざけてください。

ステップ五：ルーターの背後から確認する

クライアントのトンネルインターフェースのアドレス、内側のインターフェースの委任されたプレフィックス、そのプレフィックスへ向かう遠い側の経路、最後にルーターの背後の機器からの要求という順番で確認します。静かな遮断と欠けた経路を区別できるよう、自分が管理する宛先を使ってください。どのステップで驚いても、先へ進む前に直すのはそこです。

最後の確認は、ルーター自身から一度、その背後の機器からもう一度の二度行います。宛先に届くのにクライアントが届かないルーターは、委任か転送の問題であり、上流の問題ではありません。

切り戻し

変更の前に以前のアドレス設定を保存し、二つの仕組みのどちらを変えたかを記録します。経路を残したまま委任されたプレフィックスを外すと黒い穴が残り、プレフィックスを残したまま経路を外すと、何も届かないアドレスが残ります。片方だけ元に戻すと拠点が一方向にだけ到達不能になるため、二つの変更は別々に記録してください。

製品が必要な役割に対応していないと分かったら、決して想定されていない範囲を収めるためにクライアントのフィールドを引き伸ばすのではなく、立ち止まって設計を変えてください。間違った仕組みで答えたサポート案件は、設計変更よりも高くつきます。