VPN гостя на ESXi: маршрутизация или мост — решите до группы портов
Маршрутизируемому TUN нужны обратные маршруты; мостовому TAP нужна доступность второго уровня и более широкая политика группы портов. Определите роль до расширения режима promiscuous.
Маршрутизируйте пакеты или расширяйте домен Ethernet: изменение группы портов следует за этим выбором. С точки зрения приложения с частным адресом результаты могут выглядеть одинаково, тогда как требования гипервизора совершенно разные. Поэтому сначала расширяют группу портов, а вопрос проектирования решают вторым, обычно после broadcast-шторма. Пройдите эти проверки по порядку и остановитесь, пока требование ещё расплывчато, ведь никакая настройка группы портов не исправит проект, который так и не выбрали.
Решение принадлежит владельцу сервиса; конфигурация гипервизора должна его реализовывать, а не случайно определять.
Проверьте, что на самом деле нужно удалённой стороне
Перечислите сервисы, до которых должны дотянуться удалённые клиенты, и протоколы, которые они используют. Если список — это несколько TCP-сервисов на известных префиксах, маршрутизации хватит. Если чему-то действительно нужна смежность 2-го уровня — обнаружение, зависящее от broadcast, не-IP протоколы, устройство, не принимающее шлюз — маршрутизация это не сымитирует, и об этом нужно сказать рано. Будьте честны насчёт не-IP записей в этом списке, потому что именно там маршрутизируемый проект тихо отказывает неделю спустя.
Затем проверьте пул клиентов. Маршрутизируемому проекту нужны диапазон адресов и явный обратный маршрут на удалённой стороне; мостовому проекту нужно, чтобы расширенный домен Ethernet владел распределением адресов и изоляцией. Что бы вы ни выбрали, кто-то за пределами этой VM должен согласиться.
Что каждый проект требует от виртуальной сети
Два проекта различаются тем, что виртуальная сеть должна выдерживать, и таблица — самый короткий способ это увидеть:
| Проект | Роль на стороне гостя | Что должна вместить виртуальная сеть | Режим отказа при неверном выборе |
|---|---|---|---|
| Маршрутизируемый TUN | Маршрутизатор между отдельными префиксами | Маршрутизируемый пул клиентов плюс обратные пути на удалённой стороне | Клиенты доходят до шлюза и никогда не доходят до сервиса за ним |
| Мостовой TAP | Мост 2-го уровня для клиентов, которые подключаются | Дополнительные идентичности Ethernet, broadcast-трафик и правила VLAN | vSwitch отбрасывает кадры, или проекту нужен режим promiscuous, который никто не одобрил |
Маршрутизация оставляет broadcast-домен на месте и даёт естественное место ограничить, какие сервисы пересекают шлюз. Мост сдвигает границу: клиенты становятся участниками расширенного домена Ethernet, и распределение адресов, изоляция и любая политика 2-го уровня теперь распространяются на них. Запишите выбранную строку в журнал изменений. Фраза вроде «маршрутизируемый TUN, пул клиентов 10.90.0.0/24, обратный маршрут на ядре» не даёт следующему инженеру заново обсуждать проект исходя из настроек группы портов.
Кому можно видеть чьи кадры
Задайте владельцу платформы один вопрос, прежде чем трогать группу портов: требует ли проект, чтобы эта VM получала кадры, адресованные другим участникам? Если ответ нет, ничего в этом разделе не применяется, потому что маршрутизируемому TUN такая видимость никогда не нужна. Если ответ да, то руководство Broadcom по режиму promiscuous — это то, что стоит прочитать: оно объясняет, насколько больше vSwitch видит VM, и рекомендует ограничить эту политику одной группой портов.
Относитесь к этому как к проверке требования, а не как к разрешению. Включите настройку для одного выделенного подключения, когда потребность в мосте записана, и оставьте её выключенной везде остальном. Широкий VLAN-транк, скопированный из другого примера моста, — это та часть, которую никто не вспоминает убрать, а проект с одним VLAN должен оставаться с одним VLAN.
Запишите, какая группа портов изменилась и почему, в том же месте, где записана строка проекта. Именно эта пара делает возможным следующий аудит.
Держите объекты гостя явными
Внутри Linux членство в мосте и владение адресом — отдельные объекты, и их смешение создаёт сбивающее с толку полурабочее состояние. Назначайте адреса интерфейсу моста или маршрутизируемому туннелю, а не обеим сторонам одного пути, и держите порты-участники свободными от IP-конфигурации.
Избегайте независимого размещения одной подсети на маршрутизируемом TUN и на несвязанном Ethernet-интерфейсе. Такая конфигурация создаёт два пути к одному префиксу, асимметричные ответы и ветку поддержки о flapping, где не упоминается ни один из путей. Если гость также размещает контейнеры или локальный гипервизор, проверьте, не мостят ли они уже в тот же uplink. Два моста на одной NIC — это проект, а не авария, которую вы хотите обнаружить в окно изменений.
Подтверждайте путём пакета, а не ping
Проверяйте фактический путь, а не только доступность. С клиента подтвердите, какой адрес источника приходит на удалённый сервис, затем что ответ возвращается тем же путём. На госте проверьте счётчики пересылки для конкретного потока, а на группе портов подтвердите, что не включена дополнительная видимость сверх той, что нужна выбранному проекту.
Наконец, проверьте направление отказа. Остановите туннель или отключите клиента и убедитесь, что трафик не падает тихо на маршрутизируемый путь, который вы считали неиспользуемым, потому что именно это падение и делает мостовой проект тихим непреднамеренным маршрутизатором.