両端が同じサブネット: リモート LAN を空き範囲にマッピングする
クライアント側のアドレス マッピングは、重複するリモート LAN を空き範囲の下に提示できるが、適用できるクライアントは一部だけで、戻り経路はどのみち必要になる。
自宅とオフィスがどちらも 192.168.1.0/24 を使っていると、192.168.1.1 への要求には答えが二つあり、クライアントは尋ねずに一方を選ぶ。稼働中のオフィス網を採番し直すのはめったに歓迎されず、ルーターのアドレスはプリンターやカメラ、文書に埋め込まれていることが多い。クライアント側のアドレス マッピングなら、リモート網を空き範囲の下に提示でき、ホスト部をそのままにできるので 192.168.1.20 が 10.203.41.20 として見える。落とし穴は、実装しているクライアントが一部だけで、戻り経路には何の効果もないことだ。
同じホストの二つの見え方
マッピングはホスト部を保ち、ネットワーク部だけを変える。すると同じマシンが、どこに立つかによって二つのアドレスで応答する。何かを設定する前に両方の列を書き出しておけば、後でログやファイアウォール規則を読み違えずに済む。
| The application dials | The remote device is |
|---|---|
| 10.203.41.1 | 192.168.1.1 |
| 10.203.41.20 | 192.168.1.20 |
自宅のローカル機器は自分たちの 192.168.1.x アドレスを保ち、それがこの演習の狙いだ。隣の部屋のプリンターは到達可能なままで、オフィスは衝突しない範囲の下に見える。
引数の順序がこの仕掛けのすべて
このオプションは方向、ネットワークとマスク、そして別名を取り、最初のネットワークがクライアントの見るもの、別名がサーバーの見るものだ。リモート ゲートウェイの背後にある資源では、方向は宛先の形になる。最後の引数が別名だからといって二つのネットワークを入れ替えるのが、接続はするが何もマッピングしないトンネルを生む誤りだ。
push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"ルートが、新しい範囲宛てのクライアントのパケットをトンネルへ送り、変換は通過するときに宛先を書き換える。192.168.1.20 からの応答は 10.203.41.20 に書き戻されるので、クライアントのソケットは一貫したままになる。単一ホストでも全長マスクで同じように動くが、ルートとマッピングが同じアドレスを指している必要がある。
これはアドレスのマッピングであり、ポートのマッピングではない。一つのホスト上の二つのサービスをこれで分けることはできず、IP アドレスをペイロードに埋め込むプロトコルは今も本当のアドレスを見る。
マッピングは戻り経路を作らない
変換はクライアントで起きるので、サーバーは今も応答をトンネルへルーティングする必要があり、そのファイアウォールも今も通す必要がある。リモート ゲートウェイがトンネルのサブネットへの到達方法を知らなければ、要求は届いて応答は間違った扉から出ていき、マッピングはただ失敗をクライアントの問題に見せるだけだ。
サーバー側の規則は、変換後にサーバー上に存在するアドレスを記述すべきで、クライアントから見える範囲ではない。別名を許可規則に写しても、その側のパケットはどれも別名を運ばないので午後が無駄になる。
クライアントがルーティングする他の何とも衝突しない別名の範囲、たとえば別の VPN、コンテナ網、二つ目のオフィスを選ぶ。ここで衝突すると元の曖昧さが別の番号の下で再び現れ、アドレスが見慣れないため気づきにくい。
名前とペイロードは変換を生き延びる
本当の 192.168.1.20 に解決されるホスト名は、ルーティング テーブルが何と言おうと、ブラウザーをリモートではなくローカル機器へ送る。プライベート DNS の応答はクライアントから見える範囲を指す必要があり、TLS 証明書は今もアプリケーションの期待する名前を持つ。アドレスは動いても名前が静かに誤った方向へ解決されることがあるので、アドレスではなく名前で試すべきだ。リモート ゲートウェイがそのゾーンも提供しているなら、その自身のレコードにもクライアントから見える範囲が要る。
リダイレクト、埋め込まれた URL、ペイロードに自分のアドレスを渡すアプリケーションは、パケットのマッピングでは直せない形で壊れうる。それらはアプリケーションの問題として扱い、採番し直しが不要だと約束する前に、労力をそれに見合って見積もる。
コミットする前の三つの確認
第一に、クライアントの実装を確かめる。Community OpenVPN はこのオプションに対応しているが、OpenVPN 3 のコードベースは未対応機能の一つに挙げているので、Connect 風のクライアントに配ったプロファイルは単に無視するかもしれない。受け入れられて一度も適用されない指示は、トンネルが健全に見えるだけに、エラーより悪い。
第二に、詳細度を上げた短い診断の窓でルートと変換を別々に確かめ、そのうえで ping ではなく実際のサービスを試す。第三に、ローカル ルーターとリモートの資源がクライアントから見分けられるままか、それが元の目的だったのだから確かめる。
クライアントが変換できないなら、ゲートウェイ側に助けを求めるか、採番し直しを受け入れる。同じアドレスにルートを足し続けるのは設計ではない。