FRITZ!Box の静的ルート：VPN ゲートウェイの LAN IP を指す

自宅の LAN では FRITZ!Box がデフォルトルーターで、その隣の小さな Linux ボックスが VPN の役割を担っています。ボックスはオフィスのネットワークに到達できますが、FRITZ!Box の後ろにあるノート PC は到達できません。静的ルートはこの問題を三つのフィールドで解決します。本当の難所は、ゲートウェイ欄にトンネルアドレスを入れたくならないことだけです。ゲートウェイとは自分の LAN 内の次のルーターであり、昔からそうでした。

UI を開く前に三つのフィールドを書き出す

LAN 192.168.50.0/24、FRITZ!Box が 192.168.50.1、固定アドレス 192.168.50.2 の VPN ボックスがあり、すでに 10.40.0.0/16 への保護された経路が機能しているとします。ルートはこう言います。そのリモートプレフィックス宛てのパケットは、固定 LAN アドレスの機器に渡します。リモート VPN サーバーの公開エンドポイントも内部トンネルアドレスも、FRITZ!Box がそれらに直接何も送らないため、ここではどちらも無関係です。

その LAN アドレスは DHCP プールの外で予約してください。さもないと、設定したゲートウェイがいつかスマートフォンのものになります。

FRITZ!Box がルートを保持する場所

FRITZ! では、ホームネットワーク、ネットワーク、ネットワーク設定の順に進んだ先で IPv4 ルートの設定を開きます。正確なラベルと階層はモデルと FRITZ!OS のバージョンによって異なります。ルートテーブルが隠れている場合は拡張表示を有効にし、上の値で一件追加して適用します。お使いのモデルのガイドに目を通す価値があります。同じ機能がリリース間で何度も移動しているからです。保存するエントリの正確な文言を控えてください。テーブルのエントリは、どの画面で作られたかをほとんど語らないからです。

これは FRITZ!Box 自身が VPN を終端する機能とは別物です。ルートは別の機器を指しますが、内蔵 VPN はその機器そのものです。

ゲートウェイは到達するだけでなく、ルーティングする必要がある

リモートネットワークに到達できるホストが、自動的に LAN の残りのルーターになるわけではありません。VPN ボックスには IP フォワーディングを有効にし、LAN インターフェースとトンネルの間のフォワーディングを許可するファイアウォールポリシーを用意し、応答を自分のデフォルト経路から出すのではなく LAN に返すルートが必要です。フォワーディングだけ有効にしてファイアウォールルールを忘れるのが最もよくある半端な修正で、クライアント側からはルーティング障害に見えます。

FRITZ!Box 側から VPN ボックスの LAN アドレスに ping し、次にクライアントからリモートアドレスまで traceroute して、二番目のホップがそのボックスであることを確認します。

戻り経路と重複するレンジ

リモート側には 192.168.50.0/24 用の戻りルートがトンネル経由で必要です（VPN ボックスで意図的に送信元を変換している場合を除く）。保持と変換は、ログもアクセスルールも異なる別々のポリシーです、たった今追加した静的ルートはそのどちらを選ぶわけでもありません。レンジが重複する場合はさらに難しく、自宅 LAN とリモートネットワークが同じプレフィックスを共有していると、単一のホストルートでは区別できず、アドレス設計を変える必要があります。

LAN の別の場所でより具体的なルートを追加したり、ノート PC に二つ目の VPN クライアントを入れたりすると、FRITZ!Box のエントリを静かに上書きします。

通常のクライアントから試し、次に障害時を試す

テストは VPN ボックスからではなく、LAN 上の通常の許可されたマシンから実行してください。ボックスはすでに動いていたので何も証明しません。リモートのサービスに到達して応答を確認し、次に無関係なインターネット宛先が依然としてデフォルトルートを使い、トンネルに引きずられていないことを確認します。一つのサブネットに到達するためにデフォルトルートを置き換えるのは、最初の三つのフィールドのエントリよりはるかに大きな変更です。

最後に、VPN を切断してどうなるか見てみましょう。ゲートウェイが保護された経路を失っても静的ルートはテーブルに残るため、トラフィックはインターネットに戻るのではなくボックスで失敗します。フォールバックのトラフィックを遮断する要件は、保存されたルートではなくボックス自身のポリシーに属します。