LPIC-3 Security303-300 v3.0Weight 4Configure / Operate

334.4 Virtual Private Networks

これまで学んだRouting・Firewall・Certificate/Key・Authenticationを、離れたHost/Network間のTunnelへ統合する。製品名を暗記するのではなく、「何を運ぶか → どうPeerを認証するか → どこへRouteするか」で整理する。

最終到達点：Routed/Bridged VPNを説明し、OpenVPN・IPsec/IKEv2・WireGuardの主要差を判断できる。OpenVPN/strongSwan/WireGuardのServer/ClientまたはPeer設定を読み書きし、接続状態・Route・Firewallを切り分けられる。

Objective判定： このObjectiveの最後に客観Checkpointを配置。学習後は末尾の問題へ。

LPI 334.4：Understand bridged/routed VPNs and major differences of OpenVPN, IPsec, IKEv2, WireGuard / Configure and operate OpenVPN / strongSwan IPsec / WireGuard servers and clients / Awareness of L2TP.

VPNを3層で考える

Application Traffic ↓ 「どのNetworkへ送る?」 → Route / AllowedIPs / Traffic Selector ↓ VPN Interface / IPsec Policy → TUN/TAP / XFRM / wg0 ↓ 「誰とTunnelを作る?」 → Certificate / PSK / Public Key ↓ Internet上のEndpoint → IP + UDP/TCP Port ↓ Encrypted / Authenticated Tunnel

01 Principles02 Compare03 OpenVPN Server04 OpenVPN Client05 IPsec/IKEv206 strongSwan07 WireGuard08 Troubleshoot/L2TP

← 334.2 01 VPN Principles →

334.4 · 01/0801 VPN Principles

🟡 UnderstandRouted / Bridged

VPNの最初の判断は「Remote Access / Site-to-Site」と「L3 / L2」

このページの到達点：Remote AccessとSite-to-Site、Routed VPNとBridged VPNをScenarioから区別できる。

公式要求：Understand the principles of bridged and routed VPNs. Description: remote access and site-to-site VPNs.

Remote AccessUser端末1台などがVPNへ参加し、社内Networkへ到達する。ClientにTunnel Addressを割り当てる構成が典型。

Site-to-Site拠点AのLANと拠点BのLANをGateway同士で接続。利用者端末はVPN Softwareを直接意識しない構成が典型。

Routed = Layer 3 / Bridged = Layer 2

	Routed VPN	Bridged VPN
主に運ぶもの	IP Packet (L3)	Ethernet Frame (L2)
Network設計	別SubnetをRouteで接続	同じL2 Segmentを延伸
Broadcast	通常Router境界を越えない	L2 BroadcastもTunnelを通り得る
OpenVPN例	`dev tun`	`dev tap`

基本はRoutedを先に考える：Subnet境界が明確でBroadcast Domainを広げない。Bridgedは「L2そのものを延伸する必要」がある場合に使う、という判断軸を持つ。

Scenario：東京LAN 10.10.0.0/24と大阪LAN 10.20.0.0/24をGateway間で接続。

→ Site-to-Site + Routed VPNが自然。二つのSubnet間をRouteする。

Scenario：遠隔地の端末を同じEthernet Segmentへ参加させ、L2 Broadcastも通したい。

→ Bridged VPNの要件を疑う。

EXAM DECISION

最初にLayerを決める

別Subnetを接続 → Routed / L3
Ethernet Segmentを延伸 → Bridged / L2
1 User端末 → Remote Access
LAN同士 → Site-to-Site

← Overview Protocol Comparison →

334.4 · 02/0802 Protocol Comparison

🟡 UnderstandOpenVPN / IPsec / IKEv2 / WireGuard

4語を同列の「VPN製品」として覚えない

このページの到達点：OpenVPN、IPsec、IKEv2、WireGuardがTunnelのどの部分を担当するかを説明できる。

公式要求：Understand the principles and major differences of OpenVPN, IPsec, IKEv2 and WireGuard.

OpenVPNUserspace VPN。TLSを使ってPeer認証・Key交換を行い、TUN(L3)/TAP(L2) InterfaceへTrafficを流せる。

IPsecIP LayerでPacketを保護するProtocol Suite。ESP等で実Dataを暗号化・認証する。

