Неслагање MAC у IKE значи да провера заједничког кључа није успела

Дневник Cloud VPN-а приказује покушај са заједничким кључем након кога следи порука да се MAC не слаже, а први нагон је често тражење проблема са адресом. У овој грани MAC је код за аутентификацију поруке: вредност израчуната над разменом са договореним кључем. Пар је упоредио сопствено израчунавање са примљеном вредношћу, и оне су се разликовале. Ниједна мрежна картица није укључена, и ниједно подешавање интерфејса не мења то поређење.

У пракси то производе два услова: тајне на два краја нису иста вредност или идентитети којима се тајна бира не одговарају један другом. Одредите који тако што ћете прочитати пар, а не појединачни тунел.

Шта ова фаза доказује

Провера се извршава након што су обе стране размениле почетне параметре и представиле се. Она бира кандидате за кључеве за локални и удаљени идентитет и покушава да валидира примљене податке за аутентификацију; када ниједан не прође, дијагностика се исписује. То је јака изјава о аутентификацији и слаба изјава о узроку, јер не каже која је страна погрешна.

Ранији успех се не преноси на ову проверу. Завршен IKE_SA_INIT, или NAT корисни терет за откривање који је вратио очекиване вредности, доказује да парови могу да разговарају. То ништа не доказује о томе да ли деле тајну.

Две конфигурационе грешке, једна порука

Прва је стварно неслагање тајни, и обично је несрећа при припреми: генерисана вредност инсталирана на једној конзоли и поново откуцана на другој, знак на крају који је преживео на једној страни или наводник који је дошао с налепљивањем. Друга је неслагање идентитета, где је тајна исправна, али идентитет који пар представља бира други унос, па се исправна тајна никада не покушава. Обе дају исти ред, и зато нагађање кошта поподне.

Упоредите пар пре него што дотакнете било коју тајну. Ускладите тунел, крајњу тачку пара, временски прозор и удаљену конфигурацију, јер два резервна тунела могу да имају различите тајне, а екран пред вама можда није онај који је отказао.

NAT откривање је друга фаза

NAT откривање пита како се пакети преписују, а не ко је пар. Клијентски гејтвеј иза NAT-а и даље се исправно аутентификује када је конфигурисани идентитет онај који пар очекује, а NAT проблем се показује као неслагање предлога или порта, а не као неуспело поређење аутентификације.

Не преносите стару тврдњу о једној верзији добављача у актуелно увођење. Оно што NAT пролазак захтева у вашој верзији припада њеној сопственој документацији, а фраза неслагање MAC није доказ ни за ни против.

Одлучите по пару, а не по екрану

Прочитајте обе конфигурације једну поред друге са сакривеном тајном, па поставите три питања. Да ли је идентитет на свакој страни тачно оно што друга очекује, знак по знак? Да ли оба краја користе исту IKE верзију и исти метод аутентификације? Да ли тунел који отказује одговара конфигурацији коју читате? Не на било које од њих одређује поправку без дирања тајне.

Ако су сва три чиста, замените тајну кроз одобрени ток рада, уместо да га заобилазите изменама.

Након што се пар аутентификује

Када аутентификација успе, следећа површина отказа је подређена безбедносна асоцијација: предлози и селектори саобраћаја. Ротирање тајне која је већ прихваћена не може да поправи отказ подређене асоцијације и продужава прекид. Прочитајте стање подређене асоцијације, затим селекторе и заштићене опсеге са обе стране, и ускладите упутства за решавање проблема Cloud VPN-а са фазом која је заиста отказала.

Повежите свеже дневнике са оба краја за исти пар и исти прозор. Једна страна сама даје пресуду без доприноса друге, и то је управо нејасност која је изворно произвела поруку.

Шта не треба закључити

Не читајте поруку као захтев да се промене MAC адресе, и не објављујте заједничку тајну када тражите помоћ; изломак који садржи кључ захтева да кључ буде уклоњен, а не да дневник буде сачуван. Не претпостављајте ни грешку рутирања, јер парови који не могу да се достигну уопште не дају поређење аутентификације. И не уопштавајте документовано ограничење једне породице производа на сваку IPsec имплементацију.

Забележите пар који је отказао, стање тунела пре и после и коју сте од две услове променили. Тај запис претвара следећу појаву у проверу од пет минута.