Azure zasebni IP VPN prek ExpressRoute brez NVA

Mit je, da šifriranje prometa prek zasebnega peeringa ExpressRoute zahteva virtualno omrežno napravo. Ne zahteva. Azure podpira Site-to-Site VPN Gateway, katerega končna točka tunela je zasebni naslov RFC1918, ki se prenaša po vezju, in naprava je izbirna, ne strukturna. Kar mit o napravi skriva, je del, ki res boli: omogočanje zasebne končne točke na enem objektu namesto dveh, in dopuščanje, da neposredna peering pot tiho premaga šifrirano pot.

Od kod mit

Trditev ima spoštljiv izvor. Leta je bil praktični recept za IPsec prek zasebnega peeringa NVA, ker je upravljani prehod izpostavljal le javne končne točke. To se je spremenilo, in odgovori, napisani pred spremembo, se še vedno citirajo v nitih, kjer nihče ne preveri datuma. Popravek je ozek: VPN prehod z zasebnim naslovom obstaja in spreminja končno točko, ne logike usmerjanja okoli nje.

Nič od tega ne upokoji NVA. Upokoji predpostavko, da je naprava edina pot do zahteve.

Omogočite zasebno končno točko na obeh ravneh

Začnite z delujočo povezavo zasebnega peeringa ExpressRoute, povezano z VNet, v katerem je VPN prehod. Lokalna stran mora že dosegati ustrezne zasebne naslove po tem vezju, ker bo tunel te naslove uporabljal kot transport. Nato predpogoj prehoda: Microsoftov postopek za VPN z zasebnim IP zahteva prehod, zgrajen na javnem IP viru Standard. Zasebno naslavljanje tunela te zahteve ne odpravi, kar preseneti ljudi, ki predpostavljajo, da »zasebno« pomeni »nikjer nobenega javnega IP«.

Zdaj omogočite zastavico na obeh mestih. Konfiguracija prehoda ima svoje stikalo za zasebne IP, posamezna povezava Site-to-Site pa drugega, ki tej povezavi omogoči uporabo zasebnega naslova. Nastaviti eno in ne drugo je najpogostejša nepopolna konfiguracija; tunel se bodisi ne vzpostavi bodisi vzpostavi na napačno končno točko.

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

Preverite imena lastnosti glede na nameščeno različico CLI, ker oznake portala in lastnosti CLI nimajo vedno enakega izražanja. Aktivno-aktivni prehod izpostavi dva zasebna naslova tunela, in lokalna naprava potrebuje konfigurirana oba partnerja, če naj ta redundanca kaj pomeni. BGP ni potreben samo za dvig tega tunela z zasebnim naslovom, čeprav je običajno del načina distribucije predpon.

Drugi mit: vzpostavljen tunel šifrira vaš promet

Dve poti zdaj dosegata aplikacijsko omrežje: neposredna pot zasebnega peeringa in pot skozi VPN. Obe delujeta. Le ena uporablja to plast IPsec. Microsoft dokumentira, da ko se enake predpone oglašujejo prek ExpressRoute in prek VPN, Azure daje prednost neposredni poti ExpressRoute, zato zdrav tunel z zdravimi števci ne dokazuje ničesar o tem, kam so šli aplikacijski paketi.

Dokumentirane metode usmerjanja so pokrivni obseg na ExpressRoute in bolj specifičen zaščiten obseg na VPN, ali ločene predpone na obeh poteh. Na primer, zasebni peering lahko nosi 10.40.0.0/16, medtem ko VPN oglašuje 10.40.12.0/24. Bolj specifična predpona zmaga in preostanek obsega ostane neposreden.

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

Enako preverjanje opravite v lokalni smeri, saj preferenca vašega usmerjevalnika odloča, po kateri strani odhaja odhodni promet. In lastni transport tunela držite na poti ExpressRoute; pot, ki potegne zasebno končno točko prehoda v tunel, naredi tunel odvisen od sebe.

Odločite, kaj se zgodi, ko tunel pade

Bolj specifična pot VPN izgine, ko tunel pade, medtem ko širša neposredna pot ostane. Promet takrat teče nešifriran in vse izgleda zdravo, kar je najslabši način odpovedi za zahtevo, ki obstaja za zagotavljanje šifriranja. Če zahteva prepoveduje ta povratek, morata usmerjanje in dostopna politika to povedati izrecno, namesto da se zanašata na razpoložljivost tunela.

Zapišite, katere predpone lahko ostanejo neposredno dosegljive in katere se morajo ustaviti, ko šifrirane poti ni. Nato preizkusite dovoljeni primer z resničnim prometom in primerjajte števce povezave, ker samo usmerjevalna tabela vam ne bo povedala, ali zahteva po šifriranju še velja.

Ta okvir vam omogoča tudi, da NVA ocenite po njegovih dejanskih funkcijah, kot so več tunelov, prepustnost ali pregled dobavitelja, namesto da bi ga kupili zato, ker je končna točka zasebna.