IKEv2IPsec Peerの認証、Algorithm/Key交渉、SA作成を担うKey Management Protocol。IKEv2自体がApplication Dataを運ぶTunnel本体ではない。

WireGuardPublic KeyでPeerを識別するL3 Tunnel。InterfaceとAllowedIPsを中心にCryptokey Routingを構成する。

「Control」と「Data」を分ける

OpenVPN TLS control/auth ─────┐ Data channel ──────────┴→ TUN/TAP IPsec IKEv2 → IKE SA / CHILD_SAを交渉 ESP → 実Dataを保護 WireGuard Peer Public Key + AllowedIPs ↓ UDP上のEncrypted L3 Tunnel

判断軸	OpenVPN	IPsec/IKEv2	WireGuard
主なLayer	TUN=L3 / TAP=L2	IP Layer	L3
Peer Identity	TLS Certificate等	Certificate/PSK等をIKEで認証	Public Key
代表管理	`openvpn`	`swanctl`	`wg`/`wg-quick`

試験判断：具体的Cipherを丸暗記するページではない。334.4では「Protocolの役割・主要差」と「指定Toolでの設定/運用」を優先する。

EXAM DECISION

IKEv2をIPsecと同義にしない

IKEv2 → 認証・SA/Key交渉
ESP/IPsec → Data保護
OpenVPN → TUN/TAP + TLS系VPN
WireGuard → Public Key + AllowedIPsのL3 VPN

← Principles OpenVPN Server →

334.4 · 03/0803 OpenVPN Server

🔴 Configure / Operate/etc/openvpn/ / openvpn

OpenVPN Serverは「外側Endpoint」と「内側TUN Network」を分けて読む

このページの到達点：OpenVPN Server configでPort/Protocol、TUN/TAP、PKI、Tunnel Address Pool、Routeを対応付けられる。

公式要求：Configure and operate OpenVPN servers and clients. Partial: /etc/openvpn/, openvpn.

Serverの2つのNetwork

Internet Client ── UDP/1194 ── OpenVPN Server ↓ decrypt tun0 ↓ 10.8.0.1/24 VPN Client Network 10.8.0.0/24 ↓ route Internal LAN 10.20.0.0/24

代表的なRouted Server設定

# /etc/openvpn/server.conf など port 1194 proto udp dev tun ca /etc/openvpn/pki/ca.crt cert /etc/openvpn/pki/server.crt key /etc/openvpn/pki/server.key dh none server 10.8.0.0 255.255.255.0 push "route 10.20.0.0 255.255.255.0" keepalive 10 120 persist-key persist-tun

proto udp

外側Transport。Tunnel内側のLayerとは別。

dev tun

Layer 3のVirtual Interfaceを使う。BridgedならTAP系。

ca/cert/key

TLSで使うCA Certificate、Server Certificate、Server Private Key。

dh none

Finite-field DH parameter Fileを使わず、ECDH等のKey Agreementを使う設定。OpenVPN 2.6系のTLS Server例でも明示できる。

server 10.8.0.0 ...

Clientへ割り当てるVPN内Address Poolを作るHelper。

push "route ..."

Client側へ到達先Routeを配る。

起動前にConfigとNetwork条件を確認

# Foregroundで確認する代表形 sudo openvpn --config /etc/openvpn/server.conf # 起動後にTunnel Interface / Routeを確認 ip addr show tun0 ip route

実運用：VPN Server自身で終端しても、VPN Clientから内部LANへ転送するならIP forwardingとFirewall/FORWARD Rule、Return Routeまで必要。334.3の知識をここで再利用する。

EXAM DECISION

OpenVPN Serverで混ぜない

proto → Internet側Transport
dev tun/tap → Tunnel内側のLayer
server → VPN内Address
push route → Clientの到達先

← Compare OpenVPN Client →

334.4 · 04/0804 OpenVPN Client

🔴 Configure / OperateClient / TUN / Route

OpenVPN Clientは「どこへ接続し、誰を信頼し、何をTunnelへ送るか」

このページの到達点：Client configをServer設定と整合させ、接続後にTunnel InterfaceとRouteを確認できる。

公式要求：Configure and operate OpenVPN servers and clients.

代表Client設定

client dev tun proto udp remote vpn.example.com 1194 ca ca.crt cert client.crt key client.key remote-cert-tls server persist-key persist-tun

