Azure'i privaatne IP VPN üle ExpressRoute'i ilma NVA-ta

Müüt on, et ExpressRoute'i privaatse peeringu kohal liikluse krüpteerimiseks on vaja virtuaalset võrguseadet. Ei ole. Azure toetab Site-to-Site VPN Gateway'd, mille tunneli lõpp-punkt on privaatne RFC1918 aadress, mida kantakse üle vooluringi, ja seade on valikuline, mitte struktuurne. See, mida seadme müüt varjab, on osa, mis tegelikult hammustab: privaatse lõpp-punkti lubamine ühel objektil kahe asemel ja otsese peering-marsruudi vaikselt krüpteeritud tee üle võitmine.

Kust müüt tuli

Väitel on lugupeetud päritolu. Aastaid oli privaatse peeringu kohal IPsec'i praktiline retsept NVA, sest hallatav lüüs pakkus ainult avalikke lõpp-punkte. See muutus ja enne muudatust kirjutatud vastused on ikka veel tsiteeritud lõimedes, kus keegi kuupäeva ei kontrolli. Parandus on kitsas: privaatse aadressiga VPN-lüüs on olemas ja see muudab lõpp-punkti, mitte selle ümber olevat marsruutimisloogikat.

Miski sellest ei läheta NVA-d pensionile. See lähetab pensionile eelduse, et seade on ainus tee nõudeni.

Lubage privaatne lõpp-punkt mõlemal tasandil

Alustage töötavast ExpressRoute'i privaatse peeringu ühendusest, mis on seotud VNet-iga, kus VPN-lüüs asub. Kohapealne pool peab juba selle vooluringi kaudu asjaomastele privaatsetele aadressidele jõudma, sest tunnel kasutab neid aadresse transpordina. Seejärel lüüsi eeldus: Microsofti protseduur privaatse IP-ga VPN-i jaoks nõuab Standard avaliku IP ressursile ehitatud lüüsi. Privaatne tunneli adresseerimine ei kõrvalda seda nõuet, mis üllatab inimesi, kes eeldavad, et „privaatne“ tähendab „mitte ühtegi avalikku IP-d kusagil“.

Nüüd lubage lipp mõlemas kohas. Lüüsi konfiguratsioonil on oma lüliti privaatsete IP-de jaoks ja üksikul Site-to-Site ühendusel on teine, mis paneb selle ühenduse privaatset aadressi kasutama. Ühe seadistamine ja teise mitte on kõige levinum puudulik konfiguratsioon; tunnel kas ei tule püsti või tuleb püsti vale lõpp-punkti juures.

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

Kontrollige atribuutide nimesid paigaldatud CLI-versiooni vastu, sest portaali sildid ja CLI atribuudid ei ole alati sama sõnastusega. Aktiivne-aktiivne lüüs pakub kahte privaatset tunneli aadressi ja kohapealne seade vajab mõlemat partnerit seadistatuna, kui soovite, et see liiasus midagi tähendaks. BGP-d ei ole vaja lihtsalt selle privaatse aadressiga tunneli püstitamiseks, kuigi see on tavaliselt osa sellest, kuidas te prefikseid jaotate.

Teine müüt: püstitatud tunnel krüpteerib teie liiklust

Rakenduse võrku jõuab nüüd kaks teed: otsene privaatse peeringu tee ja tee läbi VPN-i. Mõlemad töötavad. Ainult üks rakendab seda IPsec kihti. Microsoft dokumenteerib, et kui identseid prefikseid kuulutatakse üle ExpressRoute'i ja üle VPN-i, eelistab Azure otsest ExpressRoute'i teed, seega terve tunnel tervete loenduritega ei tõesta midagi selle kohta, kuhu rakenduse paketid läksid.

Dokumenteeritud suunamismeetodid on kattuv vahemik ExpressRoute'il koos konkreetsema kaitstud vahemikuga VPN-il või mittelõikuvad prefiksid kahel teel. Näiteks võiks privaatne peering kanda 10.40.0.0/16, samal ajal kui VPN kuulutab 10.40.12.0/24. Konkreetsem prefiks võidab ja ülejäänud vahemik jääb otseseks.

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

Tehke sama kontroll kohapealses suunas, sest teie ruuteri eelistus otsustab, kuhu poolt väljuv liiklus lahkub. Ja hoidke tunneli enda transport ExpressRoute'i teel; marsruut, mis tõmbab lüüsi privaatse lõpp-punkti tunnelisse, teeb tunneli endast sõltuvaks.

Otsustage, mis juhtub, kui tunnel langeb

Konkreetsem VPN-marsruut kaob, kui tunnel langeb, samal ajal kui laiem otsene marsruut jääb. Liiklus voolab siis krüpteerimata ja kõik näeb terve välja, mis on halvim tõrkerežiim nõude jaoks, mis on loodud krüpteerimise tagamiseks. Kui nõue keelab selle tagasilanguse, peavad marsruutimine ja juurdepääsupoliitika seda selgesõnaliselt ütlema, selle asemel et lootma tunneli kättesaadavusele.

Kirjutage üles, millised prefiksid võivad jääda otse kättesaadavaks ja millised peavad lakkama, kui krüpteeritud tee puudub. Seejärel testige lubatud juhtumit tegeliku liiklusega ja võrrelge ühenduse loendureid, sest marsruutimistabel üksi ei ütle teile, kas krüpteerimisnõue veel kehtib.

See raamistik lubab teil hinnata NVA-d selle tegelike funktsioonide järgi, nagu mitu tunnelit, läbilaskevõime või tarnija kontroll, selle asemel et osta see sellepärast, et lõpp-punkt on privaatne.