Tunela altxatu zen, trafikoa ibili zen, eta geroago logak dio peer SA proposal not match local policy. Jende gehienak lerro hori bi konfigurazioek inoiz bat egin ez zutela frogatzeko irakurtzen du. Normalean zerbait estuagoa esan nahi du: lehen CHILD SArako bat egin zuten eta lehen berritzean bat egiteari utzi zioten, lehen elkarketak ez baitzuen inoiz behar geroagokoek egiten duten trukea. Bereizketa horrek erabakitzen du non begiratu.

Lehen CHILD SAk heredatu egiten du, geroagokoek negoziatu

IKEv2n hasierako CHILD SA IKE_AUTH tartean sortzen da, eta haren gakoak IKE SAren gako-materialetik eratortzen dira. Une hartan ez dago Diffie-Hellman truke bereizirik, beraz peer batek onartu ezin duen PFS taldea ez da oraindik probatzen. Tunela osasuntsu dirudi, geroago huts egingo duzun baldintza ez baitzen inoiz probatu.

CHILD_SA gako-berritzea mezu-sekuentzia desberdina da. PFS konfiguratuta dagoenean, peer-ek gako-truke berria exekutatzen dute eta bi aldeek onartzen duten taldean ados jarri behar dute, baita elkarte berrirako ESP proposamenean ere. Une horretan bihurtzen da desadostasuna ikusgai, eta horregatik erroreak proposamen bat izendatzen du, eta ez ibilbide bat.

Beraz, “atzo funtzionatzen zuen” esateak ez dizu proposamenari buruz ezer esaten. Hasierako trukea ondo atera zela esaten dizu, dagoeneko zekizun zerbait.

Irakurri huts egin zuen trukea, ez lehen pinga

Edozer aldatu aurretik, bildu IKE autentifikazio arrakastatsua, hasierako CHILD SA eta huts egindako ordezkapena bi muturretatik. Gero izenda ezazu eragiketa zehazki: IKE SA gako-berritzea, IKE berrautentifikazioa eta CHILD SA gako-berritzea hiru gertaera desberdin dira, eta “2. fasea” elkarrizketa arruntean horiek guztiak biltzen ditu.

Konparatu beheko eremuak huts egin zuen konexiorako, ez tunelarentzat oro har.

GeruzaKonparatzeko balioak
IKEBertsioa, zifratzea eta osotasuna edo PRF antolamendua, DH taldea
IPsec / CHILDESP zifratzea eta osotasuna, aurreikusitako PFS edo gako-truke taldea
Babestutako trafikoaTokiko eta urruneko hautatzaileak, gehi politiketan oinarritutako hautatzaile-ezarpena

FortiGate-n, ireki fase-2 proposamena, PFS ezarpena eta tunel horretarako onartutako DH taldeak. Irakurri kargatutako balioak, lehenago ezarritako konexio batetik ondorioztatu beharrean. GUI orriaren pantaila-argazkia exekutatzen ari den konfigurazioa baino froga ahulagoa da, biak eguneratze baten ondoren desados egon baitaitezke. Esportatu aldatu duzun atala eta gorde txartelarekin batera.

Azure-ren politika lehenetsia politika da oraindik

Konexioari atxikitako politika pertsonalizaturik ez egoteak ez du esan nahi Azure-k bat ere aplikatzen ez duenik. Konexioa atebidearen proposamen-multzo lehenetsira isurtzen da, eta multzo hori zure FortiGate-k eskaintzen duena baino zabalagoa edo estuagoa izan daiteke. Bi multzoek IKErako gainjartzen badute baina ez PFS duen ESPrako, hutsegite-eredu hau bera lortuko duzu.

Irakurketa-soileko bista honek benetan atxikitako politika erakusten du, sekreturik isuri gabe:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

Erabili zure baliabideen benetako izenak. Politika esplizitua behar denean, ezarri konexioaren baliabidean. Ez da atebide osoko etengailu bat, eta ez zaie isilpean aplikatzen atebide bereko beste tunel batzuei.

Atarian, Configuration orria da konexio horren IPsec/IKE politika pertsonalizatua kokatzen den lekua. Microsoft-en politika pertsonalizatuen gidak onartutako parametroak eta SKU baldintzak zerrendatzen ditu. Azure-k konbinazio oso bat hartzen du konexio bakoitzeko, beraz IKE eremuak eta IPsec eremuak elkarrekin zehazten dituzu, banan-banan ez.

PFS baldintza bat da, ez biratzeko etengailu bat

Zure segurtasun-oinarriak PFS eskatzen badu, konponbidea bi peer-ek bi aldeetan onartzen duten talde bat da, politika batekin adierazia. PFS desaktibatzeak errorea desagerrarazteko, gorde nahi zenuen segurtasun-propietatea aldatzen du, eta normalean geroago beste desadostasun gisa agertzen da.

Azure-ri buruzko tranpa bat: ESPrako GCM aukeratzen duzunean, zifratze- eta osotasun-hautapenek GCM algoritmo bera eta gako-luzera bera izendatu behar dituzte. GCM zifratzailea osotasun-algoritmo bereizi batekin nahasteak zerbitzuak baztertzen duen konbinazioa sortzen du, eta peer arteko desadostasuna ematen du politikak arretaz irakurri arte.

Aukeratu bi muturrek onartzen duten eta zure baldintzak ahalbidetzen duen konbinazio indartsuena, eta gero idatzi aldaketa-erregistroan. Hurrengo pertsonak erregistro horrekin konparatuko du, ez funtzionatzen zuen tunel baten oroimenarekin. Jarri bertan PFS taldea eta ESP proposamena, ez politikaren izena soilik. Geroago norbaitek auditoria bat zergatik huts egin zuen edo berritze bat zergatik den motela galdetzen duenean, lerro horrek bi galderak erantzuten ditu.

Egiaztatu huts egin zuen trukea

Planifikatu aldaketa suspertze-bide batekin, politikaren edizioak konpondu nahi duzun tunela eten baitezake. Trafikoa itzultzean, itxaron edo eragin CHILD_SA berritzea eta egiaztatu elkarte berria aurreikusitako PFS taldearekin ezartzen dela. Gero egiaztatu aplikazio-trafikoak horretan jarraitzen duela.

Bi arrasto faltsu aipatzea merezi du. SA iraupenak tokiko zehaztapenak dira, beraz balio desberdinak normalak dira eta aldatzeak arazoa noiz agertzen den soilik mugitzen du. DPD-k peer bat bizirik dagoen detektatzen du; haren denbora-muga igotzeak ez ditu ESP edo PFS hautapenak lerrokatzen.

Erregistratu negoziatutako emaitza eta aldaketaren ondorengo gertaera. Konexioak orain IKE autentifikazioa amaitu aurretik hutsegiten badu, oraintxe editatu dituzun IKE ezarpenak ari zara begiratzen, ez jatorrizko CHILD-berritzearen hutsegitea.

Erlazionatutako artikuluak