あなたの IPv4 VPN ルールは IPv6 トラフィックについて何も語っていない

監査により、同じインターフェース上でトンネルが IPv4 には厳しくフィルタされ、IPv6 には大きく開いていることが分かりました。誤字という意味での設定ミスはなく、ルールセットが一方のファミリーだけを記述し、全員がもう一方もそれに従っていると前提していただけです。実際に従うことはまれです。ルールが本当に両方を対象にしているかは三つの条件で決まり、最初の条件はポリシーではなくプラットフォームに関するものです。

条件その一：プラットフォームのテーブルは一つか二つか

パケットフィルタによっては IPv4 と IPv6 を完全に別々のルールセットに保つため、片方に追加したルールは誰かが複製するまで他方に効きません。両方に一致するファミリーを提供し、アドレスをパケットごとに変換するものもあります。第三のグループはポリシー言語を一つに保ちながら、その背後でファミリーごとに別のオブジェクトを保存します。

実際に運用しているフィルタのドキュメントを読み、どのテーブルが存在し、変更がどれに触れたのかを列挙します。IPv4 テーブルのルールを数えても、誰も尋ねていない問いに答えるだけです。次に、どのテーブルが存在し、変更がどれに触れたのかを列挙します。

条件その二：ポリシーはどこに適用されるか

混同されがちな三つの場所とは、トンネルを受け入れるリスナー、トラフィックを先へ転送する経路、そしてトンネルがフローを運んでいないときにクライアントが使う通常のインターフェースです。ゲートウェイはセッションを受け入れながら、そこから転送されるすべてを破棄することがあり、それはフィルタではなく壊れたトンネルに見えます。三つの場所は所有者もログも異なるため、何かを書く前にその混同を取り除いてください。変更記録にそれらを明記することが、修正が障害から一層離れた場所に着地するのを防ぎます。

ルールが三つのうちどれを統制するのかを書き留めます。リスナーを守るルールは転送経路を守らず、どちらもクライアントの直接経路を塞ぎません。多くの組織では答えが別のチームになるため、それぞれの場所の所有者を確認してください。

条件その三：IPv6 はどう振る舞うべきか

IPv6 がトンネルを通るのか、保護が利用できない間は遮断するのか、それとも文書化された例外に従うのかを決めます。答えごとに異なるルールセットが生まれ、問いを開いたままにすると、ネイティブ IPv6 を持つクライアントが IPv4 でトンネル内から到達する宛先に、トンネル外からも到達してしまいます。

ルールを書く前に答えを声に出してください。IPv6 を運ばないトンネルにとって遮断は正当な選択ですが、空のテーブルの偶発的な結果ではなく、意図的でテスト済みでなければなりません。文書化されていないことは、次にルールに触れる人によって、たいていは慌てて決め直されます。

ICMPv6 は制御トラフィックです

近隣探索と経路フィードバックはいずれも ICMPv6 に乗っているため、IPv4 の習慣からコピーした一律の破棄はアドレッシングと大きな転送を同時に壊します。誰も見ていないチャネルを引き渡すことになるため、一律の許可も答えではありません。

重要なメッセージ種別についてはフィルタリングの指針に従い、残りは理由を付けて拒否します。最も誤診されやすい障害は Packet Too Big メッセージの欠落で、接続が開いたあとに止まる形で現れます。

証明する、一度に一つのファミリー

各ファミリーで個別に許可されたリクエストを試し、ポリシーがセッションをまたいで維持されるべきなら再接続後に繰り返します。IPv4 のみのネットワークでのテストは IPv6 経路を動かせないため、合格しても塞ごうとしている漏れについては何も分かりません。決して一致しないルールはコメントが主張する動作をしていないため、テスト中はカウンタを監視してください。

試行ごとに範囲を限定したルールを一つだけ変え、以前の設定を手元に置いておきます。管理プロファイルがポリシーを所有している場合は、次のチェックインがローカルの修正を上書きし、漏れを元に戻すため、ローカルで編集する前にその管理者を巻き込んでください。