Azure privat IP VPN over ExpressRoute uden en NVA

Myten er, at kryptering af trafik over ExpressRoute privat peering kræver et virtuelt netværksapparat. Det gør den ikke. Azure understøtter en Site-to-Site VPN Gateway, hvis tunnelendepunkt er en privat RFC1918-adresse, der bæres over kredsløbet, og apparatet er valgfrit snarere end strukturelt. Det, apparatmyten skjuler, er den del, der for alvor bider: at aktivere det private endepunkt på ét objekt i stedet for to, og at lade en direkte peering-rute stille vinde over den krypterede vej.

Hvor myten kom fra

Påstanden har en respektabel oprindelse. I årevis var den praktiske opskrift til IPsec over privat peering en NVA, fordi den administrerede gateway kun eksponerede offentlige endepunkter. Det ændrede sig, og svar skrevet før ændringen citeres stadig i tråde, hvor ingen tjekker datoen. Rettelsen er snæver: en VPN-gateway med privat adresse findes, og den ændrer endepunktet, ikke rutelogikken omkring det.

Intet af dette pensionerer NVA'en. Det pensionerer antagelsen om, at et apparat er den eneste vej til kravet.

Aktivér det private endepunkt på begge niveauer

Start med en fungerende ExpressRoute privat peering-forbindelse, der er knyttet til det VNet, som indeholder VPN-gatewayen. Den lokale side skal allerede kunne nå de relevante private adresser over det kredsløb, fordi tunnelen vil bruge disse adresser som transport. Derefter gateway-forudsætningen: Microsofts procedure for privat-IP VPN kræver en gateway bygget på en Standard offentlig IP-ressource. Privat tunneladressering fjerner ikke dette krav, hvilket overrasker folk, der antager, at »privat« betyder »ingen offentlig IP nogetsteds«.

Aktivér nu flaget begge steder. Gateway-konfigurationen har sin egen kontakt til private IP'er, og den enkelte Site-to-Site-forbindelse har en anden, der får den forbindelse til at bruge den private adresse. At sætte den ene og ikke den anden er den mest almindelige ufuldstændige konfiguration; tunnelen enten oprettes ikke eller oprettes til det forkerte 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}'

Bekræft egenskabsnavnene mod den installerede CLI-version, fordi portallabels og CLI-egenskaber ikke altid har samme ordlyd. En aktiv-aktiv gateway eksponerer to private tunneladresser, og den lokale enhed skal have begge peer konfigureret, hvis redundansen skal betyde noget. BGP er ikke påkrævet blot for at få denne privat adresserede tunnel op, selvom det normalt er en del af måden, du fordeler præfikser på.

Den anden myte: en etableret tunnel krypterer din trafik

To veje når nu applikationsnetværket: den direkte privat peering-vej og vejen gennem VPN'en. Begge virker. Kun én anvender dette IPsec-lag. Microsoft dokumenterer, at når identiske præfikser annonceres over ExpressRoute og over VPN'en, foretrækker Azure den direkte ExpressRoute-vej, så en sund tunnel med sunde tællere beviser intet om, hvor applikationspakkerne endte.

De dokumenterede styringsmetoder er et dækkende interval på ExpressRoute med et mere specifikt beskyttet interval på VPN'en, eller adskilte præfikser på de to veje. Som illustration kan privat peering bære 10.40.0.0/16, mens VPN'en annoncerer 10.40.12.0/24. Det mere specifikke præfiks vinder, og resten af intervallet forbliver 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

Foretag den samme kontrol i den lokale retning, da din routers præference afgør, hvilken vej udgående trafik forlader. Og hold tunnelens egen transport på ExpressRoute-vejen; en rute, der trækker gatewayens private endepunkt ind i tunnelen, gør tunnelen afhængig af sig selv.

Beslut, hvad der sker, når tunnelen falder

En mere specifik VPN-rute forsvinder, når tunnelen falder, mens den bredere direkte rute bliver. Trafikken flyder så ukrypteret, og alt ser sundt ud, hvilket er den værste fejltilstand for et krav, der findes for at garantere kryptering. Hvis kravet forbyder dette tilbagefald, skal rutningen og adgangspolitikken sige det eksplicit i stedet for at stole på tunnelens tilgængelighed.

Skriv ned, hvilke præfikser der må forblive direkte tilgængelige, og hvilke der skal stoppe, når den krypterede vej mangler. Test derefter det tilladte tilfælde med rigtig trafik, og sammenlign forbindelsestællerne, fordi rutetabellen alene ikke fortæller dig, om krypteringskravet stadig holder.

Den ramme lader dig også vurdere en NVA ud fra dens faktiske funktioner, såsom flere tunneler, gennemstrømning eller leverandørinspektion, i stedet for at købe en, fordi endepunktet er privat.