VPNセンサーが支店のVLANタグを永遠に見ない理由

VPN側のセンサーには、二つの支店VLANが単なるIPトラフィックとして見え、各支店をそれぞれのケーブル上で識別していたタグは消えている。ルーティングされたトンネルが行うのはまさにそれで、復元するのはパケットであり、それを届けたEthernetフレームではない。失われたタグが問題になるかどうかは、センサーに投げかける問いに完全に依存する。以下の四つの確認を順に行えば、どの観測点がその問いに答えられるかがわかる。

まず、トンネルが何を復元するのかを確定する

TUNインターフェースはIPパケットを運ぶため、支店フレームのVLANヘッダーは、トラフィックをトンネルに押し込んだルーターで止まる。 TAPインターフェースはEthernetフレームを運ぶため、ブリッジとVLANの受け入れルールが通せばタグは残り得る。 キャプチャに何が入るべきかを考える前に、インターフェースの種別を読む。

どちらの選択も欠陥ではない。二つの設計は異なる問いに答え、タグを異なる場所に残す。

製品名から推測するのではなく、インターフェースを自分で確認する。リンクの詳細はデバイスの種類を示し、有効なフラグを表示する。TUNデバイスで取得したキャプチャは、要求したからといってEthernetヘッダーを得るわけではない。TUNのキャプチャにタグが現れるなら、ほぼ確実に別のインターフェースか、ペイロードの中にフレームを運ぶトンネルを読んでいる。先に進む前に、どちらのケースなのかを記録しておく。

次に、対象がまだ存在する位置にセンサーを置く

三つの位置でほとんどのルーティング設計を網羅できる。支店のEthernetセグメント、トンネル両端の間の外側ネットワーク、トンネル処理後の経路である。それぞれが見る対象は異なり、タグが存在するのは最初の位置だけである。センサーの位置を選ぶことは、ポリシーがどの対象を必要とするかの決定であり、便宜の問題ではない。

ポリシーの問いを表が答えられる言葉で立てれば、たいていは自然に解決する。パケットがどの支店から来たのかをルールが知る必要があるなら、下流のプレフィックス対応表で足りることもあるが、それはその対応が正確で曖昧でない間だけである。フレームがどのポートに届いたのかをルールが知る必要があるなら、最初の位置が必要である。下流の何もそれを再構成できない。問いではなく習慣で置かれたセンサーこそ、チームが設計が決して運ばなかったフィールドを要求するようになる原因である。

Ethernetを運ぶトンネルは別の設計であり、両端が何を保持し何を書き換えるかについて独自の確認が必要である。TAPを選ぶだけでは、ブリッジ、VLANの受け入れルール、検査ポリシーはまだ定義されない。

三つ目に、送信元コンテキストを信じるのではなく獲得する

支店ごとに一つのアドレス範囲を割り当てるのは、VLAN識別の代わりとしてよく使われるが、対応が一対一のままである間しか成り立たない。重複するプレフィックス、変換、共有ゲートウェイは、いずれもその前提を、設計の問題ではなくデータ品質の問題に見える形で崩す。対応表を境界とともに書き留め、二つの行に一致するパケットがどうなるかを明記する。二つの支店に現れるプレフィックスは、受け入れるコイントスではなく、検出するエラーであるべきだ。

クライアントが提供するコンテキストは、メンバーシップの証拠ではない。それは主張であり、別の列に属する。

区別が重要な場面では、自分が制御する関連付けデータを使う。どのトンネルインスタンスが接続を受け入れたか、パケットがどのインターフェースに届いたか、そのピアについてローカルのルートテーブルが何と言っているかである。クライアントが提供するラベルは有用な手がかりであり、認可の入力としては無意味である。センサーが自側で関連付けを確立できないなら、ポリシーには自信のある推測ではなく、より広いルールが必要である。

四つ目に、応答経路と復号が見逃すものを確認する

片方向しか見えないセンサーでも、要求が時間どおりに届き続けるため、健全に見えることがある。応答経路を明示的に確認し、一般的な到達性ではなく同じフローについて確認する。半二重の可視性は、そこから引き出す状態に基づく結論すべてに静かな欠落をもたらす。

内側のIPトラフィックを復元することも、その中のアプリケーションを見ることと同じではない。トンネル上を運ばれるTLSはTLSのままである。

ip -d link show tun0
tcpdump -i tun0 -n -e -c 5

この二つのコマンドはインターフェースの問いに答え、キャプチャが実際に何を含むかを示す。アーキテクチャを論じるより速い。設計が使うインターフェース名に置き換え、気になるフローが動作している間にキャプチャを実行する。TUNデバイスにタグが現れない場合、得られる知見は、センサーがデータを落としたのではなく、設計がブリッジではなくルーティングを選んだということである。その後、タグを見られる位置にセンサーを移すか、現在の位置で支えられる言葉でルールを書き直す。