OpenVPNとFRR(OSPF)を組み合わせた多拠点VPNルーティングの限界と学び

背景 複数拠点(A, B, Cなど)を OpenVPN 経由で接続し、 **2系統のVPNトンネル(10.8.0.0/24 と 10.10.0.0/24)**を経由して経路冗長化したい。(openvpnサーバは独立した2マシン) そんなニーズから検証を始めました。 各拠点はそれぞれローカルLAN(例: 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24)を持ち、 それらを OSPF (FRRouting) で自動経路学習させて、 VPNトンネル越しに相互通信できるようにしたい、という構成です。 やりたかったこと OpenVPNで各拠点を接続(多拠点site-to-site VPN) FRR (OSPF) を使って動的ルーティング トンネルごとにコストを設定して経路選択 できれば route-nopull で手動ルーティングを制御 目標は「OpenVPNトンネルを2本走らせて、FRRで経路選択を任せる」ことでした。 OpenVPNの仕組みを理解してぶつかった壁 結論から言うと、 OpenVPNではOSレベルのルーティングテーブルがVPN内部で使われない という根本的な構造問題にぶつかります。 OpenVPNのルーティングの構造 OpenVPNはユーザランドで動作し、/dev/net/tun デバイスを通じて通信します。 Linuxカーネルはtunデバイスにパケットを出す そこから先は**OpenVPNプロセス(ユーザランド)**が受け取り、独自の内部ルーティングテーブルで転送を行う つまり、Linuxのルーティングテーブル(ip route)とは別世界で動いています。 push と route-nopull の関係 OpenVPNサーバはクライアントに対して push “route …” を送ることで、 クライアントのOSにもユーザランドにもルート情報を注入します。 一方、クライアント設定で route-nopull を有効にすると、 その push 情報をすべて拒否します。 これがまずひとつの落とし穴です。 FRR(OSPF)を組み合わせても解決しない理由 FRRでOSPFを走らせると、 VPNトンネル越しに相手拠点のLAN情報(例: 192.168.x.x/24)が学習されます。 これにより、OSレベルのルーティングテーブルは更新されます。 しかし! OpenVPNはそのOSルートを全く参照しません。 OpenVPNプロセスは独自に「このLANはどのクライアントの背後にあるか」を iroute で知っていなければ、パケットをどこに転送すべきか判断できません。 OpenVPNの根本的な設計思想 これはOpenVPNが「1:多アクセスVPN」を想定して作られたから。 ...

October 9, 2025 · 3 min · 441 words · Me