NVA-сыз ExpressRoute арқылы Azure жеке IP VPN

Аңыз — ExpressRoute жеке peering арқылы трафикті шифрлау үшін виртуалды желілік құрылғы қажет деген. Қажет емес. Azure Site-to-Site VPN Gateway-ді қолдайды, оның туннельдің соңғы нүктесі схема арқылы тасымалданатын жеке RFC1918 мекенжайы, ал құрылғы құрылымдық емес, қосымша. Құрылғы аңызы жасыратын нәрсе — шын мәнінде ауыртатын бөлік: жеке соңғы нүктені екі нысанның орнына бір нысанда қосу және тікелей peering маршрутының шифрланған жолдан үнсіз басым түсуіне жол беру.

Аңыз қайдан шықты

Бұл тұжырымның құрметті негізі бар. Көп жылдар бойы жеке peering үстіндегі IPsec үшін практикалық рецепт NVA болды, өйткені басқарылатын шлюз тек жария соңғы нүктелерді ұсынатын. Бұл өзгерді, және өзгеріске дейін жазылған жауаптар әлі күнге дейін күнді ешкім тексермейтін ағындарда келтіріледі. Түзету тар: жеке мекенжайлы VPN шлюзі бар, және ол соңғы нүктені өзгертеді, айналасындағы маршруттау логикасын емес.

Мұның ешқайсысы NVA-ны зейнетке шығармайды. Ол құрылғы талапқа жетудің жалғыз жолы деген болжамды зейнетке шығарады.

Жеке соңғы нүктені екі деңгейде қосыңыз

VPN шлюзі орналасқан VNet-ке қосылған жұмыс істеп тұрған ExpressRoute жеке peering қосылымынан бастаңыз. Жергілікті жақ сол схема арқылы тиісті жеке мекенжайларға әлдеқашан жетуі керек, өйткені туннель сол мекенжайларды тасымал ретінде пайдаланады. Содан кейін шлюздің алғышарты: жеке IP VPN үшін Microsoft процедурасы Standard жария IP ресурсында құрылған шлюзді талап етеді. Жеке туннельдік мекенжайлау бұл талапты жоймайды, бұл «жеке» деген «еш жерде жария 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-ны соңғы нүкте жеке болғандықтан сатып алудың орнына, оның нақты мүмкіндіктері бойынша бағалауға мүмкіндік береді, мысалы, бірнеше туннель, өткізу қабілеті немесе жеткізуші инспекциясы.