Azure privat IP VPN over ExpressRoute uten NVA

Myten er at kryptering av trafikk over ExpressRoute privat peering krever et virtuelt nettverksapparat. Det gjør den ikke. Azure støtter en Site-to-Site VPN Gateway der tunnelendepunktet er en privat RFC1918-adresse som bæres over kretsen, og apparatet er valgfritt snarere enn strukturelt. Det apparatmyten skjuler, er den delen som virkelig svir: å aktivere det private endepunktet på ett objekt i stedet for to, og å la en direkte peering-rute stille vinne over den krypterte veien.

Hvor myten kom fra

Påstanden har en respektabel opprinnelse. I årevis var den praktiske oppskriften for IPsec over privat peering en NVA, fordi den administrerte gatewayen bare eksponerte offentlige endepunkter. Det endret seg, og svar skrevet før endringen siteres fortsatt i tråder der ingen sjekker datoen. Rettelsen er smal: en VPN-gateway med privat adresse finnes, og den endrer endepunktet, ikke rutelogikken rundt det.

Ingenting av dette pensjonerer NVA-en. Det pensjonerer antakelsen om at et apparat er den eneste veien til kravet.

Aktiver det private endepunktet på begge nivåer

Start med en fungerende ExpressRoute privat peering-tilkobling knyttet til VNetet som inneholder VPN-gatewayen. Den lokale siden må allerede nå de relevante private adressene over den kretsen, fordi tunnelen vil bruke disse adressene som transport. Deretter gateway-forutsetningen: Microsofts prosedyre for privat-IP VPN krever en gateway bygget på en Standard offentlig IP-ressurs. Privat tunneladressering fjerner ikke dette kravet, noe som overrasker folk som antar at «privat» betyr «ingen offentlig IP noe sted».

Aktiver nå flagget begge steder. Gateway-konfigurasjonen har sin egen bryter for private IP-er, og den enkelte Site-to-Site-tilkoblingen har en annen som får den tilkoblingen til å bruke den private adressen. Å sette den ene og ikke den andre er den vanligste ufullstendige konfigurasjonen; tunnelen blir enten ikke 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}'

Bekreft egenskapsnavnene mot CLI-versjonen du har installert, fordi portaletikettene og CLI-egenskapene ikke alltid har samme ordlyd. En aktiv-aktiv gateway eksponerer to private tunneladresser, og den lokale enheten trenger begge peerne konfigurert hvis redundansen skal bety noe. BGP er ikke påkrevd bare for å få denne privat adresserte tunnelen opp, selv om det vanligvis er en del av måten du distribuerer prefikser på.

Den andre myten: en etablert tunnel krypterer trafikken din

To veier når nå applikasjonsnettet: den direkte privat peering-veien og veien gjennom VPN-en. Begge virker. Bare én bruker dette IPsec-laget. Microsoft dokumenterer at når identiske prefikser annonseres over ExpressRoute og over VPN-en, foretrekker Azure den direkte ExpressRoute-veien, så en sunn tunnel med sunne tellere beviser ingenting om hvor applikasjonspakkene tok veien.

De dokumenterte styringsmetodene er et dekkende område på ExpressRoute med et mer spesifikt beskyttet område på VPN-en, eller adskilte prefikser på de to veiene. Som illustrasjon kan privat peering bære 10.40.0.0/16, mens VPN-en annonserer 10.40.12.0/24. Det mer spesifikke prefikset vinner, og resten av området forblir 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

Gjør den samme kontrollen i lokal retning, siden ruteren din bestemmer hvilken vei utgående trafikk går. Og hold tunnelens egen transport på ExpressRoute-veien; en rute som drar gatewayens private endepunkt inn i tunnelen, gjør tunnelen avhengig av seg selv.

Bestem hva som skjer når tunnelen faller

En mer spesifikk VPN-rute forsvinner når tunnelen faller, mens den bredere direkte ruten blir værende. Trafikken flyter da ukryptert, og alt ser sunt ut, noe som er den verste feilmodusen for et krav som finnes for å garantere kryptering. Hvis kravet forbyr den tilbakefallen, må rutingen og tilgangspolicyen si det eksplisitt i stedet for å stole på tunnelens tilgjengelighet.

Skriv ned hvilke prefikser som kan forbli direkte tilgjengelige, og hvilke som må stoppe når den krypterte veien mangler. Test deretter det tillatte tilfellet med ekte trafikk og sammenlign tilkoblingstellerne, fordi rutetabellen alene ikke forteller deg om krypteringskravet fortsatt gjelder.

Den rammen lar deg også vurdere en NVA etter dens faktiske funksjoner, som flere tunneler, gjennomstrømning eller leverandørinspeksjon, i stedet for å kjøpe en fordi endepunktet er privat.