Нужны ли двум площадкам одинаковые VLAN ID для VPN между площадками?

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

Миф: одинаковые VLAN ID на обоих концах

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

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

Обратная проверка столь же показательна. Дайте обоим офисам одну и ту же подсеть, и никакое количество совпадающих номеров VLAN не сделает адрес однозначным.

Что туннель на самом деле передаёт

IPsec защищает IP-пакеты согласно политике, выраженной в адресах, протоколах и портах. Архитектура IPsec описывает эти селекторы на уровне IP, который на несколько уровней выше всего, что описывает тег коммутатора. Когда пакет входит в туннель, он уже покинул VLAN; тег израсходован локальным коммутатором.

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

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

ip xfrm policy
ip route show
swanctl --list-sas

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

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

Когда перенумерация невозможна, продуманный проект трансляции может представить каждой стороне разные представления адресов. Это означает взаимно однозначное сопоставление, совпадающие селекторы, записи DNS, отражающие транслированное представление, и обратную маршрутизацию, переживающую перезапись. Это поддерживаемый проект с реальными эксплуатационными затратами, и не он делает изменение VLAN ID.

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

Одна задача на уровень, записанная

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

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

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

Подтвердите локальную картину инструментами bridge, прежде чем предполагать, что тег доходит до туннеля.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Когда расширение layer-2 — это настоящее требование

Некоторым проектам действительно нужно поведение Ethernet между площадками: устаревшее приложение, полагающееся на широковещательное обнаружение, миграция, при которой адрес должен сохраниться, пока машина переезжает, или протокол, встраивающий допущения layer-2. Такие случаи требуют overlay или мостовой службы, переносящей кадры, и тогда членство в VLAN, предотвращение петель и обработка отказов становятся сквозными вопросами.

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

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