LANルーターとVPNクライアント：2台の機器、2つの経路テーブル

二台の機器がパケットを転送し、それぞれが自分のテーブルを持っています。LANルーターはリモートプレフィックスがVPNクライアントのものだと知っており、VPNクライアントは自分のトンネルを通ってそのプレフィックスに到達する方法を知っています。最初のテーブルだけを設定すると、パケットは一致する経路を持たないマシンに届き、デフォルト経路で再び出ていきます。これが障害のすべてで、LAN側からはルーティングループに見えます。実際ほとんどそうだからです。

経路に触れる前に二つのホップを描く

例として次の構成を考えます。LANホストが192.168.50.0/24、通常のルーターが192.168.50.1、専用クライアントが192.168.50.15、そしてリモートLANが10.60.0.0/24にあり、そのクライアントが持つトンネル経由でのみ到達できます。 二つのプライベート範囲は互いに重なっていません。トンネルには独自のアドレス計画があります。

両方のプライベート範囲が重要です。どちらの機器が応答できるかを決めるからです。リモート側には、パケットがクライアントのトンネルアドレスから届くように見え、その応答は192.168.50.0/24へ戻る道を見つけなければなりません。外向きの方向だけを設定すると、要求は機能しても応答が消えます。

ステップ1：ルーターをトンネルではなくクライアントに向ける

LANルーターで、ネクストホップがクライアントのLANアドレスである宛先経路を追加します。

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

そのレコードは「トンネルを作れるマシンに届けよ」と言っているだけです。トンネルがどう構築されるかについては何も語らず、クライアント自身の経路の代わりにもなりません。管理ルーターでは同等のものが機器の静的経路ページにあり、LinuxルーターではLANを所有するインターフェースの設定に属します。閉じてしまうシェルに書くものではありません。

二番目のコマンドの答えを確認します。クライアントをgateway、LANインターフェースをdeviceとして報告していれば、最初のホップは正しく、残りの作業はもう一方のマシンにあります。

ステップ2：クライアントにトンネル側の自分の経路を与える

クライアントは10.60.0.0/24宛てのパケットを受け取り、自分のテーブルを参照します。トンネル設定がそのプレフィックスの経路をインストールしていれば、パケットは暗号化されたまま進みます。していなければ、パケットは通常のデフォルトに一致して192.168.50.1へ戻り、そこが再びクライアントへ送ります。

何かを追加する前に確認します。

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

どのテーブルにもプレフィックス経路がないことが、探している発見です。トンネル自身の設定を通して追加し、次の再接続で再インストールされるようにします。手動のip route addはセッションとともに消え、最も都合の悪いときに障害が戻ります。ネクストホップはトンネルインターフェース、またはVPNがピアとして割り当てるアドレスで、クライアントによって異なります。ピアアドレスは古いメモではなく現在のプロファイルから取るべきです。

ループは、起きるとしても実際には無限ではありません。通過のたびにTTLが減り、パケットは時間超過のメッセージとともに死にます。だから繰り返しのtracerouteは循環を示唆できますが、単に転送していないクライアントは同じパケットを静かに落とします。

ステップ3：転送を許可し、戻り経路を選ぶ

受信と転送は別の権限です。クライアントのnet.ipv4.ip_forward=1はカーネルレベルで通過を許可しますが、ファイアウォール規則がLANインターフェースとトンネルの間でそれを許可する必要は依然としてあります。クライアント自身の管理ページへのアクセスを許可する規則は、リモートLANへの通過を許可しません。同じホストがローカルでpingに応答していると、この区別を見落としやすくなります。

リモート側には鏡像の問題があります。192.168.50.0/24がこの認証済みクライアントを通じて到達可能だと知っている必要があります。 OpenVPN では、通常これはサーバー設定がプッシュするクライアントごとの経路、またはサーバー上のクライアント固有ファイルでクライアント背後のLANを宣言するものを意味します。それがなければ、リモートLANは応答を落とすか、自身のデフォルトゲートウェイ（つまりインターネット）へ送ります。

LANプレフィックスを広告できない場合の代替が送信元変換です。クライアントでの範囲を絞ったmasquerade規則が送信元をトンネルアドレスに書き換え、応答は自然に戻ります。どのLANホストが要求したかも隠れ、それ自体ではリモート側が内側への接続を開始できるようにはなりません。全面的なmasqueradeを追加して後で副作用に気づくのではなく、このトレードオフを意図的に選んでください。

ステップ4：両方の決定を永続化し、実際の経路をテストする

各経路には所有者があり、所有者とは起動時や再接続時に再生成される設定です。ルーターでは静的経路のエントリかもしれません。クライアントではVPNプロファイル、NetworkManager、systemd-networkdかもしれません。トンネルを再接続してクライアントを再起動して確認し、編集を信じるのではなくテーブルをもう一度読みます。

トンネルの外側の接続を運ぶデフォルト経路はそのままにします。設定を「単純化」するために置き換えると、内側のトラフィックが使う前に暗号化された経路が壊れ、症状は変更後に二度と確立しないトンネルです。

通常のLANホストからテストし、クライアントからは行いません。クライアントで発生した要求はルーターの最初のホップを決して通らないからです。リモートLANにしか存在しないサービスを取得して応答本文を確認し、クライアントのカウンターやログを見て通過を確認します。プライベートなホップを示す内部tracerouteは転送を証明しますが、暗号化は証明しません。外側の経路は別の観測であり、トンネル自身のインターフェースカウンターだけがそこから出たものを示します。