Azure privát IP VPN ExpressRoute-on NVA nélkül

A mítosz szerint az ExpressRoute privát peeringjén átfolyó forgalom titkosításához virtuális hálózati berendezés kell. Nem kell. Az Azure támogat egy Site-to-Site VPN Gatewayt, amelynek alagút-végpontja egy privát RFC1918-cím, amelyet az áramkörön keresztül visznek, és a berendezés opcionális, nem strukturális. Amit a berendezés-mítosz elrejt, az az a rész, amely valóban fáj: a privát végpont engedélyezése egy objektumon kettő helyett, és annak engedése, hogy egy közvetlen peering-útvonal csendesen nyerjen a titkosított útvonal felett.

Honnan jött a mítosz

Az állításnak tiszteletreméltó eredete van. Évekig a privát peering feletti IPsec gyakorlati receptje egy NVA volt, mert a felügyelt átjáró csak nyilvános végpontokat tett elérhetővé. Ez megváltozott, és a változás előtt írt válaszokat még mindig olyan szálakban idézik, ahol senki sem ellenőrzi a dátumot. A korrekció szűk: létezik privát című VPN-átjáró, és ez a végpontot változtatja meg, nem a körülötte lévő útválasztási logikát.

Ebből semmi sem vonja nyugdíjba az NVA-t. Azt a feltevést vonja nyugdíjba, hogy a berendezés az egyetlen út a követelményhez.

Engedélyezze a privát végpontot mindkét szinten

Induljon ki egy működő ExpressRoute privát peering-kapcsolatból, amely ahhoz a VNethez kapcsolódik, amelyben a VPN-átjáró van. A helyszíni oldalnak már el kell érnie a megfelelő privát címeket ezen az áramkörön keresztül, mert az alagút ezeket a címeket használja szállításként. Aztán az átjáró előfeltétele: a Microsoft privát IP-s VPN-eljárása Standard nyilvános IP-erőforrásra épített átjárót követel meg. A privát alagútcímzés nem szünteti meg ezt a követelményt, ami meglepi azokat, akik azt feltételezik, hogy a „privát“ azt jelenti: „sehol semmilyen nyilvános IP“.

Most engedélyezze a jelzőt mindkét helyen. Az átjáró konfigurációjának saját kapcsolója van a privát IP-khez, és az egyes Site-to-Site kapcsolatnak van egy másodikja, amely ezt a kapcsolatot a privát cím használatára készteti. Az egyik beállítása a másik nélkül a leggyakoribb hiányos konfiguráció; az alagút vagy nem jön létre, vagy a rossz végponthoz jön létre.

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

Ellenőrizze a tulajdonságneveket a telepített CLI-verzióval, mert a portál címkéi és a CLI-tulajdonságok nem mindig ugyanazt a megfogalmazást használják. Egy aktív-aktív átjáró két privát alagútcímet tesz elérhetővé, és a helyszíni eszköznek mindkét partnert konfigurálnia kell, ha azt akarja, hogy ennek a redundanciának legyen értelme. A BGP nem szükséges pusztán ennek a privát című alagútnak a felállításához, bár általában része annak, ahogy a prefixeket terjeszti.

A második mítosz: a létrejött alagút titkosítja a forgalmat

Két útvonal ér el most az alkalmazáshálózathoz: a közvetlen privát peering-útvonal és a VPN-en át vezető útvonal. Mindkettő működik. Csak az egyik alkalmazza ezt az IPsec-réteget. A Microsoft dokumentálja, hogy amikor azonos prefixeket hirdetnek az ExpressRoute és a VPN felé is, az Azure a közvetlen ExpressRoute-útvonalat részesíti előnyben, így egy egészséges alagút egészséges számlálókkal semmit sem bizonyít arról, hova mentek az alkalmazáscsomagok.

A dokumentált irányítási módszerek egy lefedő tartomány az ExpressRoute-on és egy konkrétabb védett tartomány a VPN-en, vagy diszjunkt prefixek a két útvonalon. Például a privát peering viheti 10.40.0.0/16-et, míg a VPN a 10.40.12.0/24-t hirdeti. A konkrétabb prefix nyer, és a tartomány többi része közvetlen marad.

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

Végezze el ugyanezt az ellenőrzést a helyszíni irányban, mert a router beállítása dönti el, merre lép ki a kimenő forgalom. És tartsa az alagút saját szállítását az ExpressRoute-útvonalon; egy útvonal, amely az átjáró privát végpontját behúzza az alagútba, az alagutat önmagától függővé teszi.

Döntse el, mi történik, ha az alagút leesik

Egy konkrétabb VPN-útvonal eltűnik, amikor az alagút leesik, míg a szélesebb közvetlen útvonal megmarad. A forgalom ekkor titkosítás nélkül folyik, és minden egészségesnek látszik, ami a legrosszabb hibamód annak a követelménynek, amely a titkosítás garantálására létezik. Ha a követelmény tiltja ezt a visszaesést, az útválasztásnak és a hozzáférési házirendnek ezt kifejezetten ki kell mondania, ahelyett hogy az alagút elérhetőségére támaszkodna.

Írja le, mely prefixek maradhatnak közvetlenül elérhetők, és melyeknek meg kell állniuk, ha a titkosított útvonal hiányzik. Ezután tesztelje az engedélyezett esetet valódi forgalommal, és hasonlítsa össze a kapcsolat számlálóit, mert az útválasztási tábla önmagában nem mondja meg, hogy a titkosítási követelmény még érvényes-e.

Ez a keret lehetővé teszi azt is, hogy az NVA-t a tényleges funkciói alapján értékelje, például több alagút, átbocsátóképesség vagy szállítói vizsgálat, ahelyett hogy azért vásárolna egyet, mert a végpont privát.