Azure privat IP VPN over ExpressRoute utan ein NVA

Myten er at kryptering av trafikk over ExpressRoute privat peering krev eit virtuelt nettverksapparat. Det gjer han ikkje. Azure støttar ein Site-to-Site VPN Gateway der tunnelendepunktet er ei privat RFC1918-adresse som vert boren over krinsen, og apparatet er valfritt snarare enn strukturelt. Det apparatmyten skjuler, er den delen som verkeleg svir: å slå på det private endepunktet på eitt objekt i staden for to, og å la ei direkte peering-rute stille vinne over den krypterte vegen.

Kvar myten kom frå

Påstanden har ein respektabel opphav. I årevis var den praktiske oppskrifta for IPsec over privat peering ein NVA, fordi den administrerte gatewayen berre eksponerte offentlege endepunkt. Det endra seg, og svar skrivne før endringa vert framleis siterte i trådar der ingen sjekkar datoen. Rettinga er smal: ein VPN-gateway med privat adresse finst, og han endrar endepunktet, ikkje rutelogikken rundt det.

Ingenting av dette pensjonerer NVA-en. Det pensjonerer antekninga om at eit apparat er den einaste vegen til kravet.

Slå på det private endepunktet på begge nivå

Start med ei fungerande ExpressRoute privat peering-tilkopling knytt til VNetet som inneheld VPN-gatewayen. Den lokale sida må allereie nå dei relevante private adressene over den krinsen, fordi tunnelen vil bruke desse adressene som transport. Deretter gateway-føresetnaden: prosedyren til Microsoft for privat-IP VPN krev ein gateway bygd på ein Standard offentleg IP-ressurs. Privat tunneladressering fjernar ikkje dette kravet, noko som overraskar folk som antek at «privat» tyder «ingen offentleg IP nokon stad».

Slå no på flagget begge stader. Gateway-konfigurasjonen har sin eigen brytar for private IP-ar, og den einskilde Site-to-Site-tilkoplinga har ein annan som får den tilkoplinga til å bruke den private adressa. Å setje den eine og ikkje den andre er den vanlegaste ufullstendige konfigurasjonen; tunnelen vert anten ikkje etablert eller etablert mot feil endepunkt.

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

Stadfest eigenskapnamna mot CLI-versjonen du har installert, fordi portalaetikettane og CLI-eigenskapane ikkje alltid har same ordlyd. Ein aktiv-aktiv gateway eksponerer to private tunneladresser, og den lokale eininga treng begge peerane konfigurerte om redundansen skal bety noko. BGP er ikkje påkravd berre for å få denne privat adresserte tunnelen opp, sjølv om det vanlegvis er ein del av måten du fordeler prefiks på.

Den andre myten: ein etablert tunnel krypterer trafikken din

To vegar når no applikasjonsnettet: den direkte privat peering-vegen og vegen gjennom VPN-en. Begge verkar. Berre éin brukar dette IPsec-laget. Microsoft dokumenterer at når identiske prefiks vert annonserte over ExpressRoute og over VPN-en, føretrekker Azure den direkte ExpressRoute-vegen, så ein sunn tunnel med sunne teljarar beviser ingenting om kvar applikasjonspakka tok vegen.

Dei dokumenterte styringsmetodane er eit dekkjande område på ExpressRoute med eit meir spesifikt verna område på VPN-en, eller åtskilde prefiks på dei to vegane. Til dømes kan privat peering bera 10.40.0.0/16, medan VPN-en annonserer 10.40.12.0/24. Det meir spesifikke prefikset vinn, og resten av området held fram som direkte.

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

Gjer den same kontrollen i lokal retning, sidan rutaren din avgjer kva veg utgåande trafikk går. Og hald den eigen transportsvegen til tunnelen på ExpressRoute-vegen; ei rute som dreg det private endepunktet til gatewayen inn i tunnelen, gjer tunnelen avhengig av seg sjølv.

Avgjer kva som skjer når tunnelen fell

Ei meir spesifikk VPN-rute forsvinn når tunnelen fell, medan den breiare direkte ruta vert verande. Trafikken flyt då ukryptert, og alt ser sunt ut, noko som er den verste feilmodusen for eit krav som finst for å garantere kryptering. Viss kravet forbyr den tilbakefallen, må rutinga og tilgangspolitikken seie det eksplisitt i staden for å stole på tilgjenge til tunnelen.

Skriv ned kva prefiks som kan halde fram med å vere direkte tilgjengelege, og kva som må stoppe når den krypterte vegen manglar. Test deretter det tillatne tilfellet med ekte trafikk og samanlikn tilkoplingsteljarane, fordi rutetabellen åleine ikkje fortel deg om krypteringskravet framleis gjeld.

Den ramma lèt deg òg vurdere ein NVA etter dei faktiske funksjonane hans, som fleire tunnelar, gjennomstrøyming eller leverandørinspeksjon, i staden for å kjøpe ein fordi endepunktet er privat.