VPN (Virtual Private Network) #

VPN (Virtual Private Network、仮想プライベートネットワーク) は、公開ネットワーク (通常はインターネット) の上に、自分たちだけがアクセスできる暗号化された仮想専用線を張る 技術の総称である。「通信を盗聴・改ざんから守る」「リモートから社内 LAN に入る」「離れた拠点を 1 つの LAN にする」「検閲やジオブロックを回避する」「ISP に閲覧履歴を見られないようにする」といった、用途は違うのに発想は同じ という多目的さが VPN の特徴。

技術的に見ると、VPN は 「もう 1 段階の IP の中に暗号化した IP を詰める (= トンネリング)」 という単純な発想を、各時代の暗号と運用要件に合わせて作り直してきた プロトコル群 の総称でもある。本稿では「まず仕組みを 1 枚で押さえ、次に世代と選び方を一気通貫で整理し、最後に運用で踏みやすい地雷と後継モデルまで」という流れで進める。

1. 仕組み — トンネルとカプセル化 #

VPN の本質は 「もう 1 つの IP パケットの中に、本来の IP パケットを暗号化して詰める」 という単純な発想である。これを トンネリング (tunneling) と呼ぶ。

ポイントは:

「外側」と「内側」が独立した IP 空間 を持てる。クライアントが社内 IP 10.0.0.5 を貰い、社内サーバと「同じ LAN にいるかのように」通信できる。
外側の中継機器 (ISP / ルータ / Wi-Fi AP / 検閲機構) からは内側のパケットは見えない。見えるのは「どこかの公衆 IP から VPN GW 宛の暗号化通信」のみ。
VPN GW で復号され、元パケットとして社内ネットに流れる。社内サーバから見ると「社内 IP からの普通の接続」。

これが PPTP, IPsec, OpenVPN, WireGuard などすべての VPN プロトコルに共通する骨格 である。違うのは「外側パケットの形式 (UDP か TCP か, GRE か ESP か)」「VPN ヘッダの中身 (鍵交換, 改ざん検出, 順序保証)」「暗号アルゴリズム」だけ。

2. 2 つの形態 — リモートアクセスと Site-to-Site #

VPN は「何と何」を繋ぐかで、大きく 2 形態に分かれる。仕組みは同じでも運用・選定基準が大きく違う。

2.1 リモートアクセス VPN #

1 人のクライアント (PC / スマホ) が公衆インターネット越しに社内 LAN や VPN プロバイダの拠点へ入る形態。リモートワーク・出張先からの社内アクセス・個人向け匿名 VPN サービス はすべてここに含まれる。

設計の論点:

クライアントごとの認証 (パスワード, 証明書, TOTP, デバイスポスチャ = ウイルス対策・パッチ・ディスク暗号化の検査)
動的な内側 IP 配布 (DHCP に近い) と DNS / 検索ドメインの注入
スプリットトンネリング (社内宛だけ VPN を通し、その他は素で出す) を有効にすべきか — 帯域は節約できるが社内の DNS / 監視を経由しなくなるため賛否が分かれる
ユーザは専用クライアントソフトを入れるのが普通 (OpenVPN GUI, Cisco AnyConnect, WireGuard アプリ ...)

2.2 Site-to-Site VPN #

ルータ / ファイアウォール同士 が常時 VPN トンネルを張り、離れた拠点の LAN を 1 つに見せる形態。本社 ⇔ 支社、本社 ⇔ AWS VPC、本社 ⇔ Azure VNet、データセンター間冗長化 — 企業ネットワークの裏側で大量に動いている。

設計の論点:

ルータ間で事前共有鍵 (PSK) または証明書で認証
トンネルは常時張りっぱなし、ユーザは VPN を意識しない
IPsec (IKEv2) が事実上の標準。Cisco / Fortinet / Juniper / クラウド事業者すべてが対応
ルーティング (静的 or BGP) で拠点間の経路を交換することが多い
冗長化 (Active/Standby のトンネル, 複数 GW) が運用要件に絡む

3. プロトコルの世代と現代の選び方 #

VPN プロトコルは 「過去 30 年の暗号と運用要件の変化に合わせて世代交代してきた集合」として理解するのが一番速い。「この時代になぜこれが出て、なぜ次に置き換わったか」を一気通貫で並べる。

