VPN (Virtual Private Network) は、公開ネットワークの上に「自分たちだけがアクセスできる暗号化された仮想専用線」を張る技術の総称。本稿では トンネリングという仕組み を押さえたうえで、リモートアクセス vs Site-to-Site、PPTP → WireGuard の世代交代と現代の選び方、DNS / IPv6 / kill switch などの実装上の落とし穴、企業 VPN ゲートウェイ脆弱性の系譜、ZTNA / SASE という後継モデルまでを通しで扱う。
難しく見えても本質は次の 3 つだけ。(1) VPN は 「インターネットの中に作る、自分専用のトンネル」。中を通る通信は外から覗かれないし、出口を変えることで 「あたかも別の場所からアクセスしている」ように見せられる。(2) 主な用途は (a) 公衆 Wi-Fi での盗聴防止 / (b) リモートワークで会社の LAN に入る / (c) 海外サーバ経由で検閲・地域制限を回避 の 3 系統。(3) 「VPN を張れば全部安全」ではない — DNS / IPv6 / 切断時の挙動など、漏れる隙間がいくつもある (§05)。— ここを土台に各章を順に開いていけばいい。
仕組み — トンネルとカプセル化 #
VPN の本質は 「もう 1 つの IP パケットの中に、本来の IP パケットを暗号化して詰める」 という単純な発想。これを トンネリング (tunneling) と呼ぶ。
普通の郵便で「A → B 宛」の封筒を出すと、配達員も中継局も 「A から B 宛に何かを送った」事実が見える。VPN は その封筒をもう一回り大きな封筒に入れ、中身は鍵をかけて読めなくする仕組み。外側の封筒には 「自分の家 → VPN 業者の倉庫」 とだけ書いてあるので、間の配達員には「業者の倉庫に何か送った」しか見えない。倉庫で外側の封筒を開け、中の本物の封筒を本来の宛先 B に投函しなおす — これがトンネリングの正体。暗号方式や封筒形式が違うだけで PPTP も IPsec も WireGuard もこの 1 行に集約できる。
自分で動かして確かめる — クライアントの通信がゲートウェイで暗号化トンネルを通り、宛先に届いて戻ってくるまでを 1 ステップずつ追える。
# VPN なし — 素の IP パケットがそのまま流れる
[ IP 10.0.0.5→10.0.0.20 ][ TCP 443 ][ HTTP / DB / etc ]
# VPN あり — 元パケットを暗号化して外側パケットに封入
[ 外側 IP 公衆 IP→VPN GW ][ UDP 51820 ][ VPN hdr ][ 暗号化された元パケット (IP+TCP+App) ]
▲ 中身は復号鍵を持つ両端だけが読めるポイントは:
- 「外側」 と「内側」が独立した IP 空間 を持てる。クライアントが社内 IP
10.0.0.5を貰い、社内サーバと「同じ LAN にいるかのように」通信できる - 外側の中継機器 (ISP / ルータ / Wi-Fi AP / 検閲機構) からは内側のパケットが見えない。見えるのは「どこかの公衆 IP から VPN GW 宛の暗号化通信」のみ
- VPN GW で復号され、元パケットとして社内ネットに流れる。社内サーバから見ると「社内 IP からの普通の接続」
PPTP / IPsec / OpenVPN / WireGuard などすべての VPN プロトコルに共通する骨格は「もう 1 段階の IP 封入」。違うのは 外側パケットの形式 (UDP/TCP, GRE/ESP)、VPN ヘッダの中身 (鍵交換, 改ざん検出, 順序保証)、暗号アルゴリズム だけ。
2 つの形態 — リモートアクセス と Site-to-Site #
VPN は「何と何を繋ぐか」で大きく 2 形態に分かれる。仕組みは同じでも運用・選定基準が大きく違う。
リモートアクセス VPN は 1 人の社員が家から会社の LAN に入る形 — VPN を張った瞬間、その PC は 「会社のデスクの上にいる」のと同じ扱いになる。Site-to-Site VPN は 会社と支社を結ぶ「常時接続の専用線」を、インターネットの上に擬似的に張ったもの。利用者 (社員) は VPN の存在すら意識せず、「東京本社のサーバが大阪支社の机からも見える」状態が当たり前にある。個人で使う VPN サービスは前者、企業ネットワークの裏側で動いているのは後者、と覚えればよい。
リモートアクセス VPN #
1 人のクライアント (PC / スマホ) が公衆インターネット越しに社内 LAN や VPN プロバイダの拠点へ入る形態。リモートワーク・出張先からの社内アクセス・個人向け匿名 VPN サービスはすべてここに含まれる。
設計の論点:
- クライアントごとの認証 (パスワード, 証明書, TOTP, デバイスポスチャ = ウイルス対策・パッチ・ディスク暗号化の検査)
- 動的な内側 IP 配布 (DHCP に近い) と DNS / 検索ドメインの注入
- スプリットトンネリング (社内宛だけ VPN を通し、その他は素で出す) を有効にすべきか — 帯域は節約できるが社内の DNS / 監視を経由しなくなるため賛否が分かれる
- ユーザは専用クライアントソフトを入れるのが普通 (OpenVPN GUI, Cisco AnyConnect, WireGuard アプリ)
Site-to-Site VPN #
ルータ / ファイアウォール同士が常時 VPN トンネルを張り、離れた拠点の LAN を 1 つに見せる形態。本社 ⇔ 支社、本社 ⇔ AWS VPC、本社 ⇔ Azure VNet、データセンター間冗長化 — 企業ネットワークの裏側で大量に動いている。
設計の論点:
- ルータ間で事前共有鍵 (PSK) または証明書で認証
- トンネルは常時張りっぱなし、ユーザは VPN を意識しない
- IPsec (IKEv2) が事実上の標準。Cisco / Fortinet / Juniper / クラウド事業者すべてが対応
- ルーティング (静的 or BGP) で拠点間の経路を交換することが多い
- 冗長化 (Active/Standby のトンネル, 複数 GW) が運用要件に絡む
プロトコルの世代交代 — PPTP から WireGuard まで #
VPN プロトコルは「過去 30 年の暗号と運用要件の変化に合わせて世代交代してきた集合」として理解するのが速い。
プロトコル名がたくさん出てきて圧倒されるが、今から学ぶなら覚えるべきは 2 つだけ。(1) WireGuard — 個人プライバシー VPN / 自宅サーバ / Tailscale の中核。速い・省電力・設定が短いのが取り柄で、迷ったらまずこれ。(2) IKEv2/IPsec — iPhone の「Always On VPN」や会社の拠点間接続 (Site-to-Site) の事実上の標準。モバイル網と Wi-Fi を行き来しても切れにくいのが特徴。PPTP / L2TP は「過去にこういうのがあった」程度に知っておけば十分で、新規構築では絶対に選ばない (理由は本章で順に出てくる)。
PPTP (1996, Microsoft) — 使ってはいけない #
Windows NT 4.0 / 98 にバンドルされて爆発的に普及。PPP を GRE トンネルで包む設計で、当時は画期的だった。しかし認証 (MS-CHAPv2) は 2012 年に Moxie Marlinspike が事実上の総当たり破りを公表、暗号 (MPPE) も 40/128-bit RC4 に依存しており現代の暗号要件を満たせない。今でも一部のレガシー機器に残っていることがあるが、発見次第無効化するのが正しい対応。
L2TP/IPsec (1999) — レガシーの主流 #
Cisco の L2F + Microsoft の PPTP を統合した L2TP (RFC 2661) を、IPsec ESP で暗号化したコンビ。OS 標準で動くため 2000 年代の企業 VPN の主流だった。仕様自体に大きな問題はないが、NAT 越え (NAT-T) の構成が面倒、事前共有鍵が運用で漏れやすい、設定パラメータが多すぎて互換性で詰みがちで新規構築には推奨されない。
IKEv2/IPsec — 現代主流 #
IPsec の鍵交換 (IKE) を第 2 版に作り直したもの。Cisco, Microsoft Always On VPN, Apple iOS 標準 VPN で最も普及している現代版 IPsec。
- MOBIKE で Wi-Fi ↔ 4G/5G の切替時にもセッション維持 → モバイルに強い
- AES-GCM / ChaCha20-Poly1305 で AEAD、PFS (Forward Secrecy) も標準
- NAT-T が標準内蔵
- ハードウェアアクセラレータが普及していて速い
Site-to-Site VPN の事実上の標準であり、iPhone から会社につなぐ「Always On VPN」もこれが主役。
OpenVPN (2001) — 「TCP/443 が通る場所なら必ず動く」 #
TLS の上に独自バイナリプロトコルを載せるユーザ空間 VPN。James Yonan が公開し、TCP でも UDP でも動く・TCP/443 でも動くことから空港・ホテル・国家ファイアウォール越えの定番。クロスプラットフォーム、設定が .ovpn 1 ファイルにまとまるシンプルさが個人向け VPN サービスでの採用理由。ユーザ空間で動くため IKEv2/WireGuard より遅い。
SSL VPN — 「ブラウザだけで使える」 #
HTTPS (TCP/443) に乗せた VPN。Cisco AnyConnect / Fortinet SSL VPN / Pulse Connect Secure / Palo Alto GlobalProtect / SonicWall などのベンダーが提供する企業向けリモートアクセスの主役。**「443/tcp さえ開いていれば動く」「ブラウザでログイン → クライアントが落ちてくる」**という運用しやすさで爆発的に普及。後述の通りこの層のベンダー脆弱性が現代企業侵害の主要経路になっている。
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 寄りの製品で、今もっとも勢いがある。
結局どれを使うか — 用途別の選択 #
| 用途 | 推奨 | 理由 |
|---|---|---|
| 個人プライバシー (公衆 Wi-Fi 防衛 / 検閲回避) | Mullvad, ProtonVPN (WireGuard) | 速い・監査済 No-Log・モバイルで省電力 |
| 企業のリモートアクセス (中小) | Tailscale, OpenVPN | Tailscale は配布・運用が楽。OpenVPN は枯れて文献豊富 |
| 企業のリモートアクセス (大規模) | Cloudflare Zero Trust, Zscaler, GlobalProtect | デバイスポスチャ・SAML/SCIM・WAN 統合が必要 |
| Site-to-Site (本社⇔支社 / クラウド⇔オンプレ) | IKEv2/IPsec | ベンダー間相互接続性・冗長化のエコシステムが厚い |
| 自宅サーバ・ノマド端末 | Tailscale, 自前 WireGuard | 設定がシンプル・NAT 越えが楽 |
| 国家規模の検閲回避 | OpenVPN over TCP/443, Shadowsocks, V2Ray | 厳密には VPN ではないが HTTPS にカモフラージュ可 |
レガシー機器との互換目的を除いて、上の表に PPTP/L2TP は出てこない。新規構築では選択肢から外すのが原則。
運用で踏みやすい落とし穴 #
VPN は「繋がっている = 安全」と錯覚させやすい技術で、実装の隙間から素のトラフィックが漏れることが現実によく起きる。
「VPN ON」ランプが点いていても、素のトラフィックがどこかから漏れていることは現実に頻繁にある。接続後に毎回確認すべき 4 点。(1) IP は変わったか — ifconfig.me で VPN プロバイダの IP が出るか。(2) DNS リーク — dnsleaktest.com で ISP の DNS が混ざっていないか。(3) IPv6 リーク — curl -6 ifconfig.me で素の IPv6 が返ってこないか。(4) WebRTC リーク — browserleaks.com/webrtc でブラウザから生 IP が見えていないか。この 4 点だけは毎回必ず習慣化しておくと、「気付かないうちに丸見え」事故を構造的に防げる。
DNS リーク #
VPN は張ったのに、DNS クエリだけは ISP の DNS に飛んでいた。結果、ISP に「どのドメインを見たか」が筒抜け。
$ dig +short whoami.akamai.net
10.45.67.89 # この IP が VPN プロバイダ / 社内 DNS なら OK
# ISP のレンジならリーク対策: VPN 接続時に DNS サーバも VPN 内側のものに切り替える (Push "dhcp-option DNS x.x.x.x")。Linux なら systemd-resolved + DNS-over-TLS でシステム全体の DNS を強制。
IPv6 リーク #
VPN クライアントが IPv4 だけトンネルし、IPv6 トラフィックは素のまま流れる。最近のサイトの多くが IPv6 対応なので実害が大きい。
$ curl -6 ifconfig.me
2401:abcd:... # 生 IPv6 が返ったらリーク対策: VPN 接続中は IPv6 を完全無効化するか、クライアントが IPv6 もトンネルすることを確認する。WireGuard はデフォルトで IPv6 対応。
Kill Switch がない #
VPN が切断された瞬間に素の回線に切り替わる OS の挙動。ユーザに気付かれず生 IP で通信が続く。市販 VPN クライアントには標準機能だが、自前 OpenVPN/WireGuard では iptables / nftables で自分で実装する。
# [Interface] セクションに追記
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 REJECTWebRTC リーク #
ブラウザの WebRTC API が VPN を経由せず生の LAN IP / 公衆 IP を JavaScript から取得可能にしてしまう。匿名性目的のユーザは特に深刻。
確認: browserleaks.com/webrtc で生 IP が露出していたらリーク。対策: ブラウザ拡張で WebRTC 無効化、または Firefox の about:config で media.peerconnection.enabled = false。
個人向け VPN サービスを使うとき、全トラフィックがそのプロバイダの GW を必ず通る。プロバイダが悪意を持てば中身は見えなくとも「いつ・どこに・どれだけ」のメタデータは取れる。選定軸: ① No-Log + 第三者監査 (Mullvad / ProtonVPN は監査履歴あり) / ② 管轄国 (Five/Nine/Fourteen Eyes 加盟国を避ける思想) / ③ 匿名支払い (現金 / Bitcoin) / ④ 物理サーバ vs RAM-only サーバ。
企業 VPN ゲートウェイ脆弱性の系譜 #
VPN は「信頼の入口」として狙われやすく、特に SSL VPN 系ベンダー製品は国家攻撃者の主要侵入経路になっている。
VPN ゲートウェイは 「会社の玄関ドア」。インターネット側にずっと顔を出している入口なので、ドア自体に穴が空くと、その先の社内全部が丸ごと侵入される。下表は実際にそれが起きた歴史で、Fortinet / Pulse / Citrix / Palo Alto は 「VPN GW を起点に企業 LAN へ広がる」パターンが繰り返し発生した典型例。教訓はシンプルで、「VPN GW のパッチ適用は最優先 / ベンダー CVE を購読する / MFA + クライアント証明書を必ず併用」の 3 点に集約される。
| 年 | 製品 / CVE | 内容 |
|---|---|---|
| 2018 | Fortinet FortiGate SSL VPN / CVE-2018-13379 | パストラバーサル → セッションファイル盗取。約 50,000 台の認証情報が公開。2021-22 年も継続悪用 |
| 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 監視が現代の運用最低基準。
VPN の次 — ZTNA / SASE #
「社内 LAN に入る = 信頼」という従来 VPN の前提は、侵害された端末・委託先・SaaS 中心の業務に合わなくなった。Google の BeyondCorp (2014〜) を皮切りに、Zero Trust Network Access (ZTNA) が広まっている。
従来の VPN は 「会社のドアの鍵」を 1 個渡して、入ったら社内は自由に歩ける方式。だから 鍵が 1 個盗まれると社内全部が見られる。ZTNA は 「人事システムの鍵」「経理システムの鍵」を必要な人にだけ別々に渡す方式 — 1 個盗まれても他のドアは開かないし、鍵を渡す前に毎回 「あなたは誰?」「PC のパッチは最新?」を確認する。「LAN に入る」から「アプリに入る」への発想転換、と覚えればよい。SASE はこの ZTNA に WAN 側のセキュリティ機能をクラウドでまとめて提供するパッケージ、というだけの違い。
| 観点 | 従来 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)。
短期的には併存が現実的。ZTNA はアプリ単位だが、レガシー業務アプリは素通しの L3 ルーティングが要る → 結局 VPN。拠点間接続は IPsec/WireGuard が事実上唯一の選択肢。個人向けプライバシー VPN は別カテゴリ。中長期的には「VPN プロトコル (WireGuard, IPsec) は ZTNA / SASE のデータ平面で生き続ける」 — 制御平面が抽象化されていく、というのが起きていること。
まとめ #
- VPN は「インターネットの上に専用線を擬似的に張る」シンプルなアイデアから、暗号と業務環境の進化に合わせ世代交代してきた
- 利用者として大事なのは ① どの方式を選ぶか (WireGuard 主軸) / ② 素のトラフィックが漏れる隙間を塞ぐか (DNS / IPv6 / WebRTC / kill switch)
- 運用者として大事なのは ③ ゲートウェイ自身を最新に保つか (Fortinet / Pulse / Citrix / Palo Alto の系譜を見れば自明)
- 「中身が暗号化されている」=「安全」ではない。エンドツーエンドの認証・継続的パッチ・デバイス側のチェックが揃って、はじめて本物の盾になる