Directive	確認ポイント
`remote`	外側のVPN Server hostname/IP + Port。
`dev`/`proto`	Serverと整合しているか。
`ca`	Server Certificateを検証するTrust Anchor。
`cert/key`	Client Certificate認証を使う場合のIdentity。
`remote-cert-tls server`	接続相手CertificateがServer用途として適切か確認する。

接続後は「Connected」よりInterface / Routeを見る

sudo openvpn --config client.conf ip addr show ip route # 例: 内部NetworkへのRouteがtun側へ向くか確認 ip route get 10.20.0.10

接続は成立するが内部LANへ届かない：OpenVPN TLS Session自体ではなく、Client Route / Server forwarding / Firewall / 内部側Return Routeを順に疑う。

Scenario：OpenVPN Logでは接続完了、tun0もある。しかし10.20.0.0/24へ行けない。

→ まずClientに10.20.0.0/24のRouteが入ったか。次にServerのforwarding/FORWARD RuleとReturn Path。

OPERATE

Client確認の順

Endpointへ到達できる?
TLS/Certificate認証は成功?
TUN/TAP Interfaceは作られた?
目的NetworkへのRouteはある?

← OpenVPN Server IPsec / IKEv2 →

334.4 · 05/0805 IPsec / IKEv2

🟡 UnderstandIKE SA / CHILD_SA / ESP

IPsecは「IKEv2で交渉 → ESPでData保護」の2段階で理解する

このページの到達点：IKEv2、IKE SA、CHILD_SA、Traffic Selector、ESPの関係を一続きで説明できる。

公式要求：Understand the principles and major differences of IPsec and IKEv2.

Control → Data

Peer A Peer B │ │ ├──── IKEv2 Authentication ────┤ │ Algorithm/Key negotiation │ ↓ │ IKE SA │ ↓ ├──── CHILD_SA negotiation ────┤ │ Traffic Selector / ESP keys │ ↓ ╰══════ ESP protected Data ════╯

Security Association。Peer間で「どのAlgorithm/Key/条件で通信を保護するか」という状態。

IKE SA

IKEv2のControl Planeを保護し、Peer認証や後続のCHILD_SA交渉に使う。

CHILD_SA

実Trafficを保護するIPsec SA。ESPのKeyやTraffic Selector等を持つ。

ESP

Encapsulating Security Payload。実際のIP Packetの機密性/完全性等を提供するIPsec Protocol。

Traffic Selector

どのSource/Destination Network/TrafficをそのCHILD_SAで保護するか。

Site-to-Siteなら「内側Subnet」をSelectorで結ぶ

Gateway A public: 198.51.100.10 LAN A: 10.10.0.0/24 ⇅ ESP Tunnel Gateway B public: 203.0.113.20 LAN B: 10.20.0.0/24 local_ts = 10.10.0.0/24 remote_ts = 10.20.0.0/24

EXAM DECISION

IPsecで「鍵交渉」と「Data保護」を分ける

Peer認証/Key交渉 → IKEv2
実Data保護 → ESP/IPsec
何をTunnelへ入れる → Traffic Selector

← OpenVPN Client strongSwan →

334.4 · 06/0806 strongSwan

🔴 Configure / Operateswanctl

strongSwanは「Connection → Identity → Child/Traffic Selector」で読む

このページの到達点：swanctl.confのSite-to-Site例を読み、Load→Initiate→SA確認→Terminateの運用ができる。

公式要求：Configure and operate IPsec servers and clients using strongSwan. Partial: /etc/strongswan.conf, /etc/strongswan.d/, /etc/swanctl/swanctl.conf, /etc/swanctl/, swanctl.

Config Directoryの役割

Path	役割
`/etc/strongswan.conf`	strongSwan daemon/plugin等のGlobal設定。
`/etc/strongswan.d/`	Plugin/機能別の分割設定。
`/etc/swanctl/swanctl.conf`	Connection、Authentication、Children、Pool等のswanctl設定。
`/etc/swanctl/x509/`	End-entity Certificateの代表配置先。
`/etc/swanctl/private/`	対応するPrivate Keyの代表配置先。
`/etc/swanctl/x509ca/`	信頼するCA Certificateの代表配置先。
`/etc/swanctl/`	これらCredentialと`swanctl.conf`を含むswanctl側Directory。