3.1 PPTP (1996, Microsoft) — 使ってはいけない #

VPN を「企業でも個人でも使える存在」にした最初の主要プロトコル。Windows NT 4.0 / 98 にバンドルされて爆発的に普及した。PPP を GRE トンネルで包む という設計で、当時は画期的だった。

しかし認証 (MS-CHAPv2) は 2012 年に Moxie Marlinspike が事実上の総当たり破りを公表、暗号 (MPPE) も 40-bit / 128-bit RC4 に依存しており現代の暗号要件を満たせない。今でも一部のレガシー機器に残っていることがあるが、発見次第無効化するのが正しい対応。

3.2 L2TP/IPsec (1999) — レガシーの主流 #

Cisco の L2F + Microsoft の PPTP を統合した L2TP (RFC 2661) を、IPsec ESP で暗号化したコンビ。OS 標準で動くため 2000 年代の企業 VPN の主流だった。

仕様自体に大きな問題はないが、NAT 越え (NAT-T) の構成が面倒、事前共有鍵が運用で漏れやすい、設定パラメータが多すぎて互換性で詰みがち といった点で新規構築には推奨されない。Snowden 文書では NSA が特定パラメータ組合せを解読する能力を持っていた示唆もある。

3.3 IKEv2/IPsec — 拠点間とモバイル・アクセスの現代主流 #

IPsec の鍵交換 (IKE) を第 2 版に作り直したもの。Cisco, Microsoft Always On VPN, Apple iOS の標準 VPN など商用製品で最も普及している現代版 IPsec。

IKEv2 が現役な理由:

MOBIKE で Wi-Fi ↔ 4G/5G の切替時にもセッションを維持できる → モバイルに強い
AES-GCM / ChaCha20-Poly1305 で AEAD、PFS (Forward Secrecy) も標準
NAT-T が標準内蔵
ハードウェアアクセラレータが普及していて速い

Site-to-Site VPN の事実上の標準 であり、iPhone から会社につなぐ「Always On VPN」 もこれが主役。

3.4 OpenVPN (2001) — 「TCP/443 が通る場所なら必ず動く」 #

TLS の上に独自バイナリプロトコルを載せるユーザ空間 VPN。James Yonan が公開し、TCP でも UDP でも動く・TCP/443 でも動く ことから 空港・ホテル・国家ファイアウォール越えの定番 として重宝された。

クロスプラットフォーム (Linux/macOS/Windows/iOS/Android) で 設定が .ovpn 1 ファイルにまとまるシンプルさが、中小企業 VPN や個人向け VPN サービスで広く採用される理由になった。ユーザ空間で動くため IKEv2/WireGuard より遅い。

3.5 SSL VPN (2000 年代後半) — 「ブラウザだけで使える」 #

HTTPS (TCP/443) に乗せた VPN。Cisco AnyConnect / Fortinet SSL VPN / Pulse Connect Secure / Palo Alto GlobalProtect / SonicWall などのベンダーが提供する企業向けリモートアクセスの主役。

「443/tcp さえ開いていれば動く」「ブラウザでログイン → クライアントが落ちてくる」という運用しやすさで爆発的に普及したが、後述する通りこの層のベンダー脆弱性が現代企業侵害の主要経路になっており、運用の重さが変わった。

3.6 WireGuard (2018) — 現代のデフォルト候補 #

Jason A. Donenfeld が公開、Linux カーネル 5.6 で mainline 化 (2020)。コードが ~4,000 行 という極端な小ささと、暗号スイートを 1 つに固定したミニマリズムで、IPsec / OpenVPN を一気に置き換えうる勢いになっている。

仕様の特徴:

鍵交換: Curve25519 / AEAD: ChaCha20-Poly1305 / ハッシュ: Blake2s / KDF: HKDF — ネゴシエーションなし、選べない = 攻撃面が小さい
UDP 単一ポート (デフォルト 51820)
設定は 公開鍵 1 行ずつの peer 列挙 (SSH authorized_keys の感覚)
接続/切断の概念がない — 必要な時だけ送る state-less な「peer」モデル
モバイルでバッテリ消費が小さい

