Azure privāts IP VPN pār ExpressRoute bez NVA

Mīts ir tāds, ka trafika šifrēšanai pār ExpressRoute privāto peering nepieciešama virtuāla tīkla iekārta. Nav nepieciešama. Azure atbalsta Site-to-Site VPN Gateway, kura tuneļa galapunkts ir privāta RFC1918 adrese, kas tiek pārnesta pār ķēdi, un iekārta ir neobligāta, nevis strukturāla. Tas, ko iekārtas mīts slēpj, ir daļa, kas patiešām sāp: privātā galapunkta iespējošana vienā objektā, nevis divos, un ļaušana tiešajam peering maršrutam klusi uzvarēt šifrēto ceļu.

No kurienes nāca mīts

Apgalvojumam ir cienījama izcelsme. Gadu gaitā praktiskā IPsec pār privāto peering recepte bija NVA, jo pārvaldītā vārteja piedāvāja tikai publiskos galapunktus. Tas mainījās, un atbildes, kas rakstītas pirms izmaiņām, joprojām tiek citētas pavedienos, kuros neviens nepārbauda datumu. Labojums ir šaurs: pastāv VPN vārteja ar privātu adresi, un tā maina galapunktu, nevis maršrutēšanas loģiku ap to.

Nekas no tā nepensionē NVA. Tas pensionē pieņēmumu, ka iekārta ir vienīgais ceļš uz prasību.

Iespējojiet privāto galapunktu abos līmeņos

Sāciet ar strādājošu ExpressRoute privātā peering savienojumu, kas saistīts ar VNet, kurā atrodas VPN vārteja. Vietējai pusei jau jāsasniedz attiecīgās privātās adreses pār šo ķēdi, jo tunelis izmantos šīs adreses kā transportu. Tad vārtejas priekšnosacījums: Microsoft procedūra privātā IP VPN prasa vārteju, kas būvēta uz Standard publiskā IP resursa. Privāta tuneļa adresācija šo prasību neizslēdz, kas pārsteidz cilvēkus, kuri pieņem, ka „privāts“ nozīmē „nekur nav publiskas IP“.

Tagad iespējojiet karodziņu abās vietās. Vārtejas konfigurācijai ir savs slēdzis privātajām IP, un atsevišķajam Site-to-Site savienojumam ir otrs, kas liek šim savienojumam izmantot privāto adresi. Viena iestatīšana bez otra ir visbiežākā nepilnīgā konfigurācija; tunelis vai nu neveidojas, vai veidojas uz nepareizo galapunktu.

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

Pārbaudiet rekvizītu nosaukumus pret instalēto CLI versiju, jo portāla etiķetes un CLI rekvizīti ne vienmēr lieto vienu un to pašu formulējumu. Aktīva-aktīva vārteja piedāvā divas privātas tuneļa adreses, un vietējai ierīcei jābūt konfigurētiem abiem partneriem, ja vēlaties, lai šī dublēšana kaut ko nozīmētu. BGP nav nepieciešams tikai šī privātās adreses tuneļa pacelšanai, lai gan tas parasti ir daļa no prefiksu izplatīšanas veida.

Otrais mīts: izveidots tunelis šifrē jūsu trafiku

Divi ceļi tagad sasniedz lietojumprogrammas tīklu: tiešais privātā peering ceļš un ceļš caur VPN. Abi darbojas. Tikai viens piemēro šo IPsec slāni. Microsoft dokumentē, ka tad, kad identiski prefiksi tiek reklamēti gan pār ExpressRoute, gan pār VPN, Azure dod priekšroku tiešajam ExpressRoute ceļam, tāpēc vesels tunelis ar veseliem skaitītājiem neko nepierāda par to, kur aizgāja lietojumprogrammas paketes.

Dokumentētās virzīšanas metodes ir pārklājošs diapazons uz ExpressRoute un konkrētāks aizsargāts diapazons uz VPN, vai nekrustojoši prefiksi abos ceļos. Piemēram, privātais peering varētu pārnest 10.40.0.0/16, kamēr VPN reklamē 10.40.12.0/24. Konkrētākais prefikss uzvar, un pārējais diapazons paliek tiešs.

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

Veiciet to pašu pārbaudi vietējā virzienā, jo jūsu maršrutētāja izvēle nosaka, pa kuru pusi iziet izejošais trafiks. Un turiet paša tuneļa transportu uz ExpressRoute ceļa; maršruts, kas ievelk vārtejas privāto galapunktu tunelī, padara tuneli atkarīgu no sevis.

Izlemiet, kas notiek, kad tunelis nokrīt

Konkrētāks VPN maršruts pazūd, kad tunelis nokrīt, kamēr plašākais tiešais maršruts paliek. Tad trafiks plūst nešifrēts un viss izskatās vesels, kas ir sliktākais atteices režīms prasībai, kas pastāv, lai garantētu šifrēšanu. Ja prasība aizliedz šo atkāpšanos, maršrutēšanai un piekļuves politikai tas jāsaka skaidri, nevis jāpaļaujas uz tuneļa pieejamību.

Pierakstiet, kuri prefiksi drīkst palikt tiešā veidā sasniedzami un kuriem jāapstājas, kad šifrētā ceļa nav. Pēc tam pārbaudiet atļauto gadījumu ar reālu trafiku un salīdziniet savienojuma skaitītājus, jo tikai maršrutu tabula jums nepateiks, vai šifrēšanas prasība joprojām ir spēkā.

Šis ietvars arī ļauj novērtēt NVA pēc tā faktiskajām funkcijām, piemēram, vairākiem tuneļiem, caurlaidspēju vai piegādātāja pārbaudi, nevis iegādāties to tāpēc, ka galapunkts ir privāts.