Приватный IP VPN Azure через ExpressRoute без NVA

Миф в том, что шифрование трафика через частный peering ExpressRoute требует виртуального сетевого устройства. Не требует. Azure поддерживает Site-to-Site VPN Gateway, конечная точка туннеля которого — частный адрес RFC1918, передаваемый через канал, а устройство необязательно, а не структурно. Миф об устройстве скрывает то, что действительно больно: включение частной конечной точки на одном объекте вместо двух и то, что прямой маршрут peering тихо выигрывает у шифрованного пути.

Откуда взялся миф

У утверждения почтенное происхождение. Годами практическим рецептом для IPsec через частный peering было NVA, потому что управляемый шлюз предоставлял только публичные конечные точки. Это изменилось, но ответы, написанные до изменения, до сих пор цитируются в обсуждениях, где никто не проверяет дату. Исправление узкое: шлюз VPN с частным адресом существует, и он меняет конечную точку, а не логику маршрутизации вокруг неё.

Ничто из этого не отправляет NVA на пенсию. Оно отправляет на пенсию предположение, что устройство — единственный путь к требованию.

Включите частную конечную точку на обоих уровнях

Начните с работающего подключения частного peering ExpressRoute, связанного с VNet, в которой находится шлюз VPN. Локальная сторона уже должна достигать нужных частных адресов через этот канал, потому что туннель использует эти адреса как транспорт. Затем предварительное условие шлюза: процедура Microsoft для VPN с частным IP требует шлюза, построенного на ресурсе публичного IP уровня Standard. Частная адресация туннеля не отменяет это требование, что удивляет людей, полагающих, что «частный» означает «нигде никакого публичного IP».

Теперь включите флаг в обоих местах. В конфигурации шлюза есть свой переключатель для частных IP, а у отдельного подключения Site-to-Site есть второй, который заставляет это подключение использовать частный адрес. Установить один и не установить другой — самая распространённая неполная конфигурация; туннель либо не поднимается, либо поднимается к неверной конечной точке.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

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

Второй миф: установленный туннель шифрует ваш трафик

Теперь к сети приложения ведут два пути: прямой путь частного peering и путь через VPN. Оба работают. Только один применяет этот уровень IPsec. Microsoft документирует, что когда одинаковые префиксы объявляются и через ExpressRoute, и через VPN, Azure предпочитает прямой путь ExpressRoute, поэтому здоровый туннель со здоровыми счётчиками ничего не доказывает о том, куда ушли пакеты приложения.

Документированные методы управления — это охватывающий диапазон на ExpressRoute с более конкретным защищённым диапазоном на VPN или непересекающиеся префиксы на двух путях. Например, частный peering может нести 10.40.0.0/16, а VPN объявляет 10.40.12.0/24. Более конкретный префикс побеждает, а остальная часть диапазона остаётся прямой.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

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

Решите, что произойдёт при падении туннеля

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

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

Такая постановка также позволяет оценивать NVA по его реальным функциям, таким как несколько туннелей, пропускная способность или инспекция поставщика, вместо того чтобы покупать его из-за того, что конечная точка частная.