ほぼ同じ名前の二つのディレクティブが動く例には必ず登場し、片方だけをコピーすると、見た目は正しいのにブランチのプレフィックスを黙って落とすトンネルができます。両者は同じ境界の反対側で別の仕事をします:一方はプレフィックスがどこにあるかをサーバーのカーネルに教え、もう一方はOpenVPNにどの認証済みクライアントが運ぶかを教えます。両方が正しければプレフィックスは流れ、片方だけ正しければパケットには経路があっても持ち主がいません。

二つのディレクティブ、二つの異なる仕事

route-ipv6 は通常の経路インストールです:サーバーがカーネル経路を追加し、プレフィックスを自身のトンネルインターフェースへ向けます。iroute-ipv6 はクライアント固有のコンテキストに属して内部的な所有権を宣言するため、デーモンは、そのプレフィックス宛てのトラフィックを、カーネル経路がたまたま指す相手ではなく特定のクライアントへ送るべきだと分かります。

一方はカーネルの転送テーブルの話で、もう一方はデーモンの内部ルーティングモデルの話です。両者を切り離して考えると、完全に見える設定がなぜプレフィックスを落とせるのかが説明できます。同じネットワークが動く例に二度現れる理由も説明できます。どちらの行も余分ではありません。

従来のユーザー空間の構成では両方が必要で、互いに補完します。カーネル経路だけではデーモンは相手を選べません。iroute だけではカーネルにトンネルへの経路がありません。クライアントごとのファイルに関する混乱の多くもここから来ており、ファイルは経路テーブルの項目ではなく、経路の項目も所有権の表明ではありません。

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

それぞれを置く場所

経路はサーバーの管理設定に置き、そのサーバープロセスに適用します。iroute は、ブランチ機器の認証済み ID にちなんで名付けられたクライアント固有のファイルに置きます。

実効 ID と一致しないファイル名は決して読み込まれず、症状は iroute の欠落とまったく同じです。サーバーが認証した ID を確認し、次にファイル名を一文字ずつ確認してください。

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

プールとブランチのプレフィックスは、重なるとどのディレクティブでも解けない難問が生まれるため、分けておいてください。

別のクライアントに必要なもの

そのブランチに到達すべき二台目のクライアントに必要なのは所有権ではなく広告です。意図したクライアントに、設定に合うクライアント単位またはグループ単位のコンテキストでプレフィックスをプッシュします。

その機器はすでにプレフィックスを接続済みネットワークとして持っているため、ブランチ自体には送らないでください。

全員に送るのは、そのアクセスを与えるつもりのなかったクライアントも含め、すべてのクライアントがブランチをトンネル経由で到達可能だと信じる結果を伴う選択です。広告は実際にはアクセスの判断であり、ディレクティブは配管作業のように見えても変わりません。サーバーオプションのリファレンスでは iroute-ipv6 をクライアント固有の所有権として記述しており、それは維持する価値のある区別です。

ブランチ機器上の戻り経路

所有権が役立つのは、ブランチがパケットを転送し、その LAN が応答の仕方を知っている場合だけです。ブランチ機器で IPv6 転送を有効にし、その LAN のホストが VPN プール宛てのトラフィックを、プールを知らないデフォルト経路ではなくブランチへ戻すことを確認します。

その戻り経路はIPv4 で人が遭遇する経路欠落の問題の IPv6 版です。

ブランチ自体ではなく、LAN のホストから VPN プールのアドレスを検索して確認します。ルーター上で行う検索は、利用者が尋ねている質問とは別の質問に答えるものであり、両者はしばしば食い違うため、追加のコマンドを打つ価値があります。

その組でもまだ足りないとき

この経路をまったく使わない配備もあります。カーネルのデータパスと製品が管理するサーバーには、それぞれ独自のサポートされた経路処理があり、ユーザー空間の例がそのまま当てはまるとは限りません。

もう一方のために書かれたチュートリアルからディレクティブをコピーする前に、自分のビルドがどのデータパスを使っているかを確認してください。

最後にアドレス範囲を忘れないでください:fd00:7a::/64 のような一意なローカルプレフィックスは設計上プライベートであり、パブリックな IPv6 の到達性については何も語りません。内部アクセスとして扱い、インターネットへの出口は独自のポリシーを持つ別の問いとして切り分けてください。

関連記事