「拠点間の通信を暗号化したいけど、どのVPNプロトコルを選べばいいんだ?」と悩んでいる情シスの方は多いはずです。
WireGuard・OpenVPN・IPsecと選択肢はありますが、企業ルーター機器との互換性が高く、クラウドVPNのデファクトスタンダードになっているのがIPsecです。
この記事では、IPsecの仕組み・2つのプロトコル(AH/ESP)・動作モード・IKEv2による鍵交換の流れから、LinuxのstrongSwanで実際に拠点間VPNを構築する手順まで、現場で使えるレベルで解説します。
IPsecとは?なぜ今も使われ続けるのか
IPsec(Internet Protocol Security)は、IPパケットを暗号化・認証するプロトコル群の総称です。RFC 4301で標準化されており、OSIモデルの「ネットワーク層(L3)」で動作します。
TLSはHTTPなどアプリケーション層の通信を守りますが、IPsecはIPパケットそのものを保護します。通信するアプリやOSに依存しないため、インフラ全体の通信を一括で暗号化できるのが最大の特徴です。
IPsecが特に使われるシーン
・拠点間VPN(Site-to-Site VPN): 本社と支社のネットワークをインターネット越しに安全に接続する
・リモートアクセスVPN: 社員が自宅のPCから社内ネットワークに接続する(IKEv2/IPsec)
・クラウド接続: AWS・Azure・GCPのVPNゲートウェイはIPsecを標準サポート
・ルーター機器連携: Cisco・Juniper・Fortinetなど主要ベンダーがネイティブ対応
WireGuardは近年注目されていますが、既存の企業向け機器との相互接続性ではIPsecが依然として強みを持ちます。新規環境だけでなく、既存インフラとの接続が必要な場面ではIPsecが現実的な選択肢です。
IPsecの2つのプロトコル:AHとESP
IPsecには2つのセキュリティプロトコルがあります。
AH(Authentication Header)
IPパケットに認証情報(ハッシュ値)を付加し、改ざんを検知します。ただし暗号化は行いません。パケットの中身は平文のまま伝わるため、盗聴には対応できません。現代の実装ではほとんど使われません。
ESP(Encapsulating Security Payload)
AHの機能(改ざん検知)に加えて、ペイロードの暗号化も行います。現在のIPsec実装ではESPが事実上の標準です。ESP単体でも認証機能を持つため、AHとESPを組み合わせる必要はほぼありません。
| プロトコル | 改ざん検知 | 暗号化 | 現在の利用 |
|---|---|---|---|
| AH | あり | なし | ほぼ使われない |
| ESP | あり | あり | 主流(推奨) |
トランスポートモードとトンネルモード
IPsecには2つの動作モードがあり、用途によって使い分けます。
1. トランスポートモード
元のIPヘッダーはそのままに、ペイロード(データ部分)だけをESPで保護します。送信元・宛先IPアドレスは外部からも見えるため、エンドツーエンドで直接通信するホスト間(PCとサーバーなど)での利用に向いています。
ただし内部ネットワーク構成が外部に露出するため、拠点間の通信には向きません。
2. トンネルモード
元のIPパケット全体(ヘッダーを含む)をESPでカプセル化し、新しいIPヘッダーを付加します。外側から見えるのはVPNゲートウェイのIPアドレスだけで、内部ネットワークの構成を隠せます。
拠点間VPN(Site-to-Site VPN)では、ほぼすべてのケースでトンネルモードを使います。
| モード | 保護範囲 | 主な用途 |
|---|---|---|
| トランスポート | ペイロードのみ | ホスト間の直接通信 |
| トンネル | IPパケット全体 | 拠点間VPN・ゲートウェイ間通信 |
鍵交換はIKEv2が主流
暗号化に使う共通鍵は、IKE(Internet Key Exchange)というプロトコルで安全に交換します。
IKEv1とIKEv2の違い
・IKEv1(旧): メインモード・アグレッシブモードが複雑で設定ミスが起きやすく、NAT越えにも弱い。現在は廃止推奨
・IKEv2(現在の主流): RFC 7296で標準化。メッセージ数が少なく接続が速い。EAP認証・MOBIKE(モバイル再接続)に対応。モバイル回線の切り替えにも強い
新規でIPsecを設定するなら、必ずIKEv2を選択してください。IKEv1を選ぶ理由は、旧機器との互換性が必要な場合のみです。
IKEv2の接続確立フロー(概要)
1. IKE_SA_INITフェーズ: Diffie-Hellman鍵交換で安全なチャンネルを確立
2. IKE_AUTHフェーズ: 事前共有鍵または証明書でお互いを認証
3. CHILD_SA作成: 実際のIPsec通信に使うSA(Security Association)を確立
鍵のネゴシエーションにはUDP 500番ポートを使い、NAT越えが必要な場合はUDP 4500番(NAT-Traversal)に自動的に切り替わります。
LinuxでIPsec(strongSwan)を設定する実践手順
Linuxでの定番IPsec実装はstrongSwanです。オープンソースで無料、IKEv2に完全対応しています。ここでは2拠点(拠点A: 192.168.1.0/24、拠点B: 192.168.2.0/24)を接続する例を示します。
1. strongSwanのインストール
Ubuntu/Debianの場合:
# strongSwanをインストール sudo apt update && sudo apt install -y strongswan strongswan-pki # バージョン確認 ipsec version
Rocky Linux / AlmaLinuxの場合:
# EPELリポジトリを有効化してからインストール sudo dnf install -y epel-release sudo dnf install -y strongswan
2. /etc/ipsec.confの設定(拠点Aの例)
# /etc/ipsec.conf(拠点A: WAN IP = 203.0.113.1) config setup charondebug="ike 1, knl 1" # トラブル時のデバッグ用(本番では削除) conn site-to-site authby=secret # 事前共有鍵で認証 left=203.0.113.1 # 拠点AのWAN IP leftsubnet=192.168.1.0/24 # 拠点Aの内部ネットワーク right=203.0.113.2 # 拠点BのWAN IP rightsubnet=192.168.2.0/24 # 拠点Bの内部ネットワーク ike=aes256-sha256-modp2048! # IKEの暗号スイート(!で他を無効化) esp=aes256-sha256! # ESPの暗号スイート keyexchange=ikev2 # IKEv2を使用(必須) ikelifetime=24h lifetime=1h dpdaction=restart # DPD: 接続断を検知したら自動再接続 auto=start # 起動時に自動接続
3. /etc/ipsec.secretsで事前共有鍵を設定
# /etc/ipsec.secrets 203.0.113.1 203.0.113.2 : PSK "your-strong-secret-key-here"
# パーミッションを制限(必ず実施) sudo chmod 600 /etc/ipsec.secrets
4. ファイアウォールとIPフォワーディングの設定
# /etc/sysctl.conf にIPフォワーディングを追記 net.ipv4.ip_forward = 1 # 設定を即時反映 sudo sysctl -p # firewalldでIPsecポートを開放(UDP 500, 4500) sudo firewall-cmd --permanent --add-service=ipsec sudo firewall-cmd --permanent --add-port=4500/udp sudo firewall-cmd --reload
5. 接続の開始と動作確認
# strongSwanを再起動して接続を開始 sudo systemctl restart strongswan # 接続状態を確認(ESTABLISHEDが表示されれば成功) sudo ipsec statusall # 拠点Bの内部ホストへのping疎通確認 ping -c 3 192.168.2.1
ipsec statusallの出力にESTABLISHEDとINSTALLEDが表示されれば、IPsecトンネルが正常に確立されています。
拠点BのLinux側にも同様の設定(leftとrightを入れ替え)を行い、両拠点でauto=startを設定しておけば、サーバー再起動後も自動で接続が復元されます。
中小企業でも今日からできること
フルスクラッチでの設定が難しければ、段階的に取り組みましょう。
・まずクラウドVPNを検討する: AWS Site-to-Site VPNやAzure VPN GatewayはIPsecをサポートし、GUIで設定できます。管理の手間を最小化したい情シスにはこちらが現実的
・ルーター機器のIPsec機能を使う: Yamaha RTXシリーズなどは国内中小企業でよく使われ、IPsecのGUI設定をサポートしています
・strongSwanは無料で本格対応: Linuxサーバーが1台あれば費用ゼロで拠点間VPNを構築できます。まず検証サーバーで動作を確認してから本番に展開するのが安全です
・事前共有鍵から始めて証明書認証に移行する: PSK(事前共有鍵)は手軽ですが、規模が大きくなってきたらstrongSWanのPKI機能を使った証明書認証への移行を目指してください
いきなり証明書認証から始める必要はありません。まず事前共有鍵でトンネルを確立し、運用に慣れてから段階的にセキュリティを高めていく方が実務的です。
よくある誤解と注意点
【誤解1】「IPsecはNATを越えられない」
これは古い情報です。IKEv2にはNAT-Traversal(NAT-T)機能が組み込まれており、UDP 4500番ポートを使うことでNAT環境でもIPsecトンネルを確立できます。現代のIPsec実装ではほぼ問題になりません。
【誤解2】「設定が複雑すぎて情シス1人では無理」
IKEv1はたしかに設定が複雑でした。しかしIKEv2とstrongSwanの組み合わせであれば、本記事で示した20行程度の設定で最小限の拠点間VPNを動かせます。テスト環境で試してから本番適用すれば、1人情シスでも十分対応できます。
【注意】古い暗号スイートは使わない
設定例で見かける 3des や md5 は現在では推奨されません。aes256-sha256 を指定してください。Diffie-Hellmanのグループも modp1024(DHグループ2)は廃止推奨です。modp2048 以上(またはECDHの ecp256 以上)を使用してください。
【注意】ipsec.secretsのパーミッション管理を徹底する
事前共有鍵が記述された /etc/ipsec.secrets は、パーミッションを 600(所有者のみ読み書き可能)に設定することが必須です。これが漏洩すると、第三者に偽のVPNゲートウェイを立てられる可能性があります。
本記事のまとめ
| ポイント | 内容 |
|---|---|
| IPsecの位置づけ | IPパケットをL3で暗号化・認証するプロトコル群。拠点間VPNの業界標準 |
| プロトコル選択 | AH(認証のみ)よりESP(認証+暗号化)が現在の主流。ESP一択で問題ない |
| モード選択 | 拠点間VPNはトンネルモード一択。ホスト間直接通信のみトランスポートモード |
| 鍵交換 | IKEv2が現在の標準。新規設定でIKEv1を選ぶ理由はない |
| Linux実装 | strongSwanが定番。無料でIKEv2フル対応 |
| 暗号スイート | AES-256 + SHA-256 + modp2048以上。3DESやMD5は使わない |
| 中小企業向け | まずクラウドVPNまたはルーター機器のGUI設定から。Linux実装は次のステップ |
IPsecは「難しそう」というイメージが先行しがちですが、IKEv2とstrongSwanの組み合わせであれば、インフラエンジニアが1日で拠点間VPNを構築できるレベルに達しています。まずは設定ファイルの構造を理解し、検証サーバーで動作確認してから本番適用することをお勧めします。
Linuxのファイアウォール設定については、姉妹サイトLinuxMaster.JPでfirewalldやnftablesの詳細を解説しています。合わせてご参照ください。
「ネットワークセキュリティ」の記事を読む
このテーマに関連する解説記事を一覧でまとめています。あわせてご覧ください。
