企業ファイアウォールが VPN の中で見えるものと見えないもの
ファイアウォールはトンネルを遮断できても、その中身は読めないことがある。外側のヘッダーが何を明かすか、TLS 検査が適用されるかを確認し、証明書チェーンを検証しよう。
同じノート PC が自宅からは VPN につながり、オフィスからはつながらない。ならば誰かが通信を読んでいる。遮断と読取は別の権能であり、二つ目だけが経路上の位置と、クライアントが信頼する証明書を必要とする。ハンドシェイクを落とす中間装置は、あなたが送ったはずの内容について何も学んでいない。どちらに直面しているかを見極めることが、この作業のすべてだ。
遮断と読取は別の権能
拒否は安上がりでわかりやすい。ソケットは開くのに何も返らない、あるいは即座にリセットが返る。ペイロードが一本も線を渡っていないのだから、どちらも検査を意味しない。
読取には、保護を終わらせ、証明書で身元を示し、その先へ新たな接続を張る端点が要る。その端点は経路上にあり、クライアントから信頼されていなければならない。パケットを転送するだけのファイアウォールには、位置も資格情報もない。
外装が無料で明かすもの
トンネルのパケットには必ず外側があり、外側は経路を持たねばならない。つまり二つのアドレス、プロトコル、ポート、長さ、そして時刻と量である。どのルーターもその項目は既に扱っており、NAT は対応表を保つためにアドレスとポートを書き換える。ペイロードは封をされたままだから、観測は二つのホスト間にトンネルがあるという事実で止まる。
ホスト名はそこに含まれない。サイトは別の扉から漏れ、最も広いのは DNS だ。ノート PC が今もローカルのリゾルバーに問い合わせているなら、名前は平文で現れる。
時刻と量は、誇張せずにこそ尊重すべき情報だ。 毎分のバイト数 は 14:20 に大きな転送が始まったことを示せるが、どのファイルが動いたかは示せない。それは行動についての実際の開示であり、内容を読むこととは別の区分である。
TLS 傍受には、すでに信頼しているルートが要る
検査装置は TLS を破らない。終わらせるのだ。クライアントには組織が持つルートの証明書が返り、二本目の接続が本当の宛先へ向かう。クライアントがこれを受け入れるのは、そのルートが自らの信頼ストアにあるからで、管理されたノート PC に警告が出ないのはそのためだ。暗号は破られていない。端点が動かされただけである。
だからこの仕組みは証拠を残す。提示されたチェーンの発行者は公開 CA ではなく組織に属し、クライアントは特別な道具なしにそれを見られる。内部ルートで終わるチェーンは傍受の署名であって、故障ではない。
VPN のチャネルが HTTPS セッションではない理由
VPN のデータチャネルは検査装置にそんな足場を与えない。IKEv2 と WireGuard は独自のハンドシェイクと鍵スケジュールを回し、終わらせるべき TLS がない。一方で OpenVPN は制御チャネルに TLS を改変した形で借り、その後は独自の方法でデータを守る。HTTPS 向けに作られたプロキシは、そのセッションを解析できるものとして認識しない。
セッションを解析できない装置でも、それを落とすことはできる。VPN の遮断が証明書の警告ではなくタイムアウトのように見えるのはそのためで、例外を入れても何も変わらないのもそのためだ。
自分のマシンで確かめる
サイトが提示するチェーンから始めよう。ブラウザーのサイト情報は発行者を示し、コマンドラインは要約なしで同じことを報告する。
openssl s_client -connect example.com:443 -servername example.com次に、拒否されたハンドシェイクと、選別された内側の通信をカウンターで切り分ける。落とす規則より前に転送ポートを記録し、試行の後に読む。
iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbers外側のソケットにログ行がなければ、ハンドシェイクは出ておらず、経路がトンネルを拒んでいる。ハンドシェイクが完走し、一部の宛先だけが失敗するなら、トンネルは機能し、その内側のポリシーが機能していない。どちらの結果も、ペイロードを一バイトも読むことを必要としなかった。
実際に起きる読取は端にある。分割トンネルは内部 HTTPS を企業プロキシに渡し、雇用主が持つ集約装置は出口ですべてを露出させる。何を見つけても、接続を強行するために証明書の検証を切ってはいけない。その検査だけが、検査と攻撃者を分けているのだから。