Дім і офіс обидва використовують 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.

Перевірте список віддалених префіксів спершу, а не потім. Вибір нового діапазону, що конфліктує з іншим офісним сайтом, створює ту саму проблему з більшими витратами праці.

Коли жодна сторона не може змінитися

Якщо жодну з мереж не можна перенумерувати, решта варіантів живе на сервері. Шлюз може транслювати віддалену мережу в іншу підмережу для клієнтів VPN, використовуючи NAT на основі політик або двобічний варіант, тож клієнт бачить унікальну адресу. Це проєкт шлюзу, а не комутатор, який надає кожен настільний клієнт, і він змінює те, яку адресу вводять користувачі та які імена мають збігатися. Маршрут, скопійований з форуму, не може розрізнити два однакові призначення.

Приватні діапазони адрес залишаються приватними; проблема в повторному використанні, а не в самих діапазонах.

Доведіть, яка машина відповіла

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

Після будь-якої зміни перевірте офісний ресурс і локальні пристрої разом. Якщо знайомий домашній пристрій відповідає там, де має бути офісний сервер, або сертифікат TLS називає неправильний хост, зупиніться і визначте призначення, перш ніж продовжувати. Отримання відповіді з цієї адреси не встановлює, яка машина її надіслала. Перевірка суб'єкта сертифіката — один із небагатьох надійних сигналів, доступних у той момент.

Не замінюйте приватні адреси офісу довільними публічними, які ви не контролюєте. Це міняє перекриття на проблему маршрутизації та власності, яка гірша і складніша для пояснення.

Запишіть локальний префікс, віддалений префікс і зміну, яка це вирішила. Наступне перекриття виглядатиме інакше, але піде за тією ж схемою.