共有 TAP VPN でもポータルに HTTPS が必要な理由
TAP VPN が認証するのはピアであり、その背後のサービスではありません。ポータルではホスト名の検証を維持し、信頼しない隣接ピアは分離してください。
二台の端末が有効な VPN 資格情報を持ち、一つのブリッジ接続された Ethernet セグメントを共有しています。オフィス ポータルの応答を担当するのはそのうち 一台だけのはずですが、もう 一台もそのセグメント上でポータルのアドレスを主張できます。トンネルは役割を果たしました。両方のピアを認証し、サーバーへの各経路を暗号化しました。果たさなかったのは、どちらがサービス名を所有するかを証明することであり、その隙間こそがポータルに今も有効な証明書が必要な理由です。
VPN が実際に認証するもの
VPN のハンドシェイクが答えるのは 一つの問いだけです。どのピアが、どの鍵素材でこのトンネルを完了したのか。その答えはピアごと、接続ごとのものであり、そのピアが後から公開するサービスについては何も語りません。TAP セグメントでは、ピアは単一のアドレスですらありません。ブリッジが学習を許す任意の MAC と任意の IP を提示できるからです。認証はトンネルの端点で止まり、アプリケーションには及びません。
三つの問いを 一つにまとめず、分けて扱ってください。それぞれに固有の仕組みと失敗の仕方があります。
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
導入環境では、完全に認証されたトンネルと、その背後にあるまったく認証されていないサービスが併存しえます。また、第二層アドレスを別のピアが主張しているホストに、検証済みの証明書があることもあります。だからこそ、どちらか一方が他方を置き換えるのではなく、両方の制御を設計に含めるべきなのです。表は、その論点を 三行にまとめたものです。
共有セグメント上の ARP はディレクトリではありません
ARP はローカル リンク上で IPv4 アドレスを MAC に対応づけ、そのリンク上の誰からの応答も受け入れます。寛容なブリッジ セグメントでは、ピアが別の端末に属するアドレスを主張でき、ブリッジは最後に応答した相手へフレームを転送します。クライアントからサーバーへの各経路を暗号化しても、フレームはブリッジに届く前に復号されるため、これは変わりません。ARP の信頼境界はトンネルではなくセグメントです。
ホストが実際に何を学習したかを見てください。ip neigh show は現在の対応関係とその状態を一覧表示します。通常運用中に 二つの MAC アドレスの間で入れ替わるエントリは、見過ごすのではなく調査する価値のある兆候です。健全な小規模セグメントでは、そうしたエントリは長期間安定します。
ピア分離とブリッジ ポリシーは、まさにこのケースのために存在します。サービスが IP のみで、端末同士が互いのフレームを見る理由がまったくないなら、ルーテッド設計のほうが通常は適切な答えです。
証明書の検証はサービスのある場所に置いてください
アプリケーションの TLS は、トンネルが答えられない問い、すなわちこれが到達しようとしていたサービスなのかという問いに答えます。ブラウザーはホスト名を証明書と照合し、その照合だけが、ピアではなくポータルを名指しするチェーン上の唯一の部分です。
警告を体裁だけの問題と判断する前に、サーバーが何を提示しているかを調べてください。openssl s_client -connect portal.example.internal:443 -servername portal.example.internal はチェーンとサブジェクト代替名を出力します。入力した名前がその一覧にないなら、警告は正しく、修正すべきは証明書です。利用者に警告を無視するよう教えることは、機能する制御を飾りに変えてしまいます。
OpenVPN のブリッジング ガイド は Ethernet モデルとその周辺のポリシー オプションを説明しており、セグメントが何を許可すべきかの正しい参照先です。ブリッジ規則を緩める前に読んでください。そこに示されたモデルこそ、上記のすべての確認が前提としているものだからです。
これらのピアがそもそもセグメントを共有すべきかを決めてください
最も安価な修正は、要件が IP 到達性だけなら第二層の共有をやめることです。ルーテッド VPN は各クライアントに独自のアドレスを与え、共有ブロードキャスト ドメインをなくし、ピア間トラフィックを既定ではなくポリシー判断に変えます。そうすればポータルが守るべきアドレスは 一つになり、それを主張できる隣接ピアもいなくなります。
セグメントを残す必要がある場合は、クライアント同士の到達を許すサーバー側設定を確認してください。grep -n client-to-client /etc/openvpn/server.conf。無効ならクライアントのトラフィックはサーバーを経由し、そこでフィルタリングできます。有効ならピアはブリッジを介して直接フレームを交換し、フィルタリング ポイントはブリッジとホストのファイアウォールになります。
各ホストが実際にどの保護に依存しているかを書き留めてください。トンネル認証、セグメント分離、アプリケーション TLS のいずれかです。三つすべてに依存するホストは問題ありません。一つ目だけに依存し、残り 二つも付いてくると想定しているホストが、最終的に誤ったコンテンツを配信します。