Site-to-Siteの最小構造例

connections { site2site { version = 2 local_addrs = 198.51.100.10 remote_addrs = 203.0.113.20 local { auth = pubkey certs = gateway-a.crt id = @gw-a } remote { auth = pubkey id = @gw-b } children { net { local_ts = 10.10.0.0/24 remote_ts = 10.20.0.0/24 start_action = start } } } }

読む順：local/remote_addrs = 外側Peer → local/remote = Identity/Auth → children.net = 実Traffic → local_ts/remote_ts = 内側Network。

反対側Peer：Gateway Bではlocal_addrs/remote_addrsとlocal_ts/remote_tsをA/Bで入れ替え、自分のCertificate/Private Keyを配置する。idはCertificate内のIdentityと整合させる。

Load → Initiate → Monitor

sudo swanctl --load-all sudo swanctl --list-conns sudo swanctl --initiate --child net sudo swanctl --list-sas # 切断 sudo swanctl --terminate --child net

--list-conns設定がloadされたか。

--list-sasIKE/CHILD SAがESTABLISHED/INSTALLEDか。

ip xfrmKernelにIPsec state/policyが入ったか。

ip xfrm state ip xfrm policy ip route

Algorithm値：ProductionではSecurity Policy/Versionに合わせてProposalを明示する場合がある。この教材では具体的Cipher暗記より、Connection/Auth/Child/Selector/SAの構造を優先する。

OPERATE

strongSwanの切り分け

Connection load済み?
IKE SAはEstablished?
CHILD_SAはInstalled?
Traffic Selectorは正しい?
XFRM policy/stateとRoute/Firewallは?

← IPsec/IKEv2 WireGuard →

334.4 · 07/0807 WireGuard

🔴 Configure / Operatewg / wg-quick / ip

WireGuardは「InterfaceのPrivate Key」と「PeerのPublic Key + AllowedIPs」

このページの到達点：WireGuard Key Pairを作り、wg0.confを読み書きし、AllowedIPs・Endpoint・Route・Handshakeを確認できる。

公式要求：Configure and operate WireGuard servers and clients. Partial: /etc/wireguard/, wg, wg-quick, ip.

Cryptokey Routing

wg0 Interface PrivateKey = A_private Address = 10.99.0.1/24 │ └─ Peer B PublicKey = B_public Endpoint = 203.0.113.20:51820 AllowedIPs= 10.99.0.2/32, 10.20.0.0/24 Outbound: Destination ∈ AllowedIPs → このPeerへ暗号化 Inbound: このPeerから来たSource IPがAllowedIPsに整合するか確認

Key Pairを作る

umask 077 wg genkey | tee private.key | wg pubkey > public.key

/etc/wireguard/wg0.conf の代表例

[Interface] Address = 10.99.0.1/24 ListenPort = 51820 PrivateKey = <this-side-private-key> [Peer] PublicKey = <remote-public-key> AllowedIPs = 10.99.0.2/32, 10.20.0.0/24 Endpoint = 203.0.113.20:51820

AllowedIPsは単純なFirewall ACL名ではない：Outboundでは宛先からPeerを選ぶCryptokey Routingに使われ、InboundではPeerから受け入れるSource IP範囲にも関係する。

反対側Peerも対応するKey/Addressで設定

# Client/Peer B の例 [Interface] Address = 10.99.0.2/24 PrivateKey = <peer-b-private-key> [Peer] PublicKey = <peer-a-public-key> AllowedIPs = 10.99.0.0/24, 10.10.0.0/24 Endpoint = 198.51.100.10:51820 PersistentKeepalive = 25

対応関係：A側はBのPublic Key、B側はAのPublic Keyを登録する。NAT配下のBから長時間受信可能にしたい場合などにPersistentKeepaliveを使う。

起動・状態確認

sudo wg-quick up wg0 wg show ip addr show wg0 ip route sudo wg-quick down wg0

wg showで見る：peer / endpoint / allowed ips / latest handshake / transfer。Handshakeが古い・無いならEndpoint/UDP/Keyから確認する。

NAT配下Client：必要に応じてPersistentKeepalive = 25等でNAT mapping維持を助ける。常にServer側へ必須という設定ではない。

EXAM DECISION

WireGuardの3要素