現代の個人向け VPN サービス (Mullvad / IVPN / ProtonVPN ...) は WireGuard を主軸にしていることが多い。Tailscale は WireGuard をコントロール平面で包んだ ZTNA 寄りの製品で、今もっとも勢いがある。

3.7 結局どれを使うか — 用途別の選択 #

用途	推奨	理由
個人プライバシー (公衆 Wi-Fi 防衛 / 検閲回避)	Mullvad, ProtonVPN (WireGuard)	速い・監査済 No-Log・モバイルで省電力
企業のリモートアクセス (中小)	Tailscale, OpenVPN	Tailscale は配布・運用が楽。OpenVPN は枯れて文献豊富
企業のリモートアクセス (大規模)	Cloudflare Zero Trust, Zscaler, Palo Alto GlobalProtect	デバイスポスチャ・SAML/SCIM・WAN 統合が必要
Site-to-Site (本社⇔支社, クラウド⇔オンプレ)	IKEv2/IPsec	ベンダー間相互接続性・冗長化のエコシステムが厚い
自宅サーバ・自分のノマド端末を全部つなぐ	Tailscale, 自前 WireGuard	設定がシンプル・NAT 越えが楽
国家規模の検閲回避	OpenVPN over TCP/443, Shadowsocks, V2Ray	厳密には VPN ではないが、HTTPS にカモフラージュできる

PPTP と L2TP/IPsec を「新しく」採用する理由は、原則ない。 レガシー機器との互換目的を除いて、上の表に PPTP/L2TP は出てこない。

4. 運用で踏みやすい落とし穴 #

VPN は「繋がっている = 安全」と錯覚させやすい技術で、実装の隙間から素のトラフィックが漏れることが現実によく起きる。代表的な穴と確認方法:

4.1 DNS リーク #

VPN は張ったのに、DNS クエリだけは ISP の DNS に飛んでいた。結果、ISP に「どのドメインを見たか」が筒抜け。

確認: VPN 接続中に下記を実行し、返ってくる IP が VPN プロバイダ側 / 社内 DNS であれば OK。ISP のレンジならリーク。

dig +short whoami.akamai.net

対策: VPN 接続時に DNS サーバも VPN 内側のものに切り替える (Push "dhcp-option DNS x.x.x.x" 等)。Linux なら systemd-resolved + DNS-over-TLS の併用でシステム全体の DNS を強制する。

4.2 IPv6 リーク #

VPN クライアントがIPv4 だけトンネルし、IPv6 トラフィックは素のまま流れる。最近のサイトの多くが IPv6 対応なので実害が大きい。

確認: curl -6 ifconfig.me で自分の生 IPv6 が返ってきたらリーク。

対策: VPN 接続中は IPv6 を完全無効化するか、クライアントが IPv6 もトンネルすることを確認する。WireGuard はデフォルトで IPv6 対応。

4.3 Kill Switch がない #

VPN が切断された瞬間に素の回線に切り替わる OS の挙動。ユーザに気付かれず生 IP で通信が続く。市販 VPN クライアントには標準機能だが、自前 OpenVPN/WireGuard では iptables / nftables ルールで自分で実装する。

WireGuard で kill switch を効かせる例:

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) \
                -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) \
                -m addrtype ! --dst-type LOCAL -j REJECT

4.4 WebRTC リーク #

ブラウザの WebRTC API が VPN を経由せず生の LAN IP / 公衆 IP を JavaScript から取得可能 にしてしまう。匿名性目的のユーザは特に深刻。

確認: browserleaks.com/webrtc で生 IP が露出していたらリーク。

対策: ブラウザ拡張で WebRTC 無効化、または media.peerconnection.enabled = false (Firefox about:config)。

4.5 「VPN プロバイダ」を信用していいか #

個人向け VPN サービス (NordVPN, ExpressVPN, Mullvad, ProtonVPN ...) を使うとき、全トラフィックがそのプロバイダの GW を必ず通る。プロバイダ自身が悪意を持てば、内容は見えなくとも「いつ・どこに・どれだけ」のメタデータは取れる。

選定軸:

