VPN уровня L2 против туннеля L3: пять проверок перед объединением площадки

Вы объединяете площадку, потому что какой-то инструмент настаивает, что она должна быть в той же сети, а через три недели в два часа ночи читаете журналы коммутатора. Такая интуиция решает судьбу слишком многих каналов Ethernet-over-IP. Здесь действительно важно только одно различие: передаются ли целые кадры от края до края или только IP-пакеты. Выполните пять проверок ниже по порядку и остановитесь на первой, которая провалится.

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

Прежде чем в обсуждении появится хоть какое-то название продукта, запишите минуту трафика, который должен пересечь канал: tcpdump -i eth0 -nn -e 'not ip'. Этот параметр -e печатает заголовок канального уровня, и именно эту часть отбрасывает маршрутизируемый туннель. Если запись останется пустой, приложение говорит по IP, и туннель L3 переносит его без изменений. Если кадры всё же появятся, запишите EtherType, потому что 0x0806 — это ARP, 0x88cc — LLDP, а значение производителя обычно означает протокол обнаружения без резервного варианта через IP. Именно в этот момент обычный tun интерфейс перестаёт быть достаточным.

Повторите запись и на удалённой стороне. Кадр, который существует только внутри виртуального коммутатора одного узла, не повод растягивать широковещательный домен через WAN.

Проверьте, нужно ли обнаружению пересекать канал

У маршрутизируемого туннеля нет общего сегмента, поэтому ничто, адресованное группе, не достигает другого конца. ARP, широковещательные рассылки DHCP, mDNS по адресу 224.0.0.251, SSDP и запросы имён NetBIOS — все предполагают канал, который несколько узлов слышат одновременно.

Спросите, от каких из них приложение действительно зависит и есть ли для них уже прокси. Ретранслятор DHCP, отражение mDNS и статические записи ARP убирают по одной зависимости, и каждая из них — ещё один сервис, который нужно запускать и отслеживать. Когда остаются два или три, объединение — честный ответ.

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

Кадрам нужно где-то жить, поэтому всё, что вы отправляете, получает второй стек заголовков вокруг себя. В оверлее VXLAN это означает внешний заголовок IP, заголовок UDP и 8-байтовый заголовок VXLAN, что выталкивает полноразмерную полезную нагрузку в 1,500 байт за пределы MTU пути обычного интернет-канала в 1,500 байт. OpenVPN в режиме tap добавляет свои накладные расходы в том же направлении. Без меньшего MTU на внутренней стороне вы получите канал, который отвечает на ping и встаёт на первой большой передаче.

Счёт не заканчивается на байтах заголовка. Широковещательный и групповой трафик, который коммутатор обрабатывает в аппаратном обеспечении, теперь идёт через WAN, и каждая объединённая площадка наследует тот же план адресов, ту же область DHCP и то же поведение при дублировании адресов. Это делает канал значительно сложнее для аудита, чем маршрутизируемый пул с одним префиксом на площадку.

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

Проверьте, какой именно тип L2 VPN вам предлагают

Сам термин неоднозначен, и эта неоднозначность определяет, кто переносит ваш трафик. Иногда он описывает полезную нагрузку: кадры Ethernet внутри IP, отправленные через интернет как любой другой туннель, как это делают VXLAN, ZeroTier и режим tap OpenVPN. Иногда он описывает купленную услугу: канал Ethernet от оператора или псевдопровод MPLS, соединяющий две площадки внутри одной сети провайдера.

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

Проверьте более дешёвый обходной путь до объединения

Большинство запросов на объединённый канал происходит из-за одного сломанного поиска имён, а не из-за протокола, которому действительно нужны кадры. Сначала пропустите распознаватель и домен поиска через маршрутизируемый туннель: dhcp-option DNS 10.8.0.1 вместе с dhcp-option DOMAIN internal.example в конфигурации сервера OpenVPN решает удивительно много таких случаев. Локальный переадресатор на удалённой стороне делает ту же работу, не перемещая никакого широковещательного трафика.

Если один старый инструмент всё ещё не работает, поставьте его за прокси или промежуточный узел в целевом сегменте. Один переадресатор TCP дешевле в эксплуатации, чем объединённый WAN.

Закройте решение по порядку: несёт ли трафик EtherType, не связанный с IP, должно ли обнаружение пересекать канал, может ли MTU поглотить дополнительные заголовки, действительно ли доступен канал оператора и провалился ли маршрутизируемый обходной путь по причине, которую вы можете назвать? Ответ «нет» на любом шаге завершает спор в пользу туннеля, который у вас уже есть. Приложите запись и список EtherType к записи об изменении, потому что следующий человек задаст тот же вопрос и не захочет повторять измерение.