VPNの仕組みと構築入門｜WireGuard・OpenVPN・IPsecの違いとサーバー間接続の実践

「社外から社内のDBに安全につなぎたい」「オフィスとクラウドのVPCをまるごとつなぎたい」「本番サーバーのSSHをインターネットに公開したくない」。こうした要望を受けたとき、選択肢として最初に挙がるのがVPNです。しかし、WireGuard・OpenVPN・IPsecと名前は知っていても、何がどう違い、どれを選べばよいかを説明できる人は多くありません。

この記事では、VPNの根本にあるトンネリングと暗号化の考え方から、リモートアクセス型と拠点間型の使い分け、3方式の比較、WireGuardでサーバー同士をつなぐ最小構成の手順、そしてクラウドのSite-to-Site VPNとの関係までを解説します。最後に「VPNを入れても解決しないこと」も整理するので、ゼロトラストとの棲み分けを含めた判断ができるようになります。

VPNの仕組み｜トンネリングと暗号化

パケットをパケットで包む

VPN（Virtual Private Network）の中核はトンネリングです。これは「本来のIPパケットを丸ごと別のパケットのペイロードに包んで運ぶ」技術で、たとえば10.0.0.5宛てのパケットを、インターネットを越えられるグローバルIP宛てのUDPパケットの中に入れて送ります。受け取った側は外側を剥がして、中の10.0.0.5宛てパケットを自分のネットワークに流します。これによって、物理的には離れた2つのネットワークが、あたかも同じLANにいるかのように振る舞えます。

包むだけでは中身が丸見えなので、ペイロードを暗号化し、改ざんされていないことを検証する認証タグを付けます。「トンネル＋暗号化＋相手の認証」の3点セットがVPNの本質で、3方式の違いはこの3点をどう実現しているかの違いです。

リモートアクセス型と拠点間型

用途は大きく2つに分かれます。リモートアクセス型は、個人のPCやスマホから社内ネットワークやクラウドVPCに入るもので、在宅勤務や外出先からの管理作業に使います。拠点間型（Site-to-Site）は、オフィスのルーターとクラウドのVPN機器のように、ネットワーク同士を常時つなぐものです。前者はクライアントごとに鍵や証明書を配る運用が中心になり、後者は経路（ルーティング）設計が中心になります。

WireGuard・OpenVPN・IPsecの比較

3方式の特徴

観点	WireGuard	OpenVPN	IPsec（IKEv2）
動作層・プロトコル	L3、UDPのみ（既定51820）	L2/L3、UDPまたはTCP（既定1194）	L3、UDP 500/4500＋ESP
認証方式	公開鍵ペア（SSHに近い）	X.509証明書（＋ユーザー名/パスワード）	事前共有鍵または証明書
実装場所	Linuxカーネル組み込み（5.6以降）	ユーザー空間デーモン	カーネル＋IKEデーモン（strongSwan等）
設定の複雑さ	低い（数行）	中（CA運用が必要）	高い（パラメータ一致が必須）
性能	高い	中	高い（ハードウェア支援あり）
得意な用途	サーバー間、小規模チームのリモートアクセス	証明書で厳密に管理したいリモートアクセス、TCPしか通らない環境	拠点間、クラウドのSite-to-Site、ルーター製品との接続

それぞれの設計思想

WireGuardは暗号方式を固定（Curve25519・ChaCha20-Poly1305など）して交渉を省き、コードを極端に小さく保つ設計です。設定は「自分の秘密鍵」「相手の公開鍵」「相手に許可するIP範囲」だけで、SSHの鍵交換に慣れていれば違和感なく扱えます。OpenVPNはTLSの上にVPNを構築するもので、証明書による厳密なクライアント管理や、UDPが遮断される環境でのTCP 443番ポート運用が可能です。IPsecはIPそのものを拡張する標準規格で、ルーターやファイアウォール製品、各クラウドのSite-to-Site VPNが対応しているため、機器同士をつなぐ場面では事実上の共通言語になっています。

WireGuardの最小構成手順

2台のサーバーをつなぐ

ここでは、クラウド上のサーバーA（グローバルIP：203.0.113.10）と、社内のサーバーB（NAT配下）をつなぎ、VPN内では10.8.0.1と10.8.0.2で通信できるようにします。事前にファイアウォールでサーバーAのUDP 51820番を開けておいてください。

1. 両サーバーにWireGuardをインストールし、鍵ペアを生成します。

   sudo apt install wireguard
   umask 077
   wg genkey | tee privatekey | wg pubkey > publickey
   cat publickey   # 相手に渡すのは公開鍵だけ

2. サーバーA（待ち受け側）に/etc/wireguard/wg0.confを作成します。

   [Interface]
   Address = 10.8.0.1/24
   ListenPort = 51820
   PrivateKey = <サーバーAの秘密鍵>
   
   [Peer]
   PublicKey = <サーバーBの公開鍵>
   AllowedIPs = 10.8.0.2/32

3. サーバーB（NAT配下）にも同様に作成します。NAT配下からは接続先を指定し、NATテーブルが消えないようPersistentKeepaliveを設定するのがポイントです。

   [Interface]
   Address = 10.8.0.2/24
   PrivateKey = <サーバーBの秘密鍵>
   
   [Peer]
   PublicKey = <サーバーAの公開鍵>
   Endpoint = 203.0.113.10:51820
   AllowedIPs = 10.8.0.0/24
   PersistentKeepalive = 25

