Пройдите четыре проверки: на какой адрес разрешается имя, какой префикс использует локальная сеть, какой маршрут ядро выбирает для этого назначения и что отвечает на дальнем конце. Вход в 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 называет неверный хост, остановитесь и определите назначение, прежде чем продолжать. Получение ответа с этого адреса не устанавливает, какая машина его отправила. Проверка субъекта сертификата — один из немногих надёжных сигналов, доступных в этот момент.

Не заменяйте частные адреса офиса произвольными публичными, которые вы не контролируете. Это меняет перекрытие на проблему маршрутизации и владения, которая хуже и труднее объясняется.

Запишите локальный префикс, удалённый префикс и изменение, которое это решило. Следующее перекрытие будет выглядеть иначе, но пойдёт по той же схеме.

Похожие статьи