Azure privee IP VPN oer ExpressRoute sûnder NVA

De myte is dat it fersiferjen fan ferkear oer ExpressRoute privee peering in firtueel netwurkapparaat fereasket. Dat is net sa. Azure stipet in Site-to-Site VPN Gateway wêrfan it tunnel-einpunt in privee RFC1918-adres is dat oer it circuit droegen wurdt, en it apparaat is opsjoneel, net struktureel. Wat de apparaat-myte ferberget, is it part dat echt byt: it privee einpunt ynskakelje op ien objekt ynstee fan twa, en in direkte peering-rûte stil gewinne litte oer it fersifere paad.

Wêr't de myte wei kaam

De bewearing hat in respektearre oarsprong. Jierren lang wie it praktyske resept foar IPsec oer privee peering in NVA, om't de behearde gateway allinnich publike einpunten bleatstelde. Dat feroare, en antwurden skreaun foar de feroaring wurde noch altyd sitearre yn triedden wêr't nimmen de datum kontrolearret. De korreksje is smel: in VPN-gateway mei privee adres bestiet, en it feroaret it einpunt, net de rûteleaslogika deromhinne.

Neat fan dit pensionearet de NVA. It pensionearet de oanname dat in apparaat it iennichste paad nei de eask is.

Skeakelje it privee einpunt op beide nivo's yn

Begjin mei in wurkjende ExpressRoute privee peering-ferbining dy't keppele is oan it VNet dat de VPN-gateway hat. De lokale kant moat de oanbelangjende privee adressen al oer dat circuit berikke, om't de tunnel dy adressen as ferfier brûke sil. Dan de gateway-foarwaarde: de Microsoft-proseduere foar privee-IP VPN fereasket in gateway boud op in Standard iepenbiere IP-boarne. Privee tunneladressearring hellet dy eask net fuort, wat minsken ferrasset dy't oannimme dat „privee“ „nearne in iepenbiere IP“ betsjut.

Skeakelje no it flag op beide plakken yn. De gateway-konfiguraasje hat syn eigen skeakel foar privee IP's, en de yndividuele Site-to-Site-ferbining hat in twadde dy't dy ferbining it privee adres brûke lit. Ien ynstelle en de oare net is de meast foarkommende ûnfolsleine konfiguraasje; de tunnel komt of net ta stân of komt ta stân op it ferkearde einpunt.

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

Kontrolearje de eigenskipnammen tsjin de ynstallearre CLI-ferzje, om't portaal-labels en CLI-eigenskippen net altyd deselde wurden hawwe. In aktive-aktive gateway bleatstelt twa privee tunneladressen, en it lokale apparaat hat beide pearen nedich konfigurearre as jo wolle dat dy oerstalligens wat betsjut. BGP is net nedich om allinnich dizze privee-adres-tunnel omheech te krijen, hoewol it meastentiids diel is fan hoe't jo prefiksen ferspriede.

De twadde myte: in fêstige tunnel fersiferet jo ferkear

Twa paden berikke no it applikaasjenetwurk: it direkte privee-peering-paad en it paad troch de VPN. Beide wurkje. Allinnich ien past dizze IPsec-laach ta. Microsoft dokumintearret dat as identike prefiksen oer ExpressRoute en oer de VPN oankundige wurde, Azure it direkte ExpressRoute-paad foarkomt, dus in sûne tunnel mei sûne tellers bewiist neat oer wêr't de applikaasjepakketten hinne giene.

De dokumintearre stjoermetoaden binne in dekkend berik op ExpressRoute mei in mear spesifyk beskerme berik op de VPN, of disjunksje prefiksen op de twa paden. By wize fan foarbyld koe privee peering 10.40.0.0/16 drage wylst de VPN 10.40.12.0/24 oankundiget. It mear spesifike prefiks wint en de rest fan it berik bliuwt 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

Doch deselde kontrôle yn 'e lokale rjochting, om't de foarkar fan jo router beslút wêr't útgeand ferkear wei giet. En hâld it eigen ferfier fan de tunnel op it ExpressRoute-paad; in rûte dy't it privee einpunt fan de gateway de tunnel yn slepe, makket de tunnel fan himsels ôfhinklik.

Beslút wat der bart as de tunnel delgiet

In mear spesifike VPN-rûte ferdwynt as de tunnel delgiet, wylst de bredere direkte rûte bliuwt. Ferkear streamt dan ûnfersifere en alles liket sûn, wat de minste flatermodus is foar in eask dy't bestiet om fersifering te garandearjen. As de eask dy weromfal ferbean, moatte de rûtearring en it tagongsbelied dat eksplisyt sizze ynstee fan op 'e beskikberens fan de tunnel te fertrouwen.

Skriuw op hokker prefiksen direkt berikber bliuwe meie en hokker stopje moatte as it fersifere paad ôfwêzich is. Testje dan it tastiene gefal mei echt ferkear en fergelykje de ferbiningstellers, om't de rûtetabel allinnich jo net fertelle sil oft de fersiferingseask noch jildt.

Dat kader lit jo ek in NVA beoardiele op syn werklike funksjes, lykas meardere tunnels, trochfier of leveransiersynspeksje, ynstee fan ien te keapjen om't it einpunt privee is.