今からVPNについて説明してもらいます

Last updated at 2026-10-07Posted at 2026-10-07

助けてください、説明できません。
正直VPNの正式名称すら答えれませんでした。こっそり調べて"Virtual Private Network"
そうだよね。うんうん、と頷いています。

さて、仕事でサーバへ接続するときに VPNを使うことがあります。
ただ、調べる前の理解は「IP制限をかけるために使う、ネットワークの中継機」という程度でした。

では、VPNにつなぐとなぜ社内のサーバに届くのでしょうか。
そして、それがどうして安全につながるのでしょうか。
接続はできても、説明しろと言われると言葉に詰まります。

調べるきっかけになったのは、最近情報漏洩のニュースが多すぎる。

多くのシステムで流出してると聞いて、近いうちに社会問題になり、規制や認可が厳しくなると容易に予想されるので個人としてもセキュリティに関する勉強をしようと思ったからです。

話がそれましたが、VPNは何を守っていて、攻撃者はそのどこを突破しているのでしょうか。
ここでは、自宅などの社外から、社内ネットワークにあるサーバへ接続する想定で話します。

筆者はネットワークやセキュリティに詳しいわけではなく、この記事の内容は調べながら整理したものです。
調査、文章の作成、実験環境の作成には AI の補助を受けており、全文を筆者が確認しています。
仕様や事例は一次資料で確認し、実験は手元の隔離した環境で実行しています。
間違っているところがあれば、コメントなどでご指摘いただけると助かります。

そもそも VPN とは

とりあえずAIに説明させてみました。

VPN（Virtual Private Network） は、既存のネットワークの上で、参加者の通信をほかの利用者から論理的に分離する技術です。RFC 4026 §3.10
社外から使う場合は、インターネットから届く VPN ゲートウェイ を経由して、社内サーバ宛ての通信を社内へ届けます。
方式は複数あり、以降はインターネット越しの通信を暗号化し、相手を認証する VPN を対象にします。

まず疑問に思ったのは「論理的に」、「VPN ゲートウェイ」、「方式は複数（何に対する複数？）」とは一体なんなのか？

これを説明する前に先に接続方法について見てみましょう。全体像を把握することで理解しやすくなると思います。

まず、自宅から社内サーバへは、そのままでは届きません。
社内サーバには、10.77.0.10 のような プライベート IP アドレス が付いていることがよくあります。
このアドレス宛ての経路は、インターネット上にありません。RFC 1918 §3

そこで、インターネットからも届く場所に、社内への入口を1つ用意します。
端末は、社内サーバ宛ての元のパケット（内側）を、この入口宛てのパケット（外側）に包んで送ります。
入口は外側を外して内側を取り出し、社内の経路へ転送します。

つまり、

「論理的に」→ 専用の線を引いているわけではなく、自宅の回線もインターネットも他の人と同じものを使っています。包んだパケットを入口で取り出すことで、参加者の通信だけを1つのネットワークのように扱っている、ということでした。
「VPN ゲートウェイ」→ 上の図の入口のことです。包まれたパケットを受け取って中身を取り出し、社内へ転送します。
「方式は複数（何に対する複数？）」→ VPNはそもそも「他の利用者と分けた通信のグループを作る」技術の総称で、暗号化は必須ではありませんでした。RFC 4026 §3.10 インターネット越しに使うVPNでは、包み方や相手の確かめ方、暗号化の仕方が方式ごとに違います。代表的なものにIPsec、OpenVPN、WireGuardがあり、違いは「VPN の方式が違うと、何が変わるのか」で比べています。

ゲートウェイは専用機器の場合も、サーバ上のソフトウェアや Azure VPN Gateway のようなクラウドのサービスの場合もあります。

この記事で扱う構成

VPN の構成は 1 つではありません。
最初の図は、自宅の端末 1 台が、ゲートウェイ 1 つを経由して社内サーバへ入る、一番単純な構成です。
このように端末から社内へ入る構成を リモートアクセス VPN と呼び、この記事ではこの構成を扱います。
後半の実験も、端末、ゲートウェイ、社内サーバの 3 つだけで組んでいます。

拠点のネットワーク同士をつなぐ構成など、ほかの構成は「VPN の方式が違うと、何が変わるのか」で紹介します。

