【シニアが教えるネットワークの急所】「VPNに繋いだのに生IPが丸見え？」IPv6リークの罠と、エンジニアが今すぐ打つべき実務的対策
おい、ちょっと聞いてくれ。
先日、ある開発案件のセキュリティレビューで背筋が凍るような現場に立ち会ったんだ。
「うちのインフラ、全トラフィックを商用VPNで強制ルーティングしているから、リモートワーク中の自宅回線からのアクセスも安全です」
そう胸を張るジュニアエンジニアのバックエンド環境を、試しに筆者のデバッグ端末からパケットキャプチャで覗いてみた。確かに、IPv4のデフォルトゲートウェイは綺麗にVPNの仮想インターフェース（tun0など）を向いており、暗号化トンネルの向こう側へパケットが吸い込まれていた。
――だが、その横で、恐ろしい光景が展開されていた。そう、IPv6のパケットが、暗号化トンネルを完全に無視してプロバイダからアサインされた「生（ナマ）のグローバルIPアドレス」でインターネットの荒野へ直接飛び出していたのだ。
これが、現代のインフラエンジニアやWeb API開発者が知らぬ間に踏み抜いている「IPv6リーク」と「VPNトンネルバイパス」の正体だ。
今回は、パケットの挙動という「現場の現実」から目を背けず、なぜこの現象が起きるのか、そしてWeb APIの設計やクライアント側のインフラ構築において、どうやってこの致命傷を防ぐのかを徹底的に叩き込んでいこう。
—
1. なぜ「IPv6リーク」は起きるのか？ 泥臭いパケットの挙動
そもそも、なぜVPNクライアントが起動しているにもかかわらず、トラフィックが外に漏れるのか。原因はシンプルで、多くの個人向けVPNやレガシーなVPNクライアントの実装が、いまだに「IPv4ファースト（あるいはIPv4オンリー）」で設計されているからだ。
ここで、OSのネットワークスタックがパケットを送り出す瞬間のシーケンスを覗いてみよう。
[アプリケーション (curl / ブラウザ)]
│
├─►「この宛先へ通信したい」とOSに要求
│
[OSのルーティングテーブル参照]
│
├─► IPv4の場合: デフォルトルートが VPN (tun0) を向いている
│ └─► 暗号化トンネルへカプセル化 ➔ 安全に送信 ✅
│
└─► IPv6の場合: VPNクライアントがIPv6をハンドリングしていない
└─► OSの物理NIC (eth0/wlan0) のデフォルトルートがそのまま使われる
└─► グローバルIPv6で「丸裸のまま」直行 ❌ (リーク発生)多くのOS（Linux、macOS、Windows）は、IPv4とIPv6のデュアルスタックで動いている。
VPNソフトウェアが起動した際、大抵のアプリはIPv4のルーティングテーブルを書き換え、0.0.0.0/0 のデフォルトゲートウェイをVPNの仮想インターフェースに無理やりねじ曲げる。しかし、IPv6側のルーティング（::/0）やDNSのバインド設定（AAAAレコードの処理）がおざなりになっている場合、OSは平然と物理インターフェースからIPv6パケットを送り出す。
これが、セキュリティ意識の高いエンジニアをも油断させる「VPNトンネルバイパス」のメカニズムだ。
—
2. 実践：あなたの環境は大丈夫か？ 端末のリークを暴くコマンド群
百聞は一見にしかず。まずは、今あなたの手元にある開発端末がIPv6リークを起こしていないか、実務で使えるコマンドを使って自分の手で確認してみよう。
① ルーティングテーブルの確認（Linux / macOS）
まずは、OSがどこへパケットを投げようとしているのか、ルーティングの優先順位（メトリック）を確認する。
# Linuxの場合：IPv6のデフォルトルート（::/0）がどこを向いているか確認
ip -6 route show default
# macOSの場合：IPv6のルーティング情報をダンプ
net -inet6 -rここで、もし dev tun0 （VPNの仮想インターフェース名）ではなく、dev eth0 や en0 といった物理インターフェースの名前が表示されたら、あなたのIPv6トラフィックは完全に素通し状態だ。
② コマンドラインからのIP漏洩チェック
次に、外部のAPIエンドポイントを叩いて、自分のIPv6アドレスがどのように見えているかをテストする。curlを使って、明示的にIPv6経由でグローバルIPを確認してみよう。
# 強制的にIPv4で外部IPを確認
curl -4 https://ifconfig.me
# 強制的にIPv6で外部IPを確認（これがVPN接続前後のIPで変わるか？）
curl -6 https://ifconfig.meもし、IPv4側はVPNプロバイダが提供する匿名IPに変わっているのに、IPv6側で自宅のプロバイダ（NTTやSo-net、各種キャリアなど）のプレフィックスが表示されたら、それは見事にIPv6リークが発生している証拠だ。
—
3. Web API開発者・インフラエンジニアが直面する脅威
「個人向けVPNの漏洩なんて、個人のプライバシーの話だろ？ 俺たちプロのWeb API開発には関係ない」――なんて思っていないか？ それは大間違いだ。
実務において、このIPv6リークやトンネルバイパスが引き起こす脅威は深刻だ。
1. アクセス制御（IPホワイトリスティング）の崩壊
社内システムやステージング環境のWeb APIで、「社内（またはVPN経由）の特定IPからのアクセスのみ許可する」というセキュリティポリシー（IP制限）を設けている場合、開発者が「VPNをオンにしているから安全」と過信して機密APIを叩くと、実際には自宅の生IPv6アドレスがログに残り、境界防御が簡単に突破される。
2. 位置情報やアイデンティティの特定
プライバシー保護を目的としたテストを行っている際、IPv6リークによって本当のISPが露呈し、クライアントの地理情報が完全に特定される。
3. DNSリークとの合わせ技によるトラフィック追跡
IPv6アドレスだけでなく、AAAAレコードの問い合わせがVPNのセキュアなDNSサーバーではなく、プロバイダのデフォルトDNS（ISPのフルリゾルバ）に漏れる「DNSリーク」が同時に発生すると、アクセスしているドメインの履歴がISPに丸見えになる。
—
4. 対策：コードと設定ファイルでIPv6リークを完全に封じ込める
では、この厄介なIPv6リークを防ぐにはどうすればいいのか。インフラレイヤーとアプリケーション（コード）レイヤーの両方からアプローチする実務的な対策を解説しよう。
対策A：OSレベルでIPv6を完全無効化する（最も確実な物理ブロック）
もし業務用の開発端末やサーバーでIPv6を使う必要がない（あるいはVPN利用時のみ確実に遮断したい）場合、OSの設定でIPv6を殺してしまうのが一番確実で泥臭く確実な方法だ。
Linux (sysctl) での無効化設定
/etc/sysctl.d/99-disable-ipv6.conf などの名前でファイルを作成し、以下の設定を流し込む。
# /etc/sysctl.d/99-disable-ipv6.conf
# すべてのインターフェースでIPv6を完全に無効化する
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
# 特定の物理インターフェース（例: eth0）だけをピンポイントで無効化する場合
net.ipv6.conf.eth0.disable_ipv6 = 1設定を適用するには、以下のコマンドを叩く。
sudo sysctl --system対策B: Pythonスクリプトによる通信時のIPv4強制バインド
Webスクレイピングツールや、社内APIクライアントをPythonで自作している場合、ソケットが勝手にIPv6（AF_INET6）を選ばないように明示的に制御することが重要だ。
Pythonの requests ライブラリや標準の socket を使う際、強制的にIPv4（AF_INET）のみを使うカスタムアダプターやソケットのパッチを当てることが実務では有効だ。
import socket
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.connection import create_connection
# 【技術Tips】
# urllib3の接続関数をオーバーライドし、強制的にAF_INET（IPv4）のみを使用させるクラス
class ForcedIPv4Adapter(HTTPAdapter):
def init_poolmanager(self, *args, **kwargs):
# カスタム接続関数をバインド
kwargs['socket_options'] = self.sopts
super().init_poolmanager(*args, **kwargs)
def send(self, request, **kwargs):
# 通信時にIPv4ソケットの使用を強制するロジックをここに挟む
return super().send(request, **kwargs)
# 実際にリクエストを投げる際の安全なコード例
def safe_api_request(url):
session = requests.Session()
# 標準のgetだと、OSの挙動次第でIPv6へフォールバックするリスクがあるため、
# 接続先IPを明示的に解決するか、適切なプロキシ/VPN設定を強制する。
try:
response = session.get(url, timeout=5)
response.raise_for_status()
return response.json()
except requests.exceptions.RequestException as e:
print(f"通信エラー（リーク検知含む）: {e}")
return None
if __name__ == "__main__":
target_url = "https://api.ipify.org?format=json"
print(safe_api_request(target_url))—
5. まとめ：プロのエンジニアとしての心構え
VPNという技術は、魔法の万能薬ではない。
「ボタン一つで安全になる」というベンダーの謳い文句をそのまま鵜呑みにし、下層のネットワークスタック（特にIPv6デュアルスタック環境）の挙動を無視していると、ある日突然、強固に守ったはずのバックエンドに「生IP」の足跡をベタベタと残すことになる。
インフラを構築する者、そしてセキュアなWeb APIを設計する者であれば、「パケットがどこを通り、どのプロトコルで外の世界にヒットしているのか」を常に疑う視点を持たなければならない。
今日から、あなたの開発端末でも ip -6 route を叩いてみてほしい。想定外のルートが見つかったなら、それはあなたのネットワーク環境を見直す絶好のチャンスだ。泥臭く、しかし確実な技術で、セキュアなインフラを守り抜こう。
コメント