Нужен ли подключённому по peering Azure VNet собственный VPN-шлюз?
Подключённому по peering VNet может понадобиться шлюз VPN хаба с поддерживаемым SKU и одной настройкой в каждом направлении peering. Проверяйте действующие маршруты, а не состояние peering.
Появляется новый spoke VNet, у hub уже есть работающий site-to-site шлюз, и очевидный вопрос — нужно ли платить за второй шлюз. Обычно нет: транзит шлюза позволяет spoke использовать шлюз hub через peering. Работает ли это, решают три условия, и ни одно из них не видно на значке состояния peering. Подключение по peering и разрешение использовать чужой шлюз — это разные настройки, поэтому две VM, которые уже пингуют друг друга, ничего не доказывают насчёт пути VPN.
Первое условие: шлюз и его отсутствие в spoke
Azure поддерживает транзит шлюза для SKU VPN Gateway, кроме Basic, и его могут нести как региональный, так и глобальный peering. Spoke использует шлюз, которым не владеет, поэтому своего иметь не может: если в spoke уже есть шлюз или уже выбран вариант удалённого шлюза, нужная настройка транзита будет недоступна или неэффективна. Проверьте это до того, как что-либо отлаживать, потому что неактивный флажок — это симптом, а не неисправность. Сначала прочитайте SKU и существующий шлюз, а затем посмотрите настройки peering.
Не удаляйте существующий шлюз spoke, чтобы появилась опция, пока не узнаете, что от него зависит. Порядок миграции важнее флажка.
Второе условие: одна настройка в каждом направлении peering
Peering — это два объекта, по одному на каждом VNet, и настройки транзита находятся на разных сторонах этой пары. Peering hub в сторону spoke должен разрешать шлюзу hub обслуживать spoke; peering spoke в сторону hub должен принимать шлюз hub. Руководство Microsoft по транзиту шлюза называет их по направлению, и это единственный способ держать их правильно:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
Элемент управления с меткой remote меняет смысл в зависимости от того, peering какого VNet вы редактируете, поэтому читайте направление, а не слово. Настройте обе стороны, сохраните и убедитесь, что peering сообщает о подключении в обоих местах.
Третье условие: адресное пространство и границы разрешений
Транзит не может сделать так, чтобы один и тот же префикс назначения означал две сети, поэтому диапазоны hub, spoke и локальной сети должны не пересекаться, прежде чем что-то из этого заработает. VNet также могут находиться в разных подписках или разных клиентах; это не запрет, но удостоверению, которое создаёт или обновляет каждый peering, нужны необходимые разрешения в этой сети. Изменения между подписками часто терпят неудачу из-за разрешений, и ошибку легко прочитать неправильно как проблему топологии.
Запишите диапазоны и владельцев до изменения. Догадки по любому из них дают peering, который подключается и ничего не маршрутизирует.
Проверяйте по эффективным маршрутам, а не по состоянию peering
Посмотрите эффективные маршруты на сетевом интерфейсе рабочей нагрузки spoke и найдите фактический префикс локальной сети. Проверьте таблицу маршрутов подсети и отключено ли распространение маршрутов шлюза, потому что определяемый пользователем маршрут или устройство проверки может переопределить путь, который предполагают флаги peering. Затем подтвердите обратное направление: локальная сеть должна знать, как достичь префикса spoke через подключение site-to-site — либо через изученные объявления, либо через явный маршрут и соответствующую запись защищённой сети на устройстве клиента. Если префикс отсутствует с любой стороны, менять нужно не флаги peering.
Проверьте одну службу из рабочей нагрузки spoke и проследите за ответом. Проверка со шлюза VPN или с VM в hub задействует другой исходный префикс и другой путь.
Если топология обслуживает и клиентов точка-сеть, отдельно проверьте установленные у них маршруты. Клиентским пакетам Windows может потребоваться пересоздание после изменения топологии, и это задача маршрутизации на стороне клиента, а не доказательство того, что совместное использование шлюза не удалось.
Чего не даёт совместное использование шлюза
Транзит шлюза — это удобство маршрутизации, а не авторизация. Группы безопасности сети, локальные фильтры и правила на уровне службы по-прежнему решают, чего может достичь рабочая нагрузка spoke, поэтому включите конкретную службу от источника к назначению вместо того, чтобы предполагать, что общий туннель разрешает всё за ним.
Peering также не является транзитивным так, как люди надеются. Добавление ещё одного spoke или частной конечной точки вносит свои требования к маршрутизации и доступу, которые существующая настройка транзита не покрывает.