VPN が減らすのは、どんな危険か

次にVPNを利用する理由について考えてみましょう。

先ほどの図を見たときにまず思ったことがあります。
「いや、入口開けたら攻撃の穴を自ら開けていないか？」

入口は実際に攻撃の対象になります。
VPN ゲートウェイそのものが狙われた事例は、「攻撃者は、VPN のどこを使って入るのか」で紹介します。
それでも入口を用意するのは、管理画面をそれぞれインターネットへ直接公開する構成と比べて、外から狙える場所を減らせるからです。

管理画面をそれぞれインターネットへ直接公開すると、利用者以外もログインを試したり、管理画面の脆弱性を攻撃したりできます。
たとえば管理画面が 10 個あれば、外から直接狙える場所も 10 個です。

VPN を使う構成では、管理画面への直接接続を閉じ、外から届く場所をゲートウェイ 1 か所にします。
ゲートウェイの認証を通らない相手は、社内の管理画面まで通信を届けられません。
穴をなくすのではなく、開ける穴を 1 つにまとめ、そこで相手を確かめる、という考え方です。

なお、VPN を使わずに管理画面への直接接続を閉じる方法もあります。
アプリへのアクセスごとに利用者を確かめる中継を置く構成などで、「「VPN をなくしたほうが安全」は、何に置き換える話か」で紹介します。

その代わり、ゲートウェイは攻撃が集まる場所になります。
ここを突破されたときに社内のどこまで届くかは、「VPN を乗っ取られたら、本当に全部に入れるのか」で実験しています。

ここまでの話を整理すると、VPN を使う構成は次の 3 つを組み合わせて社内のサーバを守っています。

入口までの通信を暗号化する：この記事で対象にしている VPN は、自宅の端末からゲートウェイまでの通信を暗号化します。途中のインターネットで中身を読まれたり、書き換えられたりしないようにするためです。
社内への直接接続を閉じる：管理画面などにはインターネットから直接届かないようにし、外からの通信はゲートウェイ経由に限ります。
入口で相手を確かめる：ゲートウェイの認証を通った相手だけを、社内のネットワークへつなぎます。

ただ、どれも守れる範囲が決まっていて、それだけでは守れないものもあります。

守りたいもの	VPN を使う構成でできること	それだけでは決まらないこと
端末とゲートウェイの間の通信	暗号化し、途中での盗み見や改ざんに対処する	端末、ゲートウェイ、その先のサーバが侵害されていないか
サーバの接続口	インターネットから直接接続させず、入口をゲートウェイに絞る	ゲートウェイ自体の脆弱性や、そこから届く範囲
ネットワークへ参加する相手	登録した鍵や利用者の認証を通った相手に接続を認める	その人が、接続先のアプリで何をしてよいか

認証は、通信相手が登録した利用者や端末であることを確かめることです。
その相手に何を許すかを決めることは認可と呼びます。
実際には「VPN に参加してよい」「特定のサーバへ接続してよい」「そのサーバで顧客情報を読んでよい」と、複数の判断があります。
VPN 製品がいくつかをまとめて扱うことはあっても、接続できた事実だけで全部が許可されるわけではありません。

VPN と HTTPS では、暗号化する区間が違う

図の構成で VPN が暗号化するのは、端末からゲートウェイまでです。
ゲートウェイは暗号化を解く復号を行い、内側のパケットを社内へ転送します。
その中身が平文の HTTP なら、ゲートウェイや、その先で通信を観測できる装置から HTTP の内容を読めます。

そこで、社内の Web サーバとの通信自体も HTTPS にする意味があります。
HTTPS は、Web の要求や応答を運ぶ HTTP を、TLS（Transport Layer Security） という仕組みで保護した通信です。
TLS は接続相手を確認し、通信内容を暗号化して盗み見や改ざんを防ぎます。TLS 1.3 の仕様

HTTPS で接続するとき、ブラウザなどはサーバが提示する 証明書 を確認します。
証明書にはサーバの名前などが記されていて、その情報が信頼できるか、接続先と一致するかを検証します。
TLS は、証明書の検証と暗号化用の鍵の合意によって、確認した相手との通信を保護します。
途中で通信を受け取っただけの第三者には、その内容を読めません。

