Azures privata IP-VPN över ExpressRoute utan en NVA

Myten är att kryptering av trafik över ExpressRoutes privata peering kräver en virtuell nätverksapparat. Det gör den inte. Azure stöder en Site-to-Site VPN Gateway vars tunneländpunkt är en privat RFC1918-adress som bärs över kretsen, och apparaten är valfri snarare än strukturell. Det apparatmyten döljer är den del som verkligen svider: att aktivera den privata ändpunkten på ett objekt i stället för två, och att låta en direkt peering-rutt tyst vinna över den krypterade vägen.

Varifrån myten kom

Påståendet har ett respektabelt ursprung. I åratal var det praktiska receptet för IPsec över privat peering en NVA, eftersom den hanterade gatewayen bara exponerade offentliga ändpunkter. Det ändrades, och svar skrivna före ändringen citeras fortfarande i trådar där ingen kontrollerar datumet. Rättelsen är snäv: det finns en VPN-gateway med privat adress, och den ändrar ändpunkten, inte routningslogiken runt den.

Inget av detta pensionerar NVA:n. Det pensionerar antagandet att en apparat är den enda vägen till kravet.

Aktivera den privata ändpunkten på båda nivåerna

Börja med en fungerande ExpressRoute privat peering-anslutning kopplad till det VNet som innehåller VPN-gatewayen. Den lokala sidan måste redan nå de relevanta privata adresserna över den kretsen, eftersom tunneln använder dessa adresser som transport. Sedan gateway-förutsättningen: Microsofts procedur för privat-IP-VPN kräver en gateway byggd på en Standard offentlig IP-resurs. Privat tunneladressering tar inte bort det kravet, vilket förvånar folk som antar att ”privat” betyder ”ingen offentlig IP någonstans”.

Aktivera nu flaggan på båda ställena. Gateway-konfigurationen har sin egen växel för privata IP-adresser, och den enskilda Site-to-Site-anslutningen har en andra som får den anslutningen att använda den privata adressen. Att sätta den ena och inte den andra är den vanligaste ofullständiga konfigurationen; tunneln upprättas antingen inte eller upprättas mot fel ändpunkt.

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äfta egenskapsnamnen mot den installerade CLI-versionen, eftersom portalens etiketter och CLI-egenskaperna inte alltid har samma formulering. En aktiv-aktiv gateway exponerar två privata tunneladresser, och den lokala enheten behöver båda peerarna konfigurerade om redundansen ska betyda något. BGP krävs inte bara för att få upp denna privat adresserade tunnel, även om det vanligtvis är en del av hur du distribuerar prefix.

Den andra myten: en upprättad tunnel krypterar din trafik

Två vägar når nu applikationsnätet: den direkta privata peering-vägen och vägen genom VPN:et. Båda fungerar. Bara en tillämpar detta IPsec-lager. Microsoft dokumenterar att när identiska prefix annonseras över ExpressRoute och över VPN:et föredrar Azure den direkta ExpressRoute-vägen, så en frisk tunnel med friska räknare bevisar ingenting om var applikationspaketen tog vägen.

De dokumenterade styrningsmetoderna är ett täckande intervall på ExpressRoute med ett mer specifikt skyddat intervall på VPN:et, eller disjunkta prefix på de två vägarna. Som illustration kan privat peering bära 10.40.0.0/16 medan VPN:et annonserar 10.40.12.0/24. Det mer specifika prefixet vinner och resten av intervallet förblir direkt.

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

Gör samma kontroll i den lokala riktningen, eftersom din routers preferens avgör vilken väg utgående trafik tar. Och håll tunnelns egen transport på ExpressRoute-vägen; en rutt som drar in gatewayens privata ändpunkt i tunneln gör tunneln beroende av sig själv.

Bestäm vad som händer när tunneln faller

En mer specifik VPN-rutt försvinner när tunneln faller, medan den bredare direkta rutten finns kvar. Trafiken flyter då okrypterad och allt ser friskt ut, vilket är det sämsta felsättet för ett krav som finns för att garantera kryptering. Om kravet förbjuder den återgången måste routningen och åtkomstpolicyn säga det uttryckligen i stället för att lita på tunnelns tillgänglighet.

Skriv ned vilka prefix som får förbli direkt nåbara och vilka som måste stoppas när den krypterade vägen saknas. Testa sedan det tillåtna fallet med verklig trafik och jämför anslutningsräknarna, eftersom routtabellen ensam inte säger om krypteringskravet fortfarande gäller.

Den ramen låter dig också utvärdera en NVA efter dess faktiska funktioner, som flera tunnlar, genomströmning eller leverantörsinspektion, i stället för att köpa en för att ändpunkten är privat.