Azure S2S VPN konektatuta baina trafikorik ez: irakurri IKE erregistroa

Atariak Connected dio, tunelak martxan denboraren kontagailua du, eta zure makina birtualeko trace bat bigarren hop-ean hiltzen da. Konexioaren egoerak IKE eta IPsec negoziazioa deskribatzen du, ez bi aldeetako politika geruzatik pakete bakarra igarotzen den ala ez. Bi hutsegitek azaltzen dituzte txartel horietako gehienak, eta bat ere ez da konpontzen Azureko ibilbide bat aldatuta. Biak jada gatewayak sortutako erregistroan idatzita daude, eta horregatik hasten naiz han, ibilbide-taulatik beharrean.

Zer ziurtatzen duen Connected-ek benetan

Site-to-site konexio konektatu batek esan nahi du 1. eta 2. faseak osatu zirela eta segurtasun-elkarteak aktibo daudela. Negoziazioari buruzko baieztapena da: bi aldeek proposamen batean adostu zuten, gakoak trukatu eta SA pare bat instalatu zuten. Ez du ezer esaten trafiko-hautatzaileek babestuta daudela uste duzun azpisareekin bat egiten duten, ezta urruneko aldeak paketea deskribatu ondoren norabait bideratuko duen ere. Tunel bat asteak egon daiteke zutik fluxu interesgarri guztiak botatzen dituen bitartean, eta hori da jendeak gateway osasuntsu bat berreraikitzera bultzatzen duen eredua.

Lehenengo begiratu beharreko bi hutsegiteak hauek dira: AH ESP ordez proposatzen duen peer bat, eta gatewayak barnekotzat hartuko ez duen espazio batean zenbakitutako sare birtuala.

Ireki esportatutako erregistroa ibilbideak ukitu aurretik

Atarian, ireki sare birtualaren gatewaya eta exekutatu VPN troubleshooter eragiketa konexioan, gero deskargatu sortzen duen paketea eta deskonprimitu. Barruan IKE erregistro bat dago, 1. eta 2. faseen trukeekin, denbora-markekin eta testu arrunt gisa irakurgarria. Bilatu bertan transform lerroa goitik behera irakurri beharrean, sarrera interesgarria normalean ehunka lerro barruago egoten baita. Atarirako sarbiderik ez baduzu, diagnostiko berak gatewayaren erregistro-helmugan agertzen dira diagnostiko-ezarpenak gaituta daudenean.

Bi sarrerek daramate balioaren zatirik handiena. Lehenengoak honen antzera dio: expected ESP with combined authentication and cipher, received AH. Bigarrena IKE trukean zehar payload baliogabearen errorea da, eta horrek normalean proposamen-eremu gaizki eratua edo onartzen ez dena esan nahi du.

Biek lokal gailuak zer proposatu zuen deskribatzen dute, beraz biak peer aldeko ezarpenak dira. Konexioaren Azure aldea birsortzeak ez du aldatzen zure suebakiak bidaltzen duen proposamena, eta hala ere egitea lan-fluxu honetako ordu galduena da. Peer-ean, jarri 2. fasea ESP-n autentifikazio eta zifratze konbinatuekin eta utzi algoritmoa negoziatzen, gero egiaztatu combined mode bezalako izena duen saltzailearen kontrol-lauki batek isilean AH proposamen bat hautatzen duen azpian.

Egiaztatu sare birtualaren helbide-espazioa

Gatewayak sare birtuala barruti pribatuetan egotea espero du. Bloke publiko batean zenbakitutako sare batek, adibidez 111.x-rekin hasten denak, tunela altxa dezake Azurek espazio hori barnekotzat hartzeari uko egiten dion bitartean, beraz konexioa osasuntsu dirudi eta inolako fluxurik ez da onartzen. Egiaztatu helbide-espazioa hautatzaileekin arratsalde oso bat eman aurretik. Zenbakitzea lehengo esleipen baten baldintza gogorra bada, konponbidea helbide-plana aldatzea da, ez bestelako gateway bat.

Idatzi lokal barrutiekin duen gainjartzea helbide-espazioko orrian zauden bitartean, gainjartzen diren aurrizkiek huts egite desberdin bat sortzen baitute, bezeroaren aldetik antzekoa dirudiena.

Egiaztatu aurrizkiak bi norabideetan

Sare lokalaren gateway baliabideak lokal aurrizkiak gordetzen ditu, eta urruneko gailuak benetan babesten dituen azpisareekin bat etorri behar dute. Gailuak baztertzen dituen helbideak barne hartzen dituen laburpen batek fluxu batzuk pasatuko ditu eta beste batzuetan huts egingo du, eta hori tartekako bideratze-hutsegite gisa irakurtzen da, ez konfigurazio-desadostasun gisa. Begiratu urruneko aldea ere: mutur batek /16 zerrendatzen du eta besteak hiru /24 haren barruan — hori da hutsegite partzial klasikoa. Inongo zerrenda ez da berez autoritatea, beraz konparatu itzazu ondoan, ikusten duzunari soilik fidatu beharrean.

Aurrizki-aldaketa ez da beti bere kabuz jasotzen, beraz planifikatu konexio-objektua berriz gordetzea edo berreraikitzea eta gero egiaztatu aurrizki berriak bi aldeetan agertzen direla.

Probatu ibilbide bat, ez ping bat

Tunel funtzionala ibilbide funtzional batetik bereizten duen trace-a horrelakoa da: lehen hop-a local gatewaya da, gero erantzuten ez duten hop batzuk, gero urruneko ostalariak erantzuten du. Trace-ak inoiz ostalarira iristen ez bada, probatu aplikazioak benetan erabiltzen duen TCP ataka, ICMP maiz nahiko iragazten baita ping hutsak oso gutxi frogatzeko. Exekutatu trace bera urruneko ostalari batetik Azureko makina birtual batera. Bi emaitzen arteko asimetria da falta den itzulera-ibilbidea edo norabide bakarra baimentzen duen araua aurkitzeko modurik azkarrena.

Idatzi peer-en proposamena, bi helbide-espazioak eta konexioaren sorrera-denbora txartelean, hurrengo ingeniariak jakin dezan zein balio berreraiki ziren eta zeini ez zitzaion inoiz ukitu.

Erregistroa hutsik itzultzen bada, agian gatewayak ez du zure konexioa batere amaitzen. Egiaztatu sare lokalaren gatewayko peer helbidea erregistroa irakurtzen ari zaren gailuarekin bat datorrela, harpidetza bateko bi gateway erraz nahasten baitira berreraikuntza batean. Hutsegite horrek egun bat kostatzen du eta ez du arrastorik uzten inongo erregistrotan.