pfSense OpenVPN: 別のルーターの先にあるネットワークへ到達する

ノートパソコンは VPN 経由で pfSense の LAN に到達しても、さらに二ホップ内側にあるサービスには到達できず、違いは所有者ごとに一つのルーティング判断です。パケットが往復を完了する前に、クライアント、ファイアウォール、そして宛先ネットワークを実際に所有するルーターという三つの機器が合意する必要があります。どれか一つでも欠けると、症状は同じに見えます。

ルールを変更する前に、所有者ごとに制御も故障の仕方も異なるため、この三つの判断を一つのパケットで追跡してください。

一つのパケット、三つのルーティング判断

クライアントは、プッシュされたルート、ローカルルート、あるいはすでにすべてをカバーするデフォルトという、自分が知っていることだけから宛先がトンネルに属するかを判断します。pfSense はパケットを次にどこへ送るかを判断し、別のルーターの先にあるネットワークの場合、それは正しいインターフェース上の到達可能なゲートウェイを経由するスタティックルートを意味します。下流のルーターは、VPN プールへの戻り経路を知っているかを判断し、知らなければ応答は破棄されるか無意味な場所へ送られます。それぞれの判断は他の二つから独立しています。

どれか一つが失敗すれば、ユーザーの報告は同じになります。だからこそ、デバッグの順序は道具よりも重要です。

クライアントには推測ではなくプレフィックスを渡す

IPv4 トンネルネットワークが /30 より大きい pfSense SSL/TLS サーバーでは、IPv4 Local network(s) フィールドが接続時にクライアントへルートを配布します。クライアントが自分で作るのを当てにせず、下流のプレフィックスをそこに追加してください。接続後は、route-nopull を含むプロファイルやルートフィルターがサーバーの送信内容を無視できるため、クライアントの実際のテーブルを読み取ってください。サーバーは完全に正しくても、クライアントが何もインストールしないことがあります。

他のサーバーモードやトポロジーには別の制約があり、クライアントごとや接続ごとのポリシーが特定のクライアントの受信内容を変えることがあります。たまたま最初に試したクライアントではなく、重要なクライアントで検証してください。

pfSense を内部ルーターに向ける

pfSense のスタティックルートには、定義済みで到達可能なゲートウェイが必要で、そのゲートウェイに選ぶインターフェースは実際にそこへ到達するものでなければなりません（Netgate のスタティックルートガイドがそう説明しています）。例示的な構成では、通過リンクはファイアウォール側が 192.168.77.1、内部ルーター側が 192.168.77.2 で、サービスネットワークはその先の 172.16.30.0/25 です。ルートはプレフィックスとネクストホップを指定するもので、サービスのアドレスではありません。リモートネットワークのアドレスをゲートウェイとして使うのは、正しく見えてどこにも転送しないルートを作るよくある方法です。

インターフェースに名前を付けても、その先のネットワークを説明したことにはなりません。スタティックルートがその説明です。

遠い側はプールを知っている必要がある

下流のルーターには、デフォルトルートや動的プロトコルがすでに提供していない限り、プールへの戻りルート（この例では 192.168.77.1 経由の 10.55.0.0/24）が必要です。サービスホスト自身のゲートウェイはそのルーターを指している必要があり、ルーターがデフォルトゲートウェイなら通常はそうですが、ホストを手動で設定した場合はそうとは限りません。ファイアウォールのポリシールーティングも特定のトラフィックでテーブルを上書きできるため、ルートが間違っていると結論づける前に、ルールが別のゲートウェイを選んでいないか確認してください。

この設計に翻訳は不要で、クライアントの送信元アドレスを見えるままにしておけば、下流のネットワークが独自のポリシーを適用できます。

受け入れ確認では、新しいリクエストを一つ、トンネルの入口、ファイアウォールの内部出口、宛先からの応答まで追ってください。代わりに翻訳を意図的に使う場合は、下流のネットワークが見る送信元と、応答がどう戻る想定かを記録してください。

三者の計画を許可されたアプリケーションと一緒に保存し、次の管理者が経路を再発見するのではなく再構築できるようにしてください。