Ваш пул VPN — не диапазон DHCP в LAN: почему это ломается

Маршрутизируемый туннель — не сегмент Ethernet. Выберите пул, который не пересекается с LAN, а затем дайте LAN обратный маршрут, прежде чем клиенты попытаются до него добраться.

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

Два распределителя, одно адресное пространство

Сервер DHCP в LAN знает, какие адреса он сдал в аренду и какому MAC-адресу, и защищает их с помощью ARP. У сервера VPN свой пул, и об этих арендах он ничего не знает. Ни один не ошибается; их просто никогда не знакомили.

Адрес из пула LAN, который выдаёт сервер VPN, может уже принадлежать принтеру. Теперь два устройства претендуют на один адрес в одном и том же префиксе, и таблица продвижения коммутатора решает, кто ответит.

Именно с этой неисправностью люди сталкиваются первой: клиент успешно подключается и затем попадает на неправильную машину или попадает на правильную с перебоями.

Почему маршрутизатор не раздаёт адреса VPN

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

Поэтому сервер VPN сам назначает адрес: пул в конфигурации сервера, адрес каждому партнёру в конфигурации WireGuard или адрес, который проталкивает уровень аутентификации при развёртывании IKEv2. Эти механизмы не зависят от базы аренд LAN, и именно поэтому им нужен собственный диапазон.

То же рассуждение объясняет, почему изменение области DHCP не исправляет клиент VPN, который никогда не получает адрес. Клиент не спрашивает сервер LAN, и никакое редактирование области не заставит его спросить.

Пересечение проявляется как конфликт, а не как медленная сеть

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

На практике вы видите ARP-ответы от неправильного устройства, соединения, которые сбрасываются на полпути, и клиента, чей собственный адрес требует кто-то другой. Ничто из этого не выглядит как проблема маршрутизации, поэтому исправление применяется не на том уровне. Двойная аренда легко подтверждается и мешает жить. Она переживает и перезагрузки, потому что оба распределителя продолжают настаивать на одном и том же адресе.

Обратный путь — отдельная проблема

Даже с чистым и отдельным пулом хостам LAN нужно знать, как отвечать клиенту. Их шлюз по умолчанию — маршрутизатор, и маршрутизатору нужен маршрут к пулу, указывающий на сервер VPN, если только проект не транслирует трафик клиента.

Прочитайте путь в обоих направлениях, прежде чем что-либо менять. На шлюзе спросите, какой интерфейс ядро использовало бы для адреса клиента; на клиенте спросите, какой маршрут он использует для адреса LAN.

Эти команды показывают решение о продвижении на шлюзе и записи соседей, которые выявляют дубликат:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Если первая команда отвечает интерфейсом туннеля, обратный маршрут существует. Если она отвечает интерфейсом LAN, маршрутизатор считает, что клиент находится на проводе, и попытается выполнить для него ARP.

Мостовые проекты существуют, но их нужно выбирать

Объединение туннеля с LAN мостом — реальный проект, применяемый, когда клиенты должны получать широковещательные сообщения или их должны обнаруживать протоколы, предполагающие один сегмент. Он требует, чтобы сервер владел этим мостовым поведением и сопутствующей обработкой адресов.

Что не работает — это имитация результата копированием номеров. Общий пул без моста даёт вам конфликт без обнаружения, а это худшее из обоих вариантов.

Выберите третий уровень с отдельным пулом, если только приложению действительно не нужен сегмент, и задокументируйте пул, чтобы следующий администратор не использовал диапазон DHCP снова ради порядка.

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