VPN-клиент с адресом LAN не находится в LAN

Клиент подключается, получает 10.50.0.200 и не может достичь сервера по адресу 10.50.0.20, хотя оба номера лежат в одной /24. Убеждение, стоящее за этой конфигурацией, состоит в том, что адрес из префикса LAN делает клиента частью LAN. Не делает. Клиент находится на соединении точка-точка, сервер считает назначение локальным, а недостающая часть — ответ соседа, который никто не отправляет.

Миф: одинаковый префикс означает один и тот же сегмент

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

Когда сервер отправляет на 10.50.0.200, он сравнивает назначение со своей маской, считает адрес on-link и спрашивает у локального сегмента аппаратный адрес, который ему принадлежит. Этот запрос уходит через интерфейс Ethernet, а VPN-клиента там нет, чтобы его услышать.

Ничто в конфигурации клиента не может исправить это с его стороны. Путь ответа зависит от того, ответит ли устройство в LAN за клиента, или у клиента будет адрес, который сервер не считает локальным.

Что локальный хост на самом деле делает с адресом

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

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

Поиск маршрута сообщит назначение как on-link через интерфейс Ethernet, и это как раз проблема. Если запись соседа остаётся неполной, пока сессия VPN активна, вы подтвердили, что недостающая часть — разрешение на канальном уровне, а не маршрутизация или политика межсетевого экрана.

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

Как proxy ARP обеспечивает следующий шаг

proxy ARP заставляет шлюз отвечать на запрос канального уровня от имени назначения, до которого он может добраться через другой интерфейс. Хост в LAN получает аппаратный адрес, отправляет кадр шлюзу, и шлюз передаёт пакет в сессию VPN. С точки зрения хоста клиент просто выглядит находящимся за шлюзом. В конфигурации клиента ничего не меняется.

Документация RouterOS по ARP от MikroTik описывает такое применение для dial-in клиентов, которые одалживают адресное пространство подключённой LAN. Механизм — это исправление разрешения соседей, и он работает, потому что шлюз действительно находится на обоих путях.

Это не то же самое, что мост клиента в LAN. Шлюз по-прежнему должен передать пакет в правильную активную сессию, а его маршрутизация и политика межсетевого экрана по-прежнему должны разрешать службу. proxy ARP меняет то, кто отвечает на запрос соседа, а не то, кому разрешено говорить.

Внимательно читайте названия режимов платформы. RouterOS различает proxy-arp и local-proxy-arp, и второй обрабатывает трафик, который входит и выходит через один и тот же интерфейс. Это не взаимозаменяемые написания, и включать оба без разбора — не короткий путь.

Чего proxy ARP вам не даёт

Он не обеспечивает обнаружение через broadcast или multicast. Клиент, которому нужно найти службу через broadcast, всё равно потерпит неудачу, потому что шлюз передаёт unicast в сессию и не делает клиента членом домена broadcast сети LAN. Протоколы обнаружения, полагающиеся на broadcast, — частая причина сообщений о том, что одно работает, а другое нет, в проектах с одолженными адресами.

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

И он не снимает необходимость согласования с владельцем LAN. Запись proxy ARP, которая удивляет владельца плана адресов, — это инцидент поддержки, ждущий спокойной недели.

Сравнение с отдельным маршрутизируемым пулом

Альтернатива — дать VPN-клиентам собственный префикс и позволить хостам LAN маршрутизировать к нему. Тогда сервер отправляет off-link ответы своему шлюзу, шлюз маршрутизирует префикс к конечной точке VPN, и на сегменте LAN разрешение соседей вообще не нужно. Это меньше движущихся частей, чем одолженный адрес плюс ответ proxy.

Такой проект легче обдумать и легче проверить, потому что диапазон клиентов видимо отделён от диапазона LAN. Он стоит маршрута, обратного пути и правила доступа — тех же вещей, которые проект с proxy ARP требует в менее очевидном месте.

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