Сайтам, соединённым мостом, всё ещё нужно решение о локальном выходе в интернет

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

Мост переносит кадры, а не решения

Расширение уровня 2 заставляет две площадки выглядеть как один домен широковещания, поэтому запросы ARP, широковещательные сообщения DHCP и трафик в одной подсети проходят через туннель. Это вся услуга, которую он предоставляет. Ничто в мосте не проверяет адрес назначения, не сравнивает его с восходящим каналом сайта и не направляет трафик к ближайшему выходу. Каждый клиент по-прежнему сам принимает решение локальный или удалённый, используя адрес и маску, с которыми он был настроен.

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

Как клиент выбирает свой шлюз

Решение IPv4, описанное в RFC 1122, простое. Адресат внутри подключённой подсети клиента достигается напрямую, через ARP, а адресат за её пределами идёт на настроенный шлюз по умолчанию. Поэтому трафик одной подсети между сайтами может проходить через мост без всякого участия маршрутизатора, и поэтому интернет-трафик полностью зависит от адреса шлюза, который получил клиент. Оба поведения независимы, и работающий общий доступ к файлам доказывает только первое.

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

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

Позвольте DHCP выразить предполагаемый выход

Опция 3 в ответе DHCP предоставляет список адресов маршрутизаторов в подсети клиента в порядке предпочтения, и клиенты обычно берут первый, который отвечает. Механизм в порядке; собственность — вот где проекты ошибаются. Записывайте, что даёт реальная аренда на каждом сайте, вместо того чтобы предполагать, что ближайший сервер DHCP выдаст ближайший шлюз.

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

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

Проверьте четыре вещи по отдельности

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

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

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