Azureko IP VPN pribatua ExpressRoute bidez NVArik gabe
Azure VPN Gateway-k IPsec amaitu dezake helbide pribatu batean ExpressRoute bidez. Gaitu bi banderak, eta gero eragotzi peering zuzeneko ibilbideek tunela saihestu dezaten.
Mitoak dio ExpressRoute-ren peering pribatuaren gaineko trafikoa zifratzeko sare-gailu birtual bat behar dela. Ez da behar. Azure-k Site-to-Site VPN Gateway bat onartzen du, zeinaren tunelaren muturra zirkuituan zehar eramaten den RFC1918 helbide pribatu bat baita, eta gailua hautazkoa da, ez egiturazkoa. Gailuaren mitoak ezkutatzen duen zatia da benetan mintzen duena: mutur pribatua bi objektutan beharrean objektu batean gaitzea, eta peering zuzeneko ibilbide batek isil-isilik zifratutako bidea gainditzea.
Nondik etorri zen mitoa
Baieztapenak jatorri errespetagarria du. Urteetan peering pribatuaren gaineko IPsec-erako errezeta praktikoa NVA bat zen, kudeatutako atebideak mutur publikoak soilik erakusten zituelako. Hori aldatu zen, eta aldaketaren aurretik idatzitako erantzunak oraindik aipatzen dira data inork egiaztatzen ez duen harietan. Zuzenketa estua da: badago helbide pribatuko VPN atebide bat, eta muturra aldatzen du, ez inguruko bideratze-logika.
Honek ez du NVA erretiratzen. Gailu bat baldintzarako bide bakarra delako ustea erretiratzen du.
Gaitu mutur pribatua bi mailetan
Hasi ExpressRoute-ren peering pribatuko konexio erabilgarri batekin, VPN atebidea duen VNet-ari lotuta. Tokiko aldeak jada helbide pribatu garrantzitsuetara iritsi behar du zirkuitu horren bidez, tunelak helbide horiek garraio gisa erabiliko baititu. Gero atebidearen baldintza: IP pribatuko VPN-rako Microsoft-en prozedurak Standard IP publiko baliabide baten gainean eraikitako atebide bat eskatzen du. Tunelaren helbide pribatuak ez du baldintza hori kentzen, eta horrek harritzen du «pribatu» hitzak «inon IP publikorik ez» esan nahi duela uste duena.
Orain gaitu bandera bi lekuetan. Atebidearen konfigurazioak bere etengailua du IP pribatuetarako, eta Site-to-Site konexio indibidualak bigarrena du, konexio horri helbide pribatua erabiltzea eragiten diona. Bat ezarri eta bestea ez jartzea da osatugabeko konfiguraziorik ohikoena; tunela edo ez da ezartzen edo mutur okerrean ezartzen da.
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}'
Egiaztatu propietate-izenak instalatutako CLI bertsioarekin, atebidearen etiketek eta CLI propietateek ez baitute beti formulazio bera partekatzen. Atebide aktibo-aktiboak bi tunel-helbide pribatu erakusten ditu, eta tokiko gailuak bi pareak konfiguratuta behar ditu erredundantzia horrek zerbait esan nahi badu. BGP ez da beharrezkoa tunel pribatu hau altxatzeko soilik, nahiz eta normalean aurrizkiak banatzeko moduaren zati izan.
Bigarren mitoa: ezarritako tunel batek zure trafikoa zifratzen du
Bi bide iristen dira orain aplikazio-sareara: peering pribatuko bide zuzena eta VPN bidezko bidea. Biak funtzionatzen dute. Bakarrak aplikatzen du IPsec geruza hau. Microsoft-ek dokumentatzen du aurrizki berdinak ExpressRoute bidez eta VPN bidez iragartzen direnean Azure-k ExpressRoute-ren bide zuzena lehenesten duela, beraz tunel osasuntsu batek kontagailu osasuntsuekin ez du ezer frogatzen aplikazio-paketeek nora joan zirenari buruz.
Dokumentatutako zuzentze-metodoak ExpressRoute-n estaltzen duen barruti bat eta VPN-n barruti babestu zehatzago bat dira, edo bi bideetan aurrizki disjuntuak. Adibidez, peering pribatuak 10.40.0.0/16 eraman lezake eta VPN-k 10.40.12.0/24 iragarri. Aurrizki zehatzenak irabazten du eta barrutiaren gainerakoa zuzen mantentzen da.
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
Egin egiaztapen bera tokiko noranzkoan, zure bideratzailearen hobespenak erabakitzen baitu irteerako trafikoa nondik ateratzen den. Eta mantendu tunelaren garraio propioa ExpressRoute-ren bidean; atebidearen mutur pribatua tunelera arrastatzen duen ibilbide batek tunela bere buruaren mendeko bihurtzen du.
Erabaki zer gertatzen den tunela erortzen denean
VPN ibilbide zehatzagoa desagertzen da tunela erortzen denean, ibilbide zuzen zabalagoa geratzen den bitartean. Orduan trafikoa zifratu gabe isurtzen da eta dena osasuntsu dirudi, eta hori da zifratzea bermatzeko sortutako baldintza baterako huts egiteko modu okerrena. Baldintzak atzera-egite hori debekatzen badu, bideratzeak eta sarbide-politikak hori espresuki esan behar dute, tunelaren erabilgarritasunaren mende jarri beharrean.
Idatzi zein aurrizkik jarraitzen ahal duten zuzenean irisgarri eta zein gelditu behar diren bide zifratua falta denean. Gero probatu onartutako kasua benetako trafikoarekin eta konparatu konexio-kontagailuak, ibilbide-taulak bakarrik ez bait dizu esango zifratze-baldintza oraindik betetzen den.
Plantakamendu horrek NVA bat bere benetako ezaugarrien arabera ebaluatzeko aukera ematen dizu, hala nola tunel anitz, errendimendua edo hornitzailearen ikuskapena, muturra pribatua delako bat erosi beharrean.