Azure частен IP VPN през 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 по действителните му функции, като множество тунели, пропускателна способност или инспекция от доставчик, вместо да купувате такова, защото крайната точка е частна.