Ни один маршрут не исправит пул VPN, пересекающийся с вашей LAN

Когда пул туннеля и домашняя LAN делят 192.168.1.0/24, побеждает локальная подсеть. Перенумеруйте сторону, которой вы управляете, или перенаправьте удалённый диапазон.

Приложение утверждает, что туннель здоров, и всё же половина нужных адресатов никогда не отвечает. Первый рефлекс — добавить маршрут или понизить метрику, и именно этот рефлекс и есть миф, который стоит убить первым. Когда собственная LAN клиента и пул туннеля претендуют на один и тот же префикс, таблица маршрутизации держит два несовместимых факта, и ни маршрут по умолчанию, ни метрика их не разрешают. Исправление — это решение об адресации, и никакое редактирование маршрутов его не заменит.

Почему дополнительный маршрут не может разделить один префикс

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

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Спросите систему об одном адресе и отметьте, какой интерфейс она называет. Linux, macOS и Windows отвечают поиском только для чтения, который сообщает выбранный интерфейс и следующий переход, ничего не передавая. Когда ответ указывает на физический адаптер при поднятом туннеле, ядро считает адрес находящимся на канале, а не тем, что туннель мог бы нести.

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

Прочитайте пул, который клиент действительно получил

Читайте то, что получил клиент, а не маркетинговую страницу провайдера. Повысьте подробность журнала клиента OpenVPN, и маршруты, которые проталкивает сервер, появятся в нём, раскрывая префиксы туннеля; в других местах пул виден в деталях подключения или на самом адаптере. Попросите у провайдера полный список приватных диапазонов, которые он использует, потому что одна /24 сегодня может стать двумя завтра. Избегать привычных блоков RFC 1918 — не то же самое, что избегать выделения, которое вам действительно дали.

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

Перенумерация — это исправление, которое вы можете сделать

Если сервер VPN не ваш, чтобы его менять, перенос домашней LAN — единственное доступное исправление, и это обычная ситуация с коммерческим провайдером. Выберите диапазон вне пула провайдера и вне диапазонов, которые могут понадобиться позже, и проверьте его против каждого другого места, куда вы попадаете через туннель. Ждите короткого перерыва и более длинного хвоста забытых устройств: устройство, у которого остался старый адрес, выглядит работающим, пока ему не понадобится шлюз.

  1. Сначала инвентаризация: собственный адрес маршрутизатора, область DHCP, резервирования, перенаправления портов и каждое устройство, адрес которого введён вручную.
  2. Затем измените префикс LAN маршрутизатора и область DHCP вместе в рамках окна обслуживания и обновите проводные аренды раньше беспроводных.
  3. Дальше исправьте статические адреса: принтеры, сетевое хранилище, всё с жёстко прописанным шлюзом.
  4. Наконец, переподключите клиент VPN и подтвердите, что адрес туннеля больше не конфликтует с LAN.

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

Что может и чего не может псевдоним

Когда сервер ваш, трансляция адресов на клиенте может показать удалённый префикс внутри свободного локального диапазона, так что тот же хост отвечает по второму адресу. Общинный OpenVPN делает это с помощью client-nat, и эта директива свойственна именно тому клиенту, её нет в коммерческих и мобильных клиентах, с которыми её обычно сравнивают. Схема требует маршрута, соответствующего трансляции, свободного диапазона для псевдонима и сервера, готового отвечать на нетранслированный адрес клиента. Ничто из этого не помогает, когда клиент принадлежит управляемому провайдеру, который вы не можете настроить.

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

Запишите префиксы, на которых вы остановились, там, куда люди действительно смотрят: в сетевых заметках, в поле комментария маршрутизатора, на странице знакомства. Кто-то снова выберет 192.168.1.0/24, и конфликт вернётся вместе с ним.

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