Azure private IP VPN oor ExpressRoute sonder 'n NVA

Die mite is dat die versleuteling van verkeer oor ExpressRoute private peering 'n virtuele netwerktoestel vereis. Dit is nie so nie. Azure ondersteun 'n Site-to-Site VPN Gateway waarvan die tonnel-eindpunt 'n private RFC1918-adres is wat oor die kring gedra word, en die toestel is opsioneel eerder as struktureel. Wat die toestel-mite verberg, is die deel wat werklik byt: om die private eindpunt op een objek in plaas van twee te aktiveer, en om 'n direkte peering-roete stilweg oor die versleutelde pad te laat wen.

Waar die mite vandaan kom

Die bewering het 'n gerespekteerde herkoms. Jare lank was die praktiese resep vir IPsec oor private peering 'n NVA, omdat die bestuurde gateway slegs openbare eindpunte blootgestel het. Dit het verander, en antwoorde wat voor die verandering geskryf is, word steeds in drade aangehaal waar niemand die datum nagaan nie. Die regstelling is smal: 'n VPN-gateway met 'n private adres bestaan, en dit verander die eindpunt, nie die roeteringslogika daarom nie.

Niks hiervan skrap die NVA nie. Dit skrap die aanname dat 'n toestel die enigste weg na die vereiste is.

Aktiveer die private eindpunt op albei vlakke

Begin by 'n werkende ExpressRoute private-peering-verbinding wat gekoppel is aan die VNet wat die VPN-gateway huisves. Die plaaslike kant moet reeds die betrokke private adresse oor daardie kring bereik, want die tonnel sal daardie adresse as vervoer gebruik. Dan die gateway-voorvereiste: die Microsoft-prosedure vir private-IP VPN vereis 'n gateway wat op 'n Standard openbare IP-bron gebou is. Private tonnel-adressering verwyder nie daardie vereiste nie, wat mense verras wat aanneem dat "private" beteken "geen openbare IP enige plek nie".

Aktiveer nou die vlag op albei plekke. Die gateway-konfigurasie het sy eie skakelaar vir private IP's, en die individuele Site-to-Site-verbinding het 'n tweede een wat daardie verbinding die private adres laat gebruik. Om een in te stel en nie die ander nie, is die enkele mees algemene onvolledige konfigurasie; die tonnel vestig óf nie óf vestig na die verkeerde eindpunt.

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

Bevestig die eiendomsname teen die CLI-weergawe wat jy geïnstalleer het, want portaal-etikette en CLI-eienskappe het nie altyd dieselfde bewoording nie. 'n Aktief-aktiewe gateway stel twee private tonnel-adresse bloot, en die plaaslike toestel het albei eweknieë nodig as jy wil hê daardie oortolligheid moet iets beteken. BGP is nie nodig bloot om hierdie private-adres-tonnel te laat opkom nie, hoewel dit gewoonlik deel is van hoe jy voorvoegsels versprei.

Die tweede mite: 'n gevestigde tonnel versleutel jou verkeer

Twee paaie bereik nou die toepassingsnetwerk: die direkte private-peering-pad en die pad deur die VPN. Albei werk. Slegs een pas hierdie IPsec-laag toe. Microsoft dokumenteer dat wanneer identiese voorvoegsels oor ExpressRoute en oor die VPN geadverteer word, Azure die direkte ExpressRoute-pad verkies, so 'n gesonde tonnel met gesonde tellers bewys niks oor waar toepassingspakkette heen gegaan het nie.

Die gedokumenteerde stuurmetodes is 'n dekkingreeks op ExpressRoute met 'n meer spesifieke beskermde reeks op die VPN, of disjunkte voorvoegsels op die twee paaie. Ter illustrasie kan private peering 10.40.0.0/16 dra terwyl die VPN 10.40.12.0/24 adverteer. Die meer spesifieke voorvoegsel wen en die res van die reeks bly direk.

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

Doen dieselfde kontrole in die plaaslike rigting, aangesien jou roeteerder se voorkeur bepaal watter kant uitgaande verkeer verlaat. En hou die tonnel se eie vervoer op die ExpressRoute-pad; 'n roete wat die gateway se private eindpunt in die tonnel intrek, maak die tonnel van homself afhanklik.

Besluit wat gebeur wanneer die tonnel val

'n Meer spesifieke VPN-roete verdwyn wanneer die tonnel afgaan, terwyl die breër direkte roete bly. Verkeer vloei dan onversleuteld en alles lyk gesond, wat die ergste foutmodus is vir 'n vereiste wat bestaan om versleuteling te waarborg. As die vereiste daardie terugval verbied, moet die roetering en die toegangsbeleid dit eksplisiet sê eerder as om op die tonnel se beskikbaarheid te vertrou.

Skryf neer watter voorvoegsels direk bereikbaar mag bly en watter moet stop wanneer die versleutelde pad afwesig is. Toets dan die toegelate geval met werklike verkeer en vergelyk die verbindingstellers, want die roetentabel alleen sal jou nie vertel of die versleutelingsvereiste nog geld nie.

Daardie raamwerk laat jou ook 'n NVA op sy werklike funksies evalueer, soos veelvuldige tonnels, deurvoer of verskaffer-inspeksie, in plaas daarvan om een te koop omdat die eindpunt privaat is.