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 構成を、設定例そのものよりも 何を分けて確認するべきか という観点で確認します。
まず結論
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 では、トンネルが up していても相手拠点 LAN へ到達できるとは限りません。route がない場合は相手 LAN に向かいませんし、戻り route がない場合は片方向だけ通信できるように見えます。
Firewall は通信を許可する責務であり、route は通信をどこへ送るかを決める責務です。OpenVPN の外側 UDP を許可することと、トンネル内の拠点間通信を許可することも分けて考えます。
| 問題 | 確認すること |
|---|---|
| VPN は up だが相手 LAN に届かない | 相手 LAN 宛て route と戻り route |
| 外側 UDP が届かない | WAN 側 Firewall、NAT、ISP 側制限 |
| トンネル内 ping は通るが LAN 宛てが通らない | LAN 側 Firewall、site route、NAT 除外 |
| 小さい通信は通るが大きい通信が止まる | MTU / MSS / PMTUD |
MTU 問題は接続後に見える
OpenVPN の MTU 問題は、接続確立時には見えないことがあります。TLS handshake は通る、トンネル IP への ping も通る、それでも HTTPS やファイル転送だけ止まるという形で現れます。
PPPoE、IPsec、OpenVPN、別 tunnel などが重なると、経路上で実際に通せるサイズは小さくなります。PMTUD が正しく動けば調整不要な場合もありますが、ICMP が途中で落ちる経路では TCP だけが詰まりやすくなります。
| 症状 | 疑うこと |
|---|---|
| ping は通るが Web が重い | TCP MSS が大きすぎる |
| 大きいファイル転送で止まる | Path MTU と fragmentation |
| VPN は up だが一部通信だけ失敗 | route / Firewall / MSS の切り分け不足 |
| DF ping が通らない | 経路上の実効 MTU が想定より小さい |
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 ネットワーク設定ガイド
VyOS 系の記事を用途別にたどれるハブページです。 - VyOS TCP MSS 調整 – PPPoE / VPN 経路で考える
VPN 経路で問題になりやすい TCP MSS 調整を確認しています。 - VyOS PPPoE 利用時の MTU と MSS
PPPoE 環境での MTU / MSS の基本を確認しています。
次に進む
- VyOS Azure 版 OpenVPN – Marketplace イメージで VPN を構成する
クラウド上の VyOS と OpenVPN 構成へ進みます。 - VyOS VPP は本番ルーターにそのまま入れられるのか – dataplane の責務分界で考える
VPN から一段進んで dataplane の責務分界を考えます。
参考書籍
書籍
ルーティング、NAT、VPN、ネットワーク設計の基礎を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連記事
VyOS MSS / MTU 設定 – PPPoE 経路で通信が詰まる時の確認
VyOS TCP MSS clamp 設定 – PPPoE / VPN 経路で詰まりを防ぐ
VyOS PPPoE インターネット接続設定 – Firewall / NAPT / MTU を確認する
VyOS Azure 版 OpenVPN – Marketplace イメージでリモートアクセス VPN を構成する
VyOS OpenVPN の WARNING – 証明書・TLS・replay ログの切り分け
VyOS PKI / OpenVPN 証明書設計 – CA と証明書の責務を分ける
VyOS VPP の適用条件 – 本番ルーターで dataplane を分けて考える
VyOS ネットワーク設定ガイド