OpenVPN ラボにプライベート IPv6 を追加する、チェックポイントを1つずつ

すでに IPv4 で接続し、サーバーの背後にあるプライベート IPv4 ワークロードに届くクライアントがあります。目的は、外側のトランスポートに触れずに同じトンネルでプライベート IPv6 ワークロードへ届くことです。この順序が重要です。外側の経路は IPv4 のままで、変わるのは内側のアドレス計画、クライアントのルート、サーバーから LAN への戻り経路だけです。チェックポイントは五つ、どれも先へ進む前に具体的に確認するものがあります。

チェックポイント一:すでに動いている接続

何かを足す前に、クライアントを接続して IPv4 の経路を確認します。動くトンネルがあれば、新しい IPv6 の誤りと古い接続問題を切り分ける基準になります。どのサーバーインスタンスを実際に編集しているかも分かります。

すでに頼っているプール、トポロジー、プッシュされるルートを書き留めます。IPv6 の作業はその設定を広げるもので、置き換えるものではありません。

チェックポイント二:内側のプレフィックスを選ぶ

サイト用に ULA /48 を一つ選び、そこから /64 を二つ切り出します。一つはトンネルのクライアント用、一つは IPv6 ワークロードを載せる LAN セグメント用です。例のプレフィックスを写すのではなく、40 ビットのグローバル ID を生成します。そして両方のサブネットを、サイトがすでに経路に載せている全ネットワークと突き合わせます:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

独立した /64 が二つあれば、クライアントのプールが LAN セグメントから切り出されません。これは後で戻り経路を書くときに効いてきます。上の値は作業済みの一例で、再利用するプレフィックスではありません。

チェックポイント三:ヘルパーとルートプッシュを足す

何かを追記する前に、現在のサーバー設定を読みます。既存ディレクティブの二つ目のコピーは最初のものと統合されず、出るエラーは IPv6 ではなくディレクティブ名を示します。既存の IPv4 ヘルパーがあれば、二行でそれを広げます。それぞれ別の問いに答えます:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

一つ目はインターフェースとクライアントプールを設定する便利なヘルパーです。二つ目はクライアントが届くべき LAN の宛先を示します。クライアントに IPv6 アドレスを与えても、サーバーの背後にどのネットワークがあるかは伝わらないので、両方の行が必要です。

このヘルパーは静的 IPv6 プールや nopool とは共存しません。配備が意図的にアドレスを静的割り当てしているなら、その方針を保ち、例に合わせるために方針を消すのではなく IPv6 の等価物を明示的に設計します。

チェックポイント四:転送と戻り経路

サーバーの IPv6 転送は、忘れてしまう一時的な実行時書き込みではなく、システム自身の設定管理を通して有効にします。実行時の形は簡単な試験には便利です。永続設定はディストリビューションのネットワーク管理が読む drop-in ファイルに置きます:

sysctl -w net.ipv6.conf.all.forwarding=1

転送はパケットの経路制御を超えてホストの IPv6 の振る舞いを変えます。クライアントとしてルーター広告を受けていたホストは、転送を始めた時点で同じように受けなくなります。したがって IPv6 の上流が RA に依存する機械は、その上流について明示的な計画が必要です。

次に LAN へ、トンネルプールへの戻り経路を与えます。ワークロードの IPv6 ゲートウェイは VPN サーバーではなく LAN のルーターなので、経路はそのルーターに置き、サーバーの LAN アドレスを指します:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

リンクが必要とする ICMPv6 の種別は、経路 MTU のフィードバックも含めて残します。IPv4 のファイアウォール規則は IPv6 の規則を意味しませんし、IPv6 を一律に落とすと近隣探索が壊れ、経路の障害に見えます。

チェックポイント五:クライアントを読み、それから試す

クライアントを再接続し、サーバーのヘルパーアドレスから推測するのではなく、実際に受け取ったアドレスを読みます。インターフェースの一覧には同じデバイス上に両方のファミリーが出ます:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

トンネルを選ぶ経路は、クライアントがパケットの送り先を知っていることを示します。サーバーが転送していること、LAN のルーターが戻り経路を持つこと、アプリケーションが応答を許されていることは示しません。

アプリケーション自体を各ファミリーで順に試し、再接続の後とホスト再起動の後にも繰り返します。再起動までしか持たない経路や sysctl は試験であって、設計ではありません。

AAAA レコードは、IPv6 の経路が端から端まで応答してから公開します。IPv4 で問い合わせた DNS も IPv6 アドレスを返せますから、名前が引けることは何かが待ち受けている証拠ではありません。RFC 4193 の ULA ガイダンス は、これらのプレフィックスをコピーではなく自分のものにするグローバル ID の生成を扱っています。