VyOS で OpenVPN site-to-site を構成する場合、単にトンネルが張れれば終わりではありません。拠点間のトンネルアドレス、証明書、暗号方式、ルーティング、Firewall、NAT、MTU、MSS を合わせて考える必要があります。
特に実運用では、OpenVPN の接続自体は確立しているのに、Web やファイル転送などの大きめの通信だけが詰まることがあります。この場合、原因は認証や route ではなく、Path MTU Discovery、MSS、PPPoE、tunnel overhead の組み合わせにあることがあります。
この記事では、VyOS の OpenVPN site-to-site TLS 構成を、設定例そのものよりも 何を分けて確認するべきか という観点で整理します。
書籍
マスタリング TCP/IP ルーティング編
ルーティング、VPN、経路制御、ネットワーク設計の基礎を体系的に確認したい場合の参考書籍です。OpenVPN site-to-site の前提になる L3 設計の確認用として紹介します。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
まず結論
OpenVPN site-to-site は、次の要素を分けて確認すると安定します。
| 観点 | 見ること |
|---|---|
| TLS / 証明書 | CA、certificate、private key、peer の認証、失効時の扱い |
| トンネルアドレス | local-address / remote-address、point-to-point の向き |
| ルーティング | 拠点 LAN 宛て route、戻り経路、経路再配布の有無 |
| Firewall / NAT | OpenVPN の外側 UDP、トンネル内通信、NAT しない範囲 |
| MTU / MSS | PPPoE や tunnel overhead を含めた実効 MTU、TCP MSS clamp |
| 運用確認 | 接続状態、ログ、DF ping、実通信での詰まり |
つまり、OpenVPN は VPN 設定だけでは完結しません。site-to-site の場合は、VPN interface を L3 interface として扱い、route / firewall / MTU まで含めて一つの設計として見る必要があります。
OpenVPN site-to-site の基本構造
VyOS 公式ドキュメントでは、OpenVPN interface に site-to-site、server、client の mode を指定できます。site-to-site は拠点間 VPN を作るための mode です。
site-to-site では、OpenVPN interface が point-to-point の tunnel interface として振る舞います。物理 interface とは別に、vtun interface にトンネル内の local address / remote address を持たせ、そこへ route を向ける構成になります。
| 要素 | 役割 |
|---|---|
| 外側通信 | OpenVPN peer 間の UDP 通信。Internet / WAN / PPPoE 上を通る |
| TLS | peer の認証と暗号化の土台。証明書管理の責務を持つ |
| vtun interface | トンネル内の L3 interface。route / firewall / monitoring の対象になる |
| site route | 相手拠点 LAN への経路。戻り経路も必ず必要 |
| Firewall | 外側 UDP と内側 site-to-site 通信を別々に制御する |
設定例
以下は考え方を示す最小構成の例です。実際には証明書ファイル、peer の address、port、route、firewall policy を自分の環境に合わせます。
configure
set interfaces openvpn vtun1 mode 'site-to-site'
set interfaces openvpn vtun1 protocol 'udp'
set interfaces openvpn vtun1 local-address '192.168.101.1'
set interfaces openvpn vtun1 remote-address '192.168.101.2'
set interfaces openvpn vtun1 local-port '30000'
set interfaces openvpn vtun1 remote-host '<peer-public-address>'
set interfaces openvpn vtun1 remote-port '30000'
set interfaces openvpn vtun1 encryption cipher 'aes256gcm'
set interfaces openvpn vtun1 hash 'sha512'
set interfaces openvpn vtun1 persistent-tunnel
set interfaces openvpn vtun1 openvpn-option 'auth-nocache'
commit
saveここで重要なのは、設定例を丸ごと写すことではありません。vtun1 を作った後に、相手拠点 LAN への route、Firewall の許可、NAT 除外、MTU / MSS の確認まで進めることです。
route と firewall を分けて考える
site-to-site VPN では、トンネルが張れても route がなければ拠点間通信は成立しません。また片方向だけ route がある場合、ping は片方向だけ成功したり、戻り通信が別経路へ流れたりします。
show interfaces openvpn vtun1
show ip route
show ipv6 route
show log openvpn
show firewallFirewall も、外側と内側を分けて考える必要があります。外側では OpenVPN の UDP port を peer から受けられること、内側では vtun1 を通る拠点間通信を policy として許可することが論点になります。
| 場所 | 見ること |
|---|---|
| 外側 interface | OpenVPN の UDP port を peer から受けられるか |
| vtun interface | 拠点間の送受信を firewall policy が許可しているか |
| LAN 側 | 相手拠点宛て通信が VPN route に向くか |
| NAT | 拠点間通信を誤って masquerade していないか |
MTU 問題は接続後に見える
OpenVPN の MTU 問題は、接続確立時には見えないことがあります。OpenVPN manual でも、Path MTU Discovery が壊れている場合の典型症状として、接続は成功するが active usage の途中で stall する、という説明があります。
これは、OpenVPN が UDP/IP の上に暗号化 tunnel を作るためです。物理 interface の MTU が 1500 でも、OpenVPN の外側 IP header、UDP header、OpenVPN header、暗号化 overhead が加わるため、トンネル内で安全に運べる payload は小さくなります。PPPoE を通る場合は、外側の MTU がさらに小さくなりやすくなります。
| 環境 | 起きやすいこと |
|---|---|
| 通常 Ethernet | MTU 1500 前提で動くことが多いが、OpenVPN overhead 分の余白は必要 |
| PPPoE | 外側 MTU が 1492 付近になりやすく、余白が少ない |
| 二重 tunnel | OpenVPN の中に別 tunnel、または別 VPN の上に OpenVPN を通すと詰まりやすい |
| ICMP が落ちる経路 | Path MTU Discovery が効かず、大きい TCP 通信だけ止まりやすい |
MSS は TCP を壊さないための調整点
MTU 問題への対応では、最初から tun-mtu や fragment を大きく触るより、まず TCP MSS を見ます。OpenVPN 2.6 manual でも、mssfix と fragment は Path MTU Discovery が壊れている場合の workaround として説明されています。特に fragment は最後の手段に近い扱いで、まずは PMTUD や MSS の考え方を整理する方が安全です。
TCP MSS clamp は、トンネル内を流れる TCP SYN に対して、相手に大きすぎる segment を送らせないための調整です。UDP や ICMP には効きませんが、Web、SSH、ファイル転送など TCP ベースの通信が途中で止まる問題には効くことがあります。
ping <remote-tunnel-ip> size 1400 do-not-fragment
ping <remote-tunnel-ip> size 1360 do-not-fragment
show interfaces openvpn vtun1
show log openvpnここでの目的は、いきなり値を決め打ちすることではなく、どのサイズまで DF 付きで通るのか、TCP だけが詰まるのか、UDP も詰まるのかを分けることです。
運用時の確認順序
OpenVPN site-to-site が不安定な場合は、次の順序で見ると切り分けやすくなります。
| 順序 | 確認すること |
|---|---|
| 1 | OpenVPN process と vtun interface が up しているか |
| 2 | peer の外側 UDP port へ到達できるか |
| 3 | トンネル内 local / remote address へ ping できるか |
| 4 | 相手拠点 LAN への route と戻り route があるか |
| 5 | Firewall が外側 UDP と内側通信を許可しているか |
| 6 | NAT 除外または NAT 対象が意図通りか |
| 7 | DF ping や実通信で MTU / MSS 問題がないか |
この順序を飛ばすと、route の問題を MTU 問題と勘違いしたり、Firewall の問題を証明書の問題と勘違いしたりします。VPN は複数の層が重なるため、層ごとに切り分けるのが重要です。
まとめ
VyOS の OpenVPN site-to-site TLS 構成は、接続設定だけならそれほど複雑ではありません。しかし、実運用では route、firewall、NAT、MTU、MSS、証明書管理を合わせて見ないと安定しません。
特に MTU / MSS は、接続確立後に初めて問題として現れることがあります。PPPoE や別 tunnel を経由する環境では、OpenVPN の overhead を含めた実効 MTU を意識し、TCP MSS clamp や DF ping による確認を行う方が安全です。
site-to-site OpenVPN は、単なる VPN 機能ではなく、拠点間 L3 interface を追加する設計です。だからこそ、VPN 設定、ルーティング、Firewall、MTU を別々に見て、最後に一つの通信経路として確認する必要があります。
参考資料
関連記事
- VyOS VPP は本番ルーターにそのまま入れられるのか – dataplane の責務分界で考える
- VyOS MSS 設定 – TCP MSS 調整の基本
- VyOS PPPoE 利用時の MTU と MSS
- VyOS NAPT 設定 – IP マスカレードの基本
- VyOS 1.4 IPv6 IPoE インターネット接続設定
- パブリッククラウドで NFV は成立するのか – 仮想アプライアンスを置く前に考えること
- AWS EC2 のネットワーク帯域をどう読むか – baseline / burst / single-flow と NFV 設計