TLS の仕組み（証明書の検証や鍵の合意がどう進むのか）については、また別の記事にしようと思います。
ここでは、VPN と暗号化する区間がどう違うかに絞ります。

社内 Web サーバで HTTPS を復号する構成なら、2 つの暗号化の区間は次のようになります。

暗号化する仕組み	区間	暗号化を解く相手
VPN	端末 → VPN ゲートウェイ	VPN ゲートウェイ
HTTPS の TLS	端末のブラウザなど → 社内 Web サーバ	社内 Web サーバ

VPN ゲートウェイが外側の VPN の暗号化を解いても、中には TLS で暗号化された通信が残ります。
ゲートウェイで HTTPS を復号せず、端末が証明書を正しく検証し、両端の鍵が守られていれば、VPN の経路を奪っただけで HTTPS の本文が読める状態にはなりません。
ただし、経路上の装置は接続先 IP や通信量を観測したり、通信を止めたりできます。

暗号化が守るのは、その両端の間を流れるデータです。
端末やサーバ上で実行されるプログラムや、データを読む権限まで安全にする機能ではありません。

VPN の方式が違うと、何が変わるのか

VPN の構成には、端末 1 台から社内へ入るものと、拠点のネットワーク同士を結ぶものがあります。
前者がこの記事で扱っているリモートアクセス VPN、後者は 拠点間 VPN と呼ばれます。
拠点間 VPN では、各拠点のゲートウェイ同士が通信を受け渡します。構成の例：Azure VPN Gateway

何と何をつなぐかに加えて、通信を保護する方式にも違いがあります。
代表的なものを、認証と暗号化の違いに絞ると次のようになります。

方式やソフトウェア	相手を確かめ、通信を保護する仕組み
IPsec / IKEv2	IP パケットを保護する IPsec と、相手の認証や鍵の合意を担当する IKEv2 を組み合わせます。証明書や事前に共有した秘密の値などで相手を確認します。IPsec、IKEv2
OpenVPN	VPN を構成するソフトウェアです。TLS を使う構成では、証明書などで相手を認証し、データの暗号化に使う鍵を交換します。VPN の通信を運ぶ方式は UDP または TCP を選べます。公式マニュアル
WireGuard	VPN の通信方式と、それを実装したソフトウェアです。登録した相手の公開鍵を基に認証し、暗号化した IP パケットを UDP で運びます。公式の仕組みの説明

UDP と TCP は、IP の上でアプリのデータを運ぶ方式です。
TCP はデータの抜けを再送で補い、送った順にアプリへ渡す仕組みを持ちます。
UDP 自体には、この順序や再送を管理する機能はありません。TCP の仕様、UDP の仕様
どちらを使うかは、利用できるネットワークや通信の振る舞いに関係しますが、それだけで VPN 全体の安全性は決まりません。

WireGuard でいう鍵には、相手に知らせて登録する 公開鍵 と、自分だけが保持する 秘密鍵 の組があります。
WireGuard は、登録した公開鍵に対応する秘密鍵を持つ相手かどうかを確かめます。
その鍵を持つ人の氏名や在籍状況を WireGuard 自体が調べるわけではなく、誰に利用を認め、いつ無効化するかは周辺システムや運用で管理します。

通信の方式を実装した製品には、ログイン画面や管理機能などが組み合わされることもあります。
その部分の不具合で装置を操作される問題は、暗号方式そのものを解読される問題と分けて考える必要があります。

攻撃者は、VPN のどこを使って入るのか

VPN を経由した侵入には、暗号を解読せずに成立する手口があります。
警察庁が挙げる、漏えいした認証情報の悪用と、機器の脆弱性の悪用がその例です。ランサムウェアの手口

認証情報を盗み、利用者として入る

攻撃者が VPN のパスワードや必要な鍵を手に入れ、その認証条件を満たせば、利用者と同じ接続口を使えます。
VPN から見ると、必要な認証情報を持った相手との通信です。
強い暗号化を使っていても、その中を攻撃者の通信が通ります。

多要素認証は、パスワードだけを盗まれた場合に備える対策です。
たとえば、パスワードに加えて、別の認証器による確認を求めます。
ただし、認証後の端末や、ログイン済みの状態を維持するセッションの認証情報を奪われる場合まで、ログイン時の本人確認だけで防げるとは限りません。
使う認証方式と、何を盗まれた想定なのかを分ける必要があります。

