VPN IP privat Azure prin ExpressRoute fără NVA

Mitul este că criptarea traficului prin peeringul privat ExpressRoute necesită un aparat virtual de rețea. Nu necesită. Azure acceptă un Site-to-Site VPN Gateway al cărui punct final al tunelului este o adresă RFC1918 privată transportată prin circuit, iar aparatul este opțional, nu structural. Ce ascunde mitul aparatului este partea care chiar doare: activarea punctului final privat pe un singur obiect în loc de două, și lăsarea unei rute de peering direct să câștige în liniște în fața căii criptate.

De unde a venit mitul

Afirmația are o origine respectabilă. Timp de ani, rețeta practică pentru IPsec prin peering privat a fost o NVA, pentru că gateway-ul administrat expunea doar puncte finale publice. Asta s-a schimbat, iar răspunsurile scrise înainte de schimbare sunt încă citate în fire unde nimeni nu verifică data. Corecția este îngustă: există un gateway VPN cu adresă privată, și el schimbă punctul final, nu logica de rutare din jurul lui.

Nimic din toate acestea nu scoate NVA la pensie. Scoate la pensie presupunerea că un aparat este singura cale către cerință.

Activați punctul final privat la ambele niveluri

Începeți de la o conexiune de peering privat ExpressRoute funcțională, legată de VNet-ul care conține gateway-ul VPN. Partea locală trebuie să ajungă deja la adresele private relevante prin acel circuit, pentru că tunelul va folosi acele adrese ca transport. Apoi condiția prealabilă a gateway-ului: procedura Microsoft pentru VPN cu IP privat necesită un gateway construit pe o resursă IP publică Standard. Adresarea privată a tunelului nu elimină această cerință, ceea ce îi surprinde pe cei care presupun că „privat” înseamnă „niciun IP public nicăieri”.

Acum activați steagul în ambele locuri. Configurația gateway-ului are propriul comutator pentru IP-uri private, iar conexiunea Site-to-Site individuală are un al doilea care face acea conexiune să folosească adresa privată. Setarea unuia fără celălalt este cea mai frecventă configurație incompletă; tunelul fie nu se stabilește, fie se stabilește către punctul final greșit.

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}'

Verificați numele proprietăților față de versiunea CLI instalată, pentru că etichetele portalului și proprietățile CLI nu au întotdeauna aceeași formulare. Un gateway activ-activ expune două adrese private de tunel, iar dispozitivul local trebuie să aibă ambele perechi configurate dacă vreți ca acea redundanță să însemne ceva. BGP nu este necesar doar pentru a ridica acest tunel cu adresă privată, deși de obicei face parte din modul în care distribuiți prefixele.

Al doilea mit: un tunel stabilit criptează traficul

Două căi ajung acum la rețeaua aplicației: calea directă a peeringului privat și calea prin VPN. Ambele funcționează. Doar una aplică acest strat IPsec. Microsoft documentează că, atunci când prefixe identice sunt anunțate prin ExpressRoute și prin VPN, Azure preferă calea directă ExpressRoute, așa că un tunel sănătos cu contoare sănătoase nu demonstrează nimic despre unde au mers pachetele aplicației.

Metodele de direcționare documentate sunt un interval care acoperă ExpressRoute cu un interval protejat mai specific pe VPN, sau prefixe disjuncte pe cele două căi. De exemplu, peeringul privat ar putea transporta 10.40.0.0/16, în timp ce VPN-ul anunță 10.40.12.0/24. Prefixul mai specific câștigă, iar restul intervalului rămâne direct.

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

Faceți aceeași verificare în direcția locală, pentru că preferința routerului decide pe unde iese traficul de ieșire. Și țineți transportul propriu al tunelului pe calea ExpressRoute; o rută care trage punctul final privat al gateway-ului în tunel face tunelul dependent de el însuși.

Decideți ce se întâmplă când tunelul cade

O rută VPN mai specifică dispare când tunelul cade, în timp ce ruta directă mai largă rămâne. Traficul curge atunci necifrat și totul pare sănătos, ceea ce este cel mai rău mod de eșec pentru o cerință care există pentru a garanta criptarea. Dacă cerința interzice acea revenire, rutarea și politica de acces trebuie să spună asta explicit în loc să se bazeze pe disponibilitatea tunelului.

Notați ce prefixe pot rămâne accesibile direct și care trebuie să se oprească atunci când calea criptată lipsește. Apoi testați cazul permis cu trafic real și comparați contoarele conexiunii, pentru că tabelul de rutare singur nu vă va spune dacă cerința de criptare mai este valabilă.

Acel cadru vă permite și să evaluați o NVA după funcțiile ei reale, cum ar fi mai multe tuneluri, debitul sau inspecția furnizorului, în loc să cumpărați una pentru că punctul final este privat.