自宅とオフィスがどちらも 192.168.1.x を使う: どうするか

四つの確認を順に行います。名前がどのアドレスに解決されるか、ローカルネットワークがどのプレフィックスを使うか、カーネルがその宛先にどのルートを選ぶか、そして遠端で何が応答するかです。VPN のログインはこの中に入りません。どちらのネットワークが勝ってもログインは完了するからです。順番に確認すれば、重複は四番目ではなく二番目の段階で見えてきます。

ログインの成功はトンネルが上がっていることを示すだけで、特定のアドレスがどこを指すかは何も語りません。

一つのアドレス、二台のマシン

ホストは宛先アドレスを使って、経路テーブルとポリシールールから経路を選びます。192.168.1.20 へのホップが隣の部屋の機器ではなくオフィスのサーバー向けだとは、どこにも書かれていません。両方のネットワークが同じプライベート範囲にあると、最も具体的なルートが勝ち、それ以外は再接続がたまたま入れたエントリ次第になります。アドレス自体にその区別を運ぶものはありません。

ip route get 192.168.1.20

この照会はカーネルが選んだインターフェースと次のホップを示し、これが一覧の二番目の確認です。他のことをする前に、ローカルとリモートのプレフィックスを比較します。ローカル LAN が 192.168.1.0/24 で、リモート拠点も 192.168.1.0/24 なら、重複がその発見であり、クライアントのどのオプションでも直せません。

自分が管理する側を採番し直す

個人のルーターは通常、動かしやすい側です。実際に使っているリモートネットワークと衝突しない範囲を選び、10.x.x.x も自動的に空いているわけではないことに注意します。多くの拠点が使っているからです。変更を計画します。DHCP リース、予約アドレス、印刷キュー、固定アドレスのあるものはすべて対応が必要です。VPN なしでルーターを復旧できる時間帯に採番し直します。

リモートのプレフィックス一覧は後ではなく先に確認します。別のオフィス拠点と衝突する新しい範囲を選ぶと、より多くの手間で同じ問題が生じます。

どちらの側も変更できない場合

どちらのネットワークも採番し直せないなら、残る選択肢はサーバー側にあります。ゲートウェイはポリシーベースの NAT や双方向の方式を使って、VPN クライアント向けにリモートネットワークを別のサブネットに変換でき、クライアントには一意のアドレスが見えます。それはゲートウェイの設計であり、すべてのデスクトップクライアントが提供するスイッチではありません。ユーザーが入力するアドレスと、一致させる必要のある名前が変わります。フォーラムからコピーしたルートでは、二つの同一の宛先を区別できません。

プライベートアドレス範囲はプライベートのままです。問題は再利用であり、範囲そのものではありません。

どのマシンが応答したかを証明する

openssl s_client -connect 192.168.1.20:443 -servername office.example 2>/dev/null | openssl x509 -noout -subject

変更後は、オフィスのリソースとローカル機器を一緒にテストします。見慣れた自宅の機器がオフィスのサーバーのあるべき場所で応答する場合、または TLS 証明書が誤ったホストを示す場合は、止まって先に進む前に宛先を特定します。そのアドレスから応答が返っても、どのマシンが送ったかは証明されません。証明書のサブジェクトを確認することは、その時点で使える数少ない確実な手がかりの一つです。

オフィスのプライベートアドレスを、管理していない任意のパブリックアドレスに置き換えないでください。重複を、より悪く説明しにくいルーティングと所有権の問題に交換することになります。

ローカルのプレフィックス、リモートのプレフィックス、そして解決した変更を記録します。次の重複は見た目が違っても同じパターンをたどります。