Peering в Azure или VPN между VNet? Решите до маршрутизации

Azure даёт как минимум два способа соединить две виртуальные сети, и это не взаимозаменяемые настройки одного объекта. Peering соединяет VNet в магистрали Microsoft без шлюза; VPN между VNet ставит отношение IPsec между двумя шлюзами, которые вы развёртываете, подбираете по размеру и наблюдаете. Решение сводится к трём условиям, и если вы не можете ответить на все три до добавления маршрута, вы собираетесь строить обход для модели, которую никогда не выбирали.

Три условия, которые определяют модель

Первое — нужно ли чему-то в требовании граница IPsec, которая принадлежит вам и на которую можно указать. Второе — чисты ли адресные пространства и нужно ли двум VNet говорить только друг с другом. Третье — кому принадлежат любой транзитный путь и счёт за шлюз. Отвечайте в этом порядке, потому что первое может исключить peering, как бы привлекательно ни выглядело второе.

Общее для обеих моделей — жёсткое правило адресации: адресные пространства VNet не должны пересекаться. Ни peering, ни VPN между VNet не являются поддерживаемым способом сделать два одинаковых диапазона однозначными, а пересечение требует схемы отображения или перепроектирования, а не другого типа соединения.

Условие 1: нужна ли вам граница IPsec, которой владеете вы?

Peering передаёт трафик по частной магистрали Azure и не требует VPN-шлюза для самого peered-соединения. Это утверждение о транспорте, а не утверждение о шифровании, которое можно передать аудитору как «мы используем IPsec». Если требование называет туннель, настраиваемый клиентом, конкретную политику IKE или границу, которая заканчивается на оборудовании под вашим контролем, peering этого не выполняет, какой бы частной ни была магистраль.

VPN между VNet такую границу даёт: два шлюза, отношение IPsec/IKE, общие ключи и вся операционная поверхность, которая с этим идёт. Вы наследуете состояние туннеля, ёмкость шлюза, ограничения SKU и мониторинг, доказывающий, что туннель поднят. Это правильный ответ, когда требование касается именно этой границы, описанной в обзоре peering как отдельный тип соединения.

Будьте так же осторожны в обратную сторону. «Нам нужно шифрование между VNet» часто закрывается собственным TLS рабочей нагрузки, и тогда шлюз — это расход без требования за ним. Напишите фразу, которую прочитает аудитор, прежде чем выбирать механизм.

Условие 2: топология прямая или чему-то нужно транзитировать?

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

Если требование — доступ к локальной сети через концентратор, транзит шлюза это отдельный проект с конкретными ролями: концентратор владеет шлюзом, peering периферийной сети разрешает транзит шлюза, а периферийная сеть должна разрешать пересылаемый трафик. Это свойства peering, а не автоматические следствия соединения VNet:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Действующая таблица маршрутов — честный ответ на вопрос «существует ли путь?». Она показывает тип следующего перехода, который платформа действительно использует, поэтому peering, который выглядит настроенным, но не соединён, проявляется как отсутствующий или неверный маршрут, а не как загадка.

Условие 3: кому принадлежат транзитный путь и счёт?

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

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

Что бы вы ни выбрали, проверьте три потока: задуманный, отклонённый, который должен остаться отклонённым, и сценарий восстановления, когда шлюз концентратора или peering не работает. Модель, объясняющая только счастливый путь, не проверена, а продемонстрирована.

Проверьте выбор против его собственного утверждения

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

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