同じホームサーバーで2つのVPNをルートの競合なしに使えますか？

はい、2つのVPNは、それぞれのアドレス、ルート、デフォルト、ファイアウォールルール、および戻り経路が明確に分離されていれば、1台のホームサーバーで共有できます。

問題は、両方のトンネルが同じプライベートサブネットを主張したり、競合するデフォルトルートを設定したり、重複するインターフェースやテーブル識別子を使ったり、DNSを書き換えたり、リクエストとは異なるトンネル経由で応答を送信したりすると発生します。安全な設計では、まず各VPNにリモートアクセスや商用出口など明確な役割を割り当て、片方のトンネルだけ、もう片方のトンネルだけ、両方同時に動作させて、それぞれのワークロードのアクティブルートを記録しながらテストします。

両方のVPNを開始する前に役割を定義する

VPN AとVPN Bに属するクライアント、宛先、プロトコル、アプリケーションを明確に書き出します。一般的な設計例としては、リモートNASアクセス用のWireGuardサーバー1台と、選択したコンテナ用の商用VPN1台があります。

OpenVPNコミュニティは、複数のトンネルを同時に実行できると述べていますが、各インスタンスには別々の仮想アダプター、ポート、重複しないユニークなサブネットが必要です。

両方のトンネルがサーバーの全トラフィックを運ぶ場合は、どちらがプライマリでどちらがバックアップまたはネストされたものかを決めてください。2つの独立した「すべて送信」ポリシーは、明確な順序付けなしに同じパケットを制御できません。

トンネルとリモートLANのサブネットはユニークに保つ

両方のトンネルのアドレスプール、広告されているリモートLAN、ホームLAN、コンテナネットワーク、一般的なリモートクライアントネットワークを比較してください。同じルーティングコンテキスト内で2つの異なる場所を指す宛先があってはいけません。

OpenVPNのHOWTOでは、重複するプライベートネットワークはルーティングの曖昧さを生み、システムは重複したアドレスがどのサイトを表すか判断できないと説明しています。異なるプレフィックスは重複アドレスの曖昧さをルートメトリックの考慮前に排除します。

可能であれば、どちらかのトンネルまたはLANの番号を変更してください。重複が避けられない場合は、制御されたNAT変換、別のネットワーク名前空間、VRF、ポリシーテーブルを使用し、最後に起動したトンネルに依存しないようにします。

両方のVPNがデフォルトルートを置き換えないようにする

VPNなし、VPN Aのみ、VPN Bのみ、両方アクティブの状態でルートテーブルを確認してください。デフォルトルート、0.0.0.0/1や128.0.0.0/1のような分割デフォルトルート、メトリック、両VPNサーバーへのホストルートを記録します。

OpenVPNのチケットでは、複数のVPNを通じてデフォルトゲートウェイをリダイレクトするのは、管理者が競合するデフォルトルートを決めない限り有用でないと指摘しています。

選択したサブネットのみを扱うトンネルでは、自動的なデフォルトルートのインストールを無効にしてください。2つ目のトンネルを起動しても、その制御接続が最初のトンネルに入らないよう、基盤となるWAN経由で各VPNプロバイダーのエンドポイントへのルートを保持します。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

送信元やアプリケーション別のトラフィックにはポリシールーティングを使う

各VPNを通す必要があるトラフィック用に別々のルーティングテーブルを作成し、送信元サブネット、コンテナアドレス、ファイアウォールマーク、ユーザー、インターフェースで選択します。通常のホームサーバートラフィックはメインテーブルに残します。

Unix/Linuxの複数VPN接続例では、各インターフェースからのトラフィックがそれぞれのルーティングテーブルを使い、正しいモデムやトンネル経由で戻るようルールを推奨しています。

ルールは文書化された順序で追加し、代表的な送信元・宛先ペアでルート検索をテストしてください。接続されたLANや戻りルートがないポリシーテーブルは、選択したアプリケーションをホームネットワークの他から隔離できます。

NAT、ファイアウォール、DNS、戻り経路を整合させる

各VPNについて、どのインターフェースがトラフィックを転送し、どの送信元アドレスがマスカレードされ、どの受信サブネットが許可され、どのDNSリゾルバーがクライアントに提供されるかを文書化します。リモート側に戻りルートがない場合のみNATを適用してください。

Server FaultのWireGuardクライアントをOpenVPN経由でルーティングするケースでは、リモートVPNはOpenVPNクライアントのアドレスしか知らず、リモートWireGuardクライアントのサブネットを知らないため、トラフィックのマスカレードが必要になることがあります。

応答がセッションを受信または発信したトンネル経由で出ることを確認してください。非対称な応答はVPNが接続されているように見えても、TCP、DNS、SMBトラフィックが静かに失敗する原因になります。

本番運用前に障害時と再起動の順序をテストする

VPN Aを起動し、次にBを起動します。順序を逆にし、それぞれのサービスを独立して再起動し、サーバーを再起動します。ルート、ルール、DNS、ファイアウォール状態、既存のリモート管理アクセスが維持されるかを記録してください。

ZimaSpaceのVPNルートが片方消える問題の修復ガイドでは、片方のトンネルがもう片方のトラフィックを誤って奪った場合の復旧手順を紹介しています。

両方のトンネルがどの順序でも再接続でき、各ワークロードが意図した経路を通り、DNSが予測可能で、片方のVPNを無効にしても管理トラフィックが途切れない場合にのみ設定は安全です。両方のサービスを起動時に自動化する前に、ローカルコンソールまたはVPNを使わない復旧経路を確保してください。