自分 → Private Key
相手 → Public Key
そのPeerへ対応するIP → AllowedIPs
Internet上の送り先 → Endpoint

← strongSwan Troubleshooting / L2TP →

334.4 · 08/0808 Troubleshooting / L2TP

🔴 Operate⚪ L2TP Awareness

VPN Troubleshootingは「Tunnel確立」と「Tunnel内Traffic」を分ける

このページの到達点：OpenVPN/strongSwan/WireGuard共通の切り分け順を使い、L2TPをAwareness深度で識別できる。

共通切り分け

1. Process / Interfaceは存在? 2. Internet側Endpointへ到達? 3. Peer認証 / Key / Certificateは正しい? 4. Tunnel / SA / Handshakeは成立? 5. Tunnel内Address / Traffic Selector / AllowedIPsは正しい? 6. RouteはTunnelへ向く? 7. Firewall / Forwarding / NATは? 8. 相手側Return Pathは? 9. MTU / Fragmentation問題は?

方式ごとの「状態を見る場所」

方式	代表確認	成立の手掛かり
OpenVPN	`openvpn` log / `ip addr` / `ip route`	TUN/TAPが作成され、目的Routeがある
strongSwan	`swanctl --list-sas` / `ip xfrm`	IKE SA + CHILD_SA / XFRM policy
WireGuard	`wg show` / `ip route`	latest handshake / transfer / AllowedIPs

「TunnelはUpなのに通信できない」

OpenVPN：tun0あり、接続Logも正常。

→ Route → Server IP forwarding → FORWARD Rule → Return Route。

strongSwan：IKE SAはEstablishedだがDataが流れない。

→ CHILD_SA/Traffic Selector/XFRM Policy → Firewall/Route。

WireGuard：Handshakeは更新されるが特定Subnetだけ到達不能。

→ AllowedIPsとRoute、相手側AllowedIPs/Return Routeを確認。

L2TPはAwarenessだけ

L2TP = Layer 2 Tunneling Protocol。Layer 2 Tunnelを提供するが、L2TP単体はVPN Dataの機密性・完全性を提供する暗号Protocolではない。そのためL2TP/IPsecのようにIPsecと組み合わせる構成が知られる。

深度：LPI 334.4でL2TPはAwareness。L2TP daemonのConfig/Command演習まで広げない。

OBJECTIVE COMPLETE

334.4完了条件

Routed/BridgedをLayerで区別
OpenVPN/IPsec/IKEv2/WireGuardの主要差を説明
OpenVPN Server/Client configを読める
strongSwanをLoad/Initiate/Monitorできる
WireGuardのKey/Peer/AllowedIPsを設定・確認できる
Tunnel確立後のRoute/Firewall/Return Pathを切り分けられる
L2TPをAwarenessに留める

← WireGuard Objective問題へ →

334.4 VPN · CHECKPOINTObjective末尾

Weight 4客観判定50 → 75 → 100%

334.4 VPN：学習直後にここで解く

本文を読み終えた直後に、そのObjectiveだけを確認する。別ページへ移動して問題を探さない。誤答した問題から該当ノートへ戻り、再度ここへ戻る。

合格条件： 50%は基礎選択式8問中7問以上、75%は選択肢なし再現7問中6問以上。75%到達から72時間後、専用実戦Bankから10問中9問以上で100%。さらに各段階で全小テーマを最低1問正解する必要がある。毎回Question Bankからランダム出題する。

現在の到達度

選択式から開始

問題プール 34問小テーマ 6 実戦Bank 16問直近重複を抑制未出題優先

小テーマ別履歴問題を解くと正答率を表示

全体到達度を見る

Objective Check

JavaScriptが無効：このCheckpointの自動採点と進捗保存はJavaScript実行環境で利用してください。本文はそのまま閲覧できます。

出題方式：初回は小テーマをできるだけ横断し、未出題・出題回数の少ない問題を優先する。再挑戦では小テーマ網羅より直近問題の重複回避を優先し、必要な場合だけ再利用する。

この問題の役割：Objective理解の客観Checkpoint。50%/75%はObjective理解の確認、100%は専用実戦Bankで状況判断・設定/出力読解・近い選択肢まで確認する。

← Objective本文の最後へ全15 Objectiveの到達度へ →

← 334.2 Network IDS

全体進捗·Checkpoint