商用のインターネット出口 VPN はあなたのアドレスを隠しますが、あなたを自分の家につなぎはしません。家庭内ネットワークの NAS やプリンターに到達するには、そのネットワーク上にあるゲートウェイと、そこへトンネルを張るクライアントが必要です。その後パケットは五つの検査を通らなければならず、どれか一つが失敗しても外からは同じに見えます。

関門 1:クライアントがトンネルを選ぶ

クライアントで宛先プレフィックスが実際にトンネルへルーティングされているか確認します。VPN 自身のサブネットだけを push するスプリットトンネルのプロファイルでは、192.168.x.x がローカルインターフェースからそのまま出てしまい、どこにも届きません。プロファイル名ではなく、クライアントのルーティングテーブルを見てください。

これはスマートフォンのクライアントで最も多い失敗で、既定では DNS だけ、あるいは一つのプレフィックスだけを送ることがよくあります。経路が欠けていると、ハンドシェイクが完璧でも機器には届きません。

先に進む前に、クライアントのプールアドレスと自宅のサブネットが重複していないことを確認してください。

関門 2:ゲートウェイが転送する

VPN は、復号したパケットを LAN へ転送しなければならないホストで終端します。そのためには IP 転送が有効で、VPN インターフェースから LAN インターフェースへの流れを許可するファイアウォールポリシーが必要です。ルーター機器では通常組み込みですが、strongSwan や WireGuard を動かす Linux マシンでは、忘れられがちな二つの設定です。サービスを試す前に両方を確認してください。どちらか一方だけでも同じタイムアウトになります。

LAN インターフェースでのキャプチャで試してください。そこに一度も現れないパケットは、破棄されたか一度も転送されていません。

これは接続を拒否するサービスとは別の失敗で、この区別は多くの時間を節約します。許可は狭く保ち、サブネット全体ではなくサービスと VPN プールに限定してください。

関門 3:戻り経路がすべてを決める

ターゲットは自分が見た送信元アドレスへ応答します。それは翻訳するかどうかによって、クライアントのプールアドレスかゲートウェイのどちらかです。ターゲットの既定ゲートウェイが自宅ルーターで、そのルーターに VPN プールへの経路がない場合、応答はインターネットへ出て死にます。これが典型的な片方向接続です。

正しい修正は二つあります。LAN ゲートウェイにプールへの経路を追加するか、VPN ゲートウェイで source-NAT を行い、ターゲットが常にゲートウェイのアドレスだけを見るようにします。後者のほうが簡単ですが、元の送信元の身元を失います。

どちらかを意図的に選び、どちらにしたかを書き留めてください。ファイアウォールの規則とログがそれに依存します。strongSwan の転送ガイドが、その判断の Linux 側を説明しています。

関門 4:名前とプレフィックスの重複

ローカルの検出名はルーティング境界を越えないため、家の中で親しみやすい名前で見える機器が、トンネル越しには見えないことがあります。プライベートゾーン用の DNS を用意するか、アドレスを文書化してください。どの名前を使うにしても、遠隔クライアントがルーティングできる何かに解決する必要があります。だからこそ、同じ機器がアドレスでは到達でき、名前では見えないということが起こります。

プレフィックスの重複も罠です。クライアントのプールが 192.168.1.0/24 で自宅ネットワークも同じなら、クライアントは宛先をローカルとみなし、トンネルを通して送りません。

どちらか一方の番号を振り直すか、自宅では決して出会わない範囲のプールを使ってください。

関門 5:家の外から試す

台所からのテストでは何も証明できません。通信が LAN を出ないことがあるからです。モバイルホットスポットや別のネットワークから接続し、関門を順にたどってください。クライアントの経路、LAN インターフェースのキャプチャ、サービスの応答、応答のキャプチャ、名前解決の順です。証拠を生まない最初の関門が、作業すべき場所です。

サービスは応答するのに名前が応答しないなら、トンネルではなく DNS の問題です。

動作する構成を、プール、経路、NAT の選択とともにメモに残してください。次にルーターを交換すると三つともリセットされます。

関連記事