No-Log ポリシー + 第三者監査の実績 (Mullvad / ProtonVPN は監査履歴あり)
管轄国 (Five / Nine / Fourteen Eyes 加盟国を避ける思想か)
匿名支払い (現金 / Bitcoin で身元と切り離せるか)
物理サーバ vs RAM-only サーバ (再起動でデータ消失する設計か)

5. 企業 VPN ゲートウェイ脆弱性の系譜 #

VPN は「信頼の入口」として狙われやすく、特にSSL VPN 系ベンダー製品 は国家攻撃者の主要侵入経路になっている。VPN を運用する立場でこの系譜を 1 つも知らないのは無防備に近い。

年	製品 / CVE	内容
2018	Fortinet FortiGate SSL VPN / CVE-2018-13379	パストラバーサル → セッションファイル盗取。~50,000 台の認証情報が公開。2021〜2022 年も継続悪用
2019	Pulse Connect Secure / CVE-2019-11510	認証なしの任意ファイル読取。CISA / NSA / FBI 共同警告、Maze ランサム + APT が大量利用
2019	Citrix Gateway / ADC ("Shitrix") / CVE-2019-19781	ディレクトリトラバーサル → 認証なし RCE, CVSS 9.8
2020	SolarWinds Orion	サプライチェーン汚染 → 社内 VPN GW へ横展開。米連邦機関多数侵害。「VPN で守る境界」自体が脅威の侵入路に
2024	Palo Alto GlobalProtect / CVE-2024-3400	未認証 RCE, CVSS 10.0, 数か月の zero-day 悪用

示唆: VPN ゲートウェイはインターネットに常に晒されているため、最優先パッチ対象。MFA 必須 + クライアント証明書併用 + ベンダー CVE 監視 が現代の運用最低基準。

6. VPN の次 — ZTNA / SASE #

「社内 LAN に入る = 信頼」という従来 VPN の前提は、侵害された端末・委託先・SaaS 中心の業務 に合わなくなった。Google の BeyondCorp (2014〜) を皮切りに、Zero Trust Network Access (ZTNA) という発想が広まっている。

観点	従来 VPN	ZTNA
信頼境界	一度入ればその先全部にアクセス可	アプリ単位で個別承認
認証頻度	接続時に 1 回	リクエスト毎に再評価
デバイス	ユーザ認証だけ	デバイスポスチャ (パッチ / EDR / 暗号化状態) も
内部脅威	弱い (横展開を許す)	強い (横展開を遮断)
表現	「VPN へつなぐ」	「アプリへアクセスする」

代表製品: Cloudflare Zero Trust / Zscaler Private Access / Tailscale / Twingate / Cisco Duo + AnyConnect。これに WAN 側のセキュリティ (CASB / SWG / FWaaS) をクラウドで一体提供するのが SASE (Secure Access Service Edge, Gartner 2019)。

それで VPN は完全に無くなるのか? 短期的には併存が現実的:

ZTNA はアプリ単位の前提だが、レガシー業務アプリ (社内固有プロトコル, 古い ERP) は素通しの L3 ルーティングが要る → 結局 VPN
拠点間接続は IPsec/WireGuard が事実上唯一の選択肢
個人向けプライバシー VPN はそもそも企業 ZTNA とは別カテゴリ

中長期的には、「VPN プロトコル (WireGuard, IPsec) は ZTNA / SASE のデータ平面の中で生き続ける」 というのが現実的な見通し。プロトコルとしての VPN が消えるわけではなく、それを「トンネルを掘る道具」として制御平面が抽象化していく、というのが起きていることである。

VPN は「インターネットの上に専用線を擬似的に張る」というシンプルなアイデアから始まり、プロトコルの世代交代 (PPTP → L2TP/IPsec → OpenVPN → SSL VPN → WireGuard) と 運用モデルの世代交代 (境界防御 → ゼロトラスト) を、暗号と業務環境の進化に合わせて続けてきた。

利用者として大事なのは、「どの方式を選ぶか」(章 3) と 「素のトラフィックが漏れる隙間を塞ぐか」(章 4)、そして運用者として**「ゲートウェイ自身を最新に保つか」(章 5) である。「中身が暗号化されている」=「安全」ではない**。エンドツーエンドの認証・継続的なパッチ・デバイス側のチェックが揃って、はじめて VPN は本物の盾になる。