Приватний 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 за його реальними функціями, як-от кілька тунелів, пропускна здатність чи інспекція постачальника, замість купувати його через те, що кінцева точка приватна.