4. 両方で起動し、疎通を確認します。

   sudo wg-quick up wg0
   sudo systemctl enable wg-quick@wg0   # 再起動後も有効化
   sudo wg show                          # latest handshake が出れば成功
   ping 10.8.0.1                         # サーバーBから

AllowedIPsの意味を正しく理解する

WireGuardで最も誤解されやすいのがAllowedIPsです。これは「このピアから来るパケットとして受け入れる送信元」であると同時に、「この宛先へのパケットはこのピアに送る」というルーティング表でもあります。サーバーB側でAllowedIPs = 0.0.0.0/0とすると全通信がVPNを通る「フルトンネル」になり、インターネットへ出られなくなることがあります。まずは必要な範囲だけを書き、拠点間で社内LAN全体をつなぎたい場合はAllowedIPsにそのLANのCIDRを追加し、中継するサーバー側でnet.ipv4.ip_forward=1を有効にします。NATの仕組みそのものはNATとポートフォワーディングの解説を参照してください。

クラウドのSite-to-Site VPNとの関係

クラウド側が用意している仕組み

AWSの「Site-to-Site VPN」やGCPの「Cloud VPN」、Azureの「VPN Gateway」は、いずれもクラウド側にIPsecの終端装置をマネージドで用意してくれるサービスです。オフィス側のルーターやファイアウォールとIPsecで接続し、VPCとオフィスLANのあいだで経路を交換します。手順としては、クラウド側で仮想ゲートウェイを作成し、オフィス側の機器情報（グローバルIP）を登録し、生成された事前共有鍵とパラメータ（IKEバージョン、暗号スイート、DH group）をオフィス側機器に設定する流れです。VPCのサブネットやルートテーブルの設計はAWS VPCのネットワーク設計入門で扱っています。

一方、自前のWireGuardやOpenVPNをクラウド上のインスタンスで動かす構成も一般的です。マネージドVPNは接続時間に応じた料金がかかり、対向機器がIPsec対応である必要があります。少人数のリモートアクセスや、サーバー同士を手軽につなぐだけであれば、小さなインスタンスにWireGuardを載せるほうが安価で柔軟です。

トラブル事例：ハンドシェイクは成功するのに通信できない

症状：WireGuardのwg showでlatest handshakeは更新されるのに、VPN越しのpingが通らない。

原因：サーバーAでAllowedIPsを10.8.0.2/32としていたが、サーバーB側のLAN（192.168.1.0/24）から来る通信を通したかったため、その範囲が許可されておらずパケットが破棄されていた。WireGuardはAllowedIPsに合致しない送信元のパケットを黙って捨てるため、ログにもエラーが出ません。

対処：サーバーA側のAllowedIPsに192.168.1.0/24を追加し、サーバーBでip_forwardを有効化。さらにサーバーBのファイアウォールでwg0とLANインターフェース間のFORWARDを許可して解消しました。「ハンドシェイクOK＝設定OK」ではなく、経路の許可は別で確認する必要があります。

VPNで解決しないこととゼロトラストとの棲み分け

VPNは「境界」を延長するだけ

VPNは社内ネットワークという境界を遠隔地まで延長する技術です。裏を返せば、VPNにつながったPCがマルウェアに感染していれば、社内ネットワークに直接つながったのと同じリスクを持ち込みます。VPNの認証は「ネットワークに入る権利」であって、「どのサーバーのどの操作を許すか」の制御ではありません。また、VPN終端装置そのものがインターネットに露出しているため、その脆弱性が悪用される事例も継続的に報告されています。

ゼロトラストとの使い分け

ゼロトラストの考え方では、ネットワークの内側にいることを信頼せず、アクセスのたびにユーザーと端末を検証してアプリ単位で許可します。Cloudflare AccessやAWS Session Manager、Tailscaleのような製品はこの方向で、「SSHやWeb管理画面を公開せずに、認証された人だけをつなぐ」ことをVPNより細かい粒度で実現します。実務では、サーバー間の恒常的な接続や拠点間はVPN、人が管理作業のために入る経路はゼロトラスト型のアクセス制御、という組み合わせが現実的です。SSHの鍵管理を整えたうえでSSH接続をVPN内に閉じるだけでも、公開ポートを減らす効果は十分にあります。

まとめ

VPNは「パケットを包んで暗号化し、相手を認証して運ぶ」技術で、WireGuardはシンプルさと性能、OpenVPNは証明書運用とTCP対応、IPsecは機器・クラウドとの相互接続に強みがあります。サーバー間や小規模チームならWireGuardの数行の設定から始め、オフィスのルーターやクラウドVPCを恒常的につなぐならIPsecベースのSite-to-Site VPNを選ぶのが基本線です。そのうえで、VPNは境界を延長するだけであり、人の管理アクセスにはゼロトラスト型の制御を組み合わせる、という前提を忘れないでください。まずは検証用の2台でWireGuardをつなぎ、AllowedIPsの挙動を体感するところから始めるのがおすすめです。

拠点間接続の設計やクラウド移行に伴うネットワーク構成でお困りの際は、Harmonic Societyのシステム開発・インフラ支援にご相談ください。