OpenVPN の再起動後に IPv6 の外向き通信が死ぬ: プレフィックスの所有権を確認する
トンネルが作り直されると IPv6 が止まります。何かを再起動する前に、委任されたプレフィックス、クライアントのアドレス、戻り経路の所有者を決めてください。
IPv6 は OpenVPN が再起動した瞬間にトラフィックを通さなくなり、IPv4 は動き続けます。トンネルのインターフェースは作り直され、その IPv6 状態を管理していた別の何かが、アドレスを失うか、プレフィックスを到達可能にする経路を失いました。関係する状態は三つあり、それぞれ所有者が違います。プロバイダーから委任されたプレフィックスとその有効期間、VPN クライアントに渡されるアドレス、そしてそのクライアントのプレフィックスをサーバーへ戻す上流経路です。どのデーモンに触れる前に、それぞれの所有者を特定してください。間違ったものを再起動すると問題は一日隠れ、次の接続で戻ってきます。
IPv6 状態の三つの部分と三人の所有者
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
トンネル内のグローバルスコープのアドレスだけでは足りません。上流のルーターは依然としてそのプレフィックスを VPN サーバーへ戻す必要があり、サーバーがたまたまその中のアドレスを持っているからといって、そうしてくれるわけではありません。
だからこそ、公開 /64 をトンネルのプールにコピーするのは危険です。サーバーへルーティングされたプレフィックスは、上流が on-link として扱うプレフィックスとは違い、近隣探索がその隙間を埋めることはありません。
何かを変える前にサーバーの状態を読む
状態を二回、IPv6 が動いているときと再起動後の両方で取得して比較し、読み取り専用のビューで十分でメンテナンス時間中もコストはかかりません。
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwarding三つの具体的な違いとは、消えた経路、非推奨または無効な有効期間に移ったアドレス、そして再委任後に変わったのに VPN 設定がまだ古い方を広告しているプレフィックスです。
アドレスが消えたのにプレフィックスが変わっていなければ、それを割り当てるデーモンがインターフェースの管理をやめています。プレフィックスが変わったのにアドレスが変わっていなければ、クライアント設定が古いままです。二つの障害はブラウザーからは同じに見え、共通点は何もありません。
dhcpcd にトンネルを管理させるべきかを決める
dhcpcd はインターフェースを検出し、DHCPv6 プレフィックスの一部を下流のインターフェースへ委任でき、その設定では委任先を明示できます。明示的な委任先がないと、文書化された動作が他のインターフェースに及び、そうやってトンネルは誰も計画していなかったアドレスを持つことになります。
二つの条件が、トンネルの静的アドレスを OpenVPN に任せる方向へあなたを押しやるはずです。サーバーが設定で固定アドレスをプッシュしていること、そして再接続でトンネル名が変わることであり、両方が当てはまるならトンネルを委任デーモンから意図的に除外し、理由をコメントに残してください。
逆に、トンネルへの委任が意図的なものであるなら、 プレフィックス変更の処理を実装してください。委任されたプレフィックスやその有効期間が変わったときに反応し、サーバーが広告するクライアントプレフィックスを更新し、経路を再び追加するということです。その設計でインターフェースを除外すると、新しいプレフィックスを知っている唯一のコンポーネントが消えます。
dhcpcd の再起動は、状態を作り直すので一見直ったように見えますが、考えていなかったインターフェースの設定も更新したり取り下げたりします。その復旧は、VPN の再起動のたびに必要だという理由にはなりません。証拠として使っていたカウンターもリセットされます。実際に変えたインターフェースだけを狙って再読み込みしてください。
IPv6 を IPv4 NAT とは別に検証する
転送が有効で、上流経路が実際のクライアントプレフィックスを指していることを確認し、そのうえで新しく許可された IPv6 接続を行います。クライアント自身の IPv6 経路テーブルも確認してください。公開アドレスを表示していても、その要求がトンネルを使った証拠にはなりません。
IPv4 のマスカレードは別の問題を解決します。プライベートな送信元の戻り経路です。取り下げられた IPv6 プレフィックスには何の効果もなく、追加しても IPv6 は戻りません。
所有権の記録で締めくくります。どのコンポーネントがプレフィックスを委任し、どれがクライアントアドレスを割り当て、どれが戻り経路を保持し、再接続でそれぞれに何が起きるのかです。ランブックの四行が、次の人が重要なデーモンを見つけるために三つを再起動する手間を省きます。