Ang hindi pagtutugma ng MAC sa IKE ay nangangahulugang bigo ang pagsusuri ng pinagsamang susi

Ipinapakita ng iyong log ng Cloud VPN ang isang pagtatangkang may pinagsamang susi na sinusundan ng mensaheng hindi tugma ang MAC, at ang unang instinct ay madalas hanapin ang problema sa address. Sa sangay na ito ang MAC ay code ng pagpapatunay ng mensahe: isang halagang kinakalkula sa palitan gamit ang napagkasunduang susi. Inihambing ng peer ang sarili nitong kalkulasyon sa halagang natanggap nito, at magkaiba sila. Walang network card na kasangkot, at walang setting ng interface na nagbabago sa paghahambing na iyon.

Sa praktika, dalawang kondisyon ang nagdudulot nito: ang mga sikreto sa dalawang dulo ay hindi pareho ng halaga, o ang mga pagkakakilanlang ginagamit upang piliin ang sikreto ay hindi magkatugma. Pagpasyahan kung alin sa pamamagitan ng pagbasa sa pares, hindi sa nag-iisang tunnel.

Ano ang pinapatunayan ng yugtong ito

Tumatakbo ang pagsusuri pagkatapos magpalitan ng paunang parameter ang dalawang panig at makilala ang sarili. Pumipili ito ng mga kandidatong susi para sa lokal at malayong pagkakakilanlan at sinusubukang patunayan ang natanggap na datos ng pagpapatunay; kapag walang napatunayan, inilalabas ang diagnostic. Iyon ay matibay na pahayag tungkol sa pagpapatunay at mahinang pahayag tungkol sa sanhi, dahil hindi nito sinasabi kung aling panig ang mali.

Ang dating tagumpay ay hindi naisasalin sa pagsusuring ito. Ang natapos na IKE_SA_INIT, o payload ng pagtukoy ng NAT na nagbalik ng inaasahang halaga, ay nagpapatunay na nakakapag-usap ang mga peer. Wala itong pinapatunayan tungkol sa kung may pinagsasaluhan silang sikreto.

Dalawang error sa configuration, isang mensahe

Ang una ay tunay na hindi pagtutugma ng sikreto, at karaniwang aksidente ito sa paghahanda: isang halagang nabuo na inilagay sa isang console at muling tinipa sa isa, isang natitirang karakter sa dulo sa isang panig, o isang quote na kasama ng isang paste. Ang pangalawa ay hindi pagtutugma ng pagkakakilanlan, kung saan tama ang sikreto ngunit ang pagkakakilanlang ipinapakita ng peer ay pumipili ng ibang entry, kaya hindi kailanman nasusubukan ang tamang sikreto. Parehong naglalabas ng parehong linya, kaya ang paghula ay kumakain ng isang hapon.

Ihambing ang pares bago hawakan ang alinman sa mga sikreto. Itugma ang tunnel, endpoint ng peer, window ng oras at malayong configuration, dahil maaaring may magkaibang sikreto ang dalawang redundant na tunnel at ang screen sa harap mo ay maaaring hindi ang nabigo.

Ang pagtukoy ng NAT ay ibang yugto

Ang pagtukoy ng NAT ay nagtatanong kung paano muling isinusulat ang mga packet, hindi kung sino ang peer. Ang customer gateway sa likod ng NAT ay nagpapatunay pa rin nang tama kapag ang naka-configure na pagkakakilanlan ay ang inaasahan ng peer, at ang problema sa NAT ay lumalabas bilang hindi pagtutugma ng proposal o port, hindi bilang bigong paghahambing ng pagpapatunay.

Huwag dalhin ang lumang pahayag tungkol sa isang release ng vendor sa kasalukuyang deployment. Ang kailangan ng pagdaan sa NAT sa iyong release ay nasa sariling dokumentasyon nito, at ang pariralang hindi pagtutugma ng MAC ay hindi ebidensya pabor man o laban.

Magpasya batay sa pares, hindi sa screen

Basahin ang dalawang configuration nang magkatabi na nakatago ang sikreto, pagkatapos magtanong ng tatlo. Ang pagkakakilanlan sa bawat panig ba ay eksaktong inaasahan ng kabila, karakter sa karakter? Gumagamit ba ang dalawang dulo ng parehong bersyon ng IKE at parehong paraan ng pagpapatunay? Tumutugma ba ang bumabagsak na tunnel sa configuration na binabasa mo? Ang hindi sa alinman sa mga ito ay nagpapasya sa pag-aayos nang hindi hinahawakan ang sikreto.

Kung malinis ang tatlo, palitan ang sikreto sa pamamagitan ng aprubadong workflow sa halip na iikot ito sa pag-edit.

Pagkatapos magpatunay ng peer

Kapag nagtagumpay ang pagpapatunay, ang susunod na surface ng kabiguan ay ang child security association: mga proposal at traffic selector. Ang pag-ikot ng sikretong tinanggap na ay hindi makapag-aayos ng kabiguan ng child at pinapahaba ang pagkawala ng serbisyo. Basahin ang estado ng child, pagkatapos ang mga selector at protektadong saklaw sa dalawang panig, at itugma ang gabay sa pag-troubleshoot ng Cloud VPN sa yugtong talagang nabigo.

I-ugnay ang sariwang log mula sa dalawang dulo para sa parehong pares at parehong window. Ang isang panig lamang ay nagbibigay ng hatol nang walang input ng kabila, at iyon ang kalabuan na lumikha ng mensahe noong una.

Ano ang hindi dapat tapusin

Huwag basahin ang mensahe bilang hiling na baguhin ang mga MAC address, at huwag ilathala ang pinagsamang sikreto habang humihingi ng tulong; ang sipi na naglalaman ng susi ay kailangang alisin ang susi, hindi panatilihin ang log. Huwag ding ipalagay ang sira sa routing, dahil ang mga peer na hindi maabot ang isa't isa ay walang naisasagawang paghahambing ng pagpapatunay. At huwag gawing pangkalahatan ang dokumentadong limitasyon ng isang pamilya ng produkto sa bawat implementasyon ng IPsec.

Itala ang bumabagsak na pares, ang estado ng tunnel bago at pagkatapos, at alin sa dalawang kondisyon ang binago mo. Ang talaang iyon ay gagawing limang minutong pagsusuri ang susunod na pangyayari.