Несъответствие на MAC в IKE означава, че проверката на споделения ключ е неуспешна
В лог на IKEv2 с предварително споделен ключ MAC е код за удостоверяване на съобщението. Какво сравнява проверката и двете конфигурационни грешки, които всъщност я причиняват.
Вашият лог на Cloud VPN показва опит за споделен ключ, последван от MAC mismatched, и първият инстинкт често е да се търси проблем с адреса. В този клон MAC е код за удостоверяване на съобщението: стойност, изчислена върху обмена с договорения ключ. Партньорът сравни собственото си изчисление с получената стойност и те се различаваха. Тук не участва мрежова карта и нито една настройка на интерфейса не променя това сравнение.
На практика го предизвикват две условия: тайните от двете страни не са една и съща стойност или идентичностите, използвани за избор на тайната, не съвпадат. Решете кое от двете е, като прочетете двойката, а не единичния тунел.
Какво доказва етапът
Проверката се изпълнява, след като двете страни са разменили началните параметри и са се представили. Тя избира кандидат-споделени ключове за локалната и отдалечената идентичност и се опитва да валидира получените данни за удостоверяване; когато никой не се валидира, се издава диагностиката. Това е силно твърдение за удостоверяването и слабо за причината, защото не казва коя страна е сгрешила.
Предишният успех не се пренася в тази проверка. Завършен IKE_SA_INIT или полезен товар за откриване на NAT, върнал очакваните стойности, доказва, че партньорите могат да говорят. Той не доказва нищо за това дали споделят тайна.
Две конфигурационни грешки, едно съобщение
Първата е истинско несъответствие на тайната и обикновено е инцидент при предоставяне: генерирана стойност, инсталирана на една конзола и превъведена на другата, остатъчен знак, оцелял от едната страна, или кавичка, дошла с поставянето. Втората е несъответствие на идентичността, при което тайната е правилна, но идентичността, която партньорът представя, избира различен запис, така че правилната тайна никога не се опитва. И двете дават един и същ ред, затова гаденето струва един следобед.
Сравнете двойката, преди да пипате която и да е тайна. Съпоставете тунела, крайната точка на партньора, времевия прозорец и отдалечената конфигурация, защото два резервни тунела могат да държат различни тайни и екранът пред вас може да не е този, който се е провалил.
Откриването на NAT е различен етап
Откриването на NAT пита как се пренаписват пакетите, а не кой е партньорът. Клиентският шлюз зад NAT все още се удостоверява правилно, когато конфигурираната му идентичност е тази, която партньорът очаква, а проблемът с NAT се проявява като несъответствие на предложението или порта, а не като неуспешно сравнение за удостоверяване.
Не пренасяйте старо твърдение за един доставчик в текущо разгръщане. Изискванията за преминаване през NAT във вашата версия принадлежат на собствената ѝ документация, а фразата MAC mismatch не е доказателство за или против.
Решавайте от двойката, не от екрана
Прочетете двете конфигурации една до друга със заличена тайна, после задайте три въпроса. Идентичността от всяка страна точно ли е това, което другата очаква, знак по знак? Използват ли двете страни една и съща версия на IKE и един и същ метод за удостоверяване? Съответства ли провалилият се тунел на конфигурацията, която четете? „Не“ на който и да е от тях определя поправката, без да се пипа тайната.
Ако и трите са чисти, сменете тайната чрез одобрения работен процес, вместо да редактирате около нея.
След като партньорът се удостовери
Щом удостоверяването успее, следващата повърхност на отказ е дъщерната асоциация за сигурност: предложения и селектори за трафик. Ротирането на вече приета тайна не може да поправи дъщерен отказ и удължава прекъсването. Прочетете състоянието на дъщерната асоциация, после селекторите и защитените диапазони от двете страни и съпоставете ръководството Отстраняване на проблеми с Cloud VPN с етапа, който всъщност се е провалил.
Свържете свежи логове от двата края за същата двойка и същия прозорец. Едната страна сама дава присъда без входа на другата, а това е двусмислието, което първоначално е създало съобщението.
Какво да не заключаваме
Не четете съобщението като искане да смените MAC адреси и не публикувайте споделената тайна, докато искате помощ; откъс, съдържащ ключа, трябва да има премахнат ключ, а не запазен лог. Не предполагайте и проблем с маршрутизацията, защото партньори, които не могат да се достигнат, изобщо не създават сравнение за удостоверяване. И не обобщавайте документирано ограничение от едно продуктово семейство към всяка IPsec реализация.
Запишете провалилата се двойка, състоянието на тунела преди и след и кое от двете условия сте променили. Този запис превръща следващия случай в петминутна проверка.