Почему два сайта с одной подсетью — не одна сеть LAN

Два офиса оба используют 192.168.77.0/24, и кто-то предлагает туннель, чтобы они стали одной сетью. Фраза звучит просто и скрывает три разных решения: две независимые сети LAN, которые конфликтуют, один намеренно растянутый через WAN сегмент Ethernet и схема proxy-ARP, которая отвечает за удалённые адреса. Какое именно у вас — определяет, что узел делает с пакетом, и ответ виден ещё до участия VPN-шлюза.

Узел решает раньше маршрутизатора

Узел с адресом 192.168.77.10/24 сравнивает пункт назначения со своим префиксом. Всё внутри этого префикса находится в прямом канале, поэтому узел сам разрешает адрес канального уровня назначения. Всё вне его уходит на шлюз по умолчанию.

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

Поэтому, когда 192.168.77.20 существует только на другом сайте, локальный узел запрашивает его через ARP и не получает ответа. Рукопожатие VPN может быть совершенно исправным, пока это не работает. Отказ выглядит как мёртвый узел, а не как проблема маршрутизации. Распознавание этой приметы экономит час отладки туннеля.

ARP — это вопрос локального канала

ARP спрашивает, кому принадлежит адрес в этом канале, и ответ должен прийти от того, кто слышит широковещание. Маршрутизатор на другом конце туннеля IPsec его не слышит, если только решение не делает два сайта одним широковещательным доменом.

Два устройства с одинаковым адресом ухудшают дело: даже успешное разрешение не скажет, какое из них ответило.

Дублирование адресов — не ошибка маршрутизации, и никакой маршрут её не исправит. Либо сайты перенумеруются в разные префиксы, либо намеренно становятся одним доменом канального уровня.

Растянутый сегмент переносит кадры, а не маршруты

Туннель, переносящий Ethernet и подключённый к мостам, делает оба сайта частью одного домена канального уровня. Широковещательные ARP-запросы доходят до другой стороны, и каждый мост узнаёт, где находятся какие MAC-адреса. Документация моста в Linux описывает эту границу пересылки на основе MAC.

Здесь удалённый шлюз вовсе не маршрутизирует между двумя одинаковыми подсетями. Кадры проходят через нижний уровень, который сам маршрутизирует IP, а мосты продлевают разговор Ethernet.

Цена — больший радиус поражения. Затопление к неизвестным адресам, петли, выдача DHCP и уникальная адресация — всё требует одного плана, охватывающего оба сайта. Когда WAN падает, узлы теряют трафик, который считают локальным. Фильтрация на мосту и правила VLAN могут ограничить, что проходит, но перенос всё равно не обещает, что дойдёт каждый локальный управляющий кадр.

Proxy ARP — третье решение

Маршрутизатор может ответить на ARP за удалённый адрес и затем маршрутизировать к нему. Это заставляет удалённый узел выглядеть для отправителя находящимся в прямом канале, не растягивая широковещательный домен.

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

Он также не делает произвольные не-IP протоколы маршрутизируемыми и не воспроизводит широковещательный домен Ethernet. Используйте его, когда требование — именно такая замена, а не как короткий путь для отложенной перенумерации.

Выбирайте по требованию, затем проверьте

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

Подтвердите, какое решение у вас на самом деле спросив узел, что он делает с пунктом назначения:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Результат в прямом канале с неудачной записью соседа указывает на отсутствующий путь канального уровня. Результат via называет шлюз и переносит вопрос в маршрутизацию. На мосту проверьте таблицу пересылки, чтобы увидеть, выучен ли MAC через туннель. Каждый вывод сужает вопрос проектирования, а не начинает его заново.