VPN 装置の不具合から、装置そのものへ入る

もう 1 つは、VPN ゲートウェイ上のソフトウェアの脆弱性を使う方法です。
ログイン判定を迂回されたり、装置上で攻撃者の命令を実行されたりする場合があります。
その場合、通常のログインに多要素認証を追加しても、脆弱性自体は修復されません。

実際の侵入の一例に、Ivanti Connect Secure という製品への攻撃があります。
社外の端末から社内のシステムへ接続するための、企業向け VPN 製品です。製品の説明

2024 年に米国のサイバーセキュリティ当局 CISA などが出した共同勧告では、この製品などの脆弱性が使われ、装置に遠隔操作用のプログラムが置かれたと報告されています。
攻撃者は装置内の認証情報を取得し、さらに組織内の別のシステムへ侵入を広げていました。
一部では、組織のアカウントやコンピュータをまとめて管理するドメイン全体の侵害に至ったとされています。共同勧告 AA24-060B

入口から、情報を盗むところまでには段階がある

次の図は、公開された手口を基にした侵入拡大の説明例です。
すべての攻撃がこの順序で進むわけではありません。

認証情報や VPN 装置の脆弱性を悪用する
  ↓
内部ネットワークへ接続できるようになる
  ↓  届く接続先を調べる
別のサーバの認証情報や脆弱性を悪用する
  ↓  得た権限で扱えるデータが増える
情報を持ち出す、業務データを暗号化する

最初の侵入先から別のシステムへ移る動きを 横展開 と呼びます。
ネットワークで届くこと、サーバにログインできること、顧客情報を読めることは、それぞれ別の条件です。
攻撃者は、届く範囲にある弱い認証や過大な権限を利用し、この条件を順に満たそうとします。

VPN のアカウントを 1 つ盗まれた場合と、ゲートウェイの管理者権限を奪われた場合では、できることも違います。
前者はまずその利用者に許された接続範囲が問題になり、後者ではゲートウェイの設定や通過する通信自体が操作され得ます。
どちらも重大ですが、「VPN が侵害された」という一言だけでは、被害範囲は決まりません。

VPN を乗っ取られたら、本当に全部に入れるのか

ゲートウェイ上で動くプログラムから、社内のサーバへはどこまで届くのでしょうか。
これを確かめるため、1 台のパソコン上に、端末、VPN ゲートウェイ、社内サーバ役の 3 つを分けた実験環境を作りました。
それぞれを独立した環境で動かす Docker のコンテナとして用意しています。

VPN の処理には、先ほどの表で紹介した WireGuard を使いました。
通信を転送する規則と、ゲートウェイ自身が送る通信の規則を分けて設定し、届き方の違いを調べます。
端末を client、ゲートウェイを gateway、社内サーバ役を target と呼びます。

client                  gateway                    target
VPN 内: 10.66.0.2  →  VPN 内: 10.66.0.1
                     社内側: 10.77.0.2      →   10.77.0.10:8080

target は HTTP で応答するだけのサーバで、アプリ側の認証は付けていません。
gateway は、許可した通信だけを社内側へ転送する設定です。
この実験では、脆弱性を攻撃して侵入する処理は行いません。
ゲートウェイ上でプログラムを実行できる状態になったあと、どこへ接続できるかを調べます。

端末を止めた規則が、ゲートウェイ自身を止めるとは限らない

まず、client から target への転送許可を外しました。
VPN の相手との通信は続いていますが、HTTP 接続はタイムアウトしました。
次に、同じ HTTP リクエストを gateway 自身から送ると、応答が返りました。

以下が、そのときの実際の出力です。
curl は指定した URL へ通信するコマンドで、この例では同じ HTTP サーバへアクセスしています。
$ client: と $ gateway: はスクリプトがコマンドを実行したコンテナ名を示す注記で、そのままシェルへ貼る記法ではありません。

$ client: curl --noproxy '*' -sS --connect-timeout 2 --max-time 3 http://10.77.0.10:8080/vpn-lab-marker
curl: (28) Connection timed out after 2006 milliseconds
exit=28
$ gateway: curl --noproxy '*' -sS --connect-timeout 2 --max-time 3 http://10.77.0.10:8080/vpn-lab-marker
peer=10.77.0.2
exit=0

peer=10.77.0.2 は、サーバが見た接続元の IP アドレスです。
端末からの中継は止まっていても、社内側に接続口を持つゲートウェイ自身からの通信は届いています。

ゲートウェイは、端末から届いた通信を中継するだけでなく、自分自身で通信を始めることもできます。
今回の設定では、その 2 つに別の許可規則が適用されます。
図には、端末から中継する通信と、ゲートウェイ上の curl が始める通信を描いています。

通信の通過を許可したり拒否したりする機能を ファイアウォール と呼びます。
実験で使った Linux のファイアウォールでは、中継する通信の規則を FORWARD、装置自身が送る通信の規則を OUTPUT と呼び分けます。
端末からの中継を止めても、自身からの送信を許可したままなら、ゲートウェイ上の curl が始めた通信は届きます。Netfilter のパケット処理

この結果は、すべての VPN 製品で同じ制限を回避できるという意味ではありません。
この結果が示すのは、端末からの接続を制限しただけでは、ゲートウェイ自身が接続できる範囲まで制限したことにならないという構成上の違いです。
さらに、ゲートウェイの設定を変更できる管理者権限まで奪われたら、その装置上にある規則自体を書き換えられる可能性があります。

実験環境と設定条件

macOS の OrbStack 上で Docker Engine 29.4.0 を使い、Linux 7.0.14 のコンテナ内で実行しました。
コンテナは Alpine Linux 3.22.6、wireguard-tools 1.0.20250521、iproute2 6.15.0、curl 8.14.1、iptables 1.8.11、tcpdump 4.99.5、Python 3.12.14 です。

端末とゲートウェイをつなぐネットワークと、ゲートウェイと社内サーバ役をつなぐネットワークを別々に作っています。
実際のインターネットや社内ネットワークへ通信する実験ではありません。

対象	実験での設定
端末	WireGuard によりゲートウェイへ接続。社内サーバ宛ての経路を設定
ゲートウェイ	社内サーバへの転送を有効化。中継は許可規則に一致する通信だけを通し、自身からの送信は許可
社内サーバ役	TCP の 8080 番ポートで HTTP 応答を返す。端末への返信をゲートウェイへ戻す経路を設定。アプリの認証はなし
遮断した通信	端末から社内サーバ役の TCP 8080 番へ中継する通信
接続先	`http://10.77.0.10:8080/vpn-lab-marker`

掲載した curl の --noproxy '*' はプロキシ経由を除外し、-sS は進捗表示を消してエラーを残す指定です。
--connect-timeout 2 で接続を 2 秒、--max-time 3 で通信全体を 3 秒に制限しています。
タイムアウトの実測時間は実行ごとに多少変わります。
IPv4 の Linux 環境での結果で、IPv6 やほかの VPN 方式の実測は含みません。

IP 制限は、どの相手を見分けているか

この実験では、ゲートウェイで SNAT（送信元 IP アドレスの変換） を有効にするケースも用意しました。
端末からの通信であっても、サーバに見える接続元は次のように変わります。Netfilter の SNAT の説明

接続の仕方	サーバが返した接続元
端末から VPN 経由、SNAT なし	`peer=10.66.0.2`
端末から VPN 経由、SNAT あり	`peer=10.77.0.2`
ゲートウェイ自身から接続	`peer=10.77.0.2`

固定の出口 IP を使う構成で、サーバがその IP だけを許可すれば、ほかの出口からの接続を制限できます。
ただし、その IP は個々の利用者の身元を示しません。
同じ出口を使う別の利用者も、出口の装置を使える攻撃者も、接続先からは同じ IP に見えることがあります。
実験の値は社内側の IP ですが、出口の IP を許可する判断で何を区別できるかは同じです。

「VPN を通っているから許可する」という設計では、VPN の入口の認証や、入口から先への制御に大きく依存します。
アプリ自身が利用者を認証し、必要な操作だけを許す設計なら、接続元 IP 以外の条件も確認できます。

被害が広がる構成と、途中で止められる構成

ゲートウェイから全サーバに届く、社内 IP からなら認証なしで使える、強い管理者権限を共有している、といった条件が重なるほど、入口 1 台の侵害から広い被害につながりやすくなります。

一方、ゲートウェイの管理権限では変更できない場所で接続先を制限し、各アプリにも独立した認証と操作ごとの権限があれば、攻撃者が満たす必要のある条件を増やせます。
ここでいう独立とは、装置が別というだけでなく、VPN 装置を管理する権限でその制限まで解除できないことです。
警察庁も、公開機器から届く範囲と、アカウントの権限を必要最小限にする対策を挙げています。アクセス権限の最小化

アプリの認証を足す場合も、その認証情報を平文の HTTP で送れば、侵害されたゲートウェイに盗み見られる可能性があります。
接続先までの HTTPS など、認証情報を運ぶ区間の保護も必要です。
今回の実験で確認したのは認証なしの HTTP サーバへの到達範囲で、アプリ認証や HTTPS による防御は実測していません。

踏み台サーバも、接続先を絞り、操作する人を認証する場所として組み合わせられます。
SSH の ProxyJump は、踏み台を経由して目的のサーバへ接続する機能です。
VPN が IP 通信の経路を用意するのに対し、こちらは SSH の接続を中継します。
目的サーバとの SSH 認証も別に行われます。OpenSSH の -J

ただし、踏み台に全サーバへ強い権限で接続できる秘密鍵を置けば、その踏み台も権限が集中する場所になります。
VPN と踏み台を何段重ねたかだけでは、侵害後の被害範囲は判断できません。
アプリの脆弱性や盗まれた追加の認証情報があれば、途中の制限も突破され得ます。

「VPN をなくしたほうが安全」は、何に置き換える話か

VPN を外して、社内サーバをそのままインターネットへ公開すると、これまでゲートウェイで絞っていた接続口を広げることになります。

VPN を使わずに安全なアクセスを設計する場合は、必要な機能を別の仕組みで担います。
たとえば Web の管理画面だけが必要なら、そのアプリへのアクセスごとに利用者や端末を確認する方式が候補です。
ネットワーク全体への参加を許す代わりに、対象のアプリと操作を指定して許可します。
接続先を細かく絞る設計は、VPN を残したままでも取り入れられます。

ゼロトラスト は、ネットワークの内側にいるという理由だけで、相手を無条件に信頼しない考え方です。
利用者や端末、アクセス先に応じて認証と認可を行います。
特定の VPN 製品を撤去すること自体が定義ではありません。NIST SP 800-207

英国の国家サイバーセキュリティセンター（NCSC）も、ゼロトラストと VPN は両立すると説明しています。
VPN を残すかどうかは、必要な保護と組織の状況で判断し、既存の対策を外す際には代わりの対策を用意する必要があります。NCSC: Demystifying Zero Trust

新しいアクセス用の中継装置や、利用者を認証する基盤も、ソフトウェアとして管理する対象です。
そこが侵害されたときに何を許してしまうかは、移行後も残る問いです。
「VPN があるか」だけを比較しても、安全性の優劣は決まりません。

VPN を使い続ける場合も、機器を更新し、必要な相手と接続先だけに許可を絞り、不要になった権限を失効できることが前提になります。
NSA と CISA の VPN 向け指針も、強い認証、迅速な更新、不要な機能を減らすことを挙げています。VPN の選定と堅牢化の指針

なお、個人向け VPN の広告でいうプライバシー保護と、ここまでの社内アクセスは目的が違います。
普段の Web 閲覧で VPN サービスを契約すべきかという話を、そのまま案件の VPN を廃止する根拠にはできません。

まとめ

VPN は、既存のネットワーク上に参加者の通信を分離した経路を作ります。暗号化や相手認証を備えた方式でも、サーバでの操作権限は別に設計する必要があります。
VPN を使う構成は、通信の保護とサーバへの直接接続の制限に役立ちます。ゲートウェイの脆弱性や、正規の認証情報の悪用までは、それだけで防げません。
VPN の侵害からどこまで被害が広がるかは、到達できる範囲、奪われた権限、接続先の認証と認可で変わります。侵害された装置の権限では解除できない制限が重要です。
VPN をなくす判断には、代わりに何が接続と操作を制限するのかという設計が必要です。VPN とゼロトラストは両立します。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up