Розбіжність MAC в IKE означає, що перевірка спільного ключа не пройшла

У журналі Cloud VPN видно спробу зі спільним ключем, за якою йде повідомлення про розбіжність MAC, і перший інстинкт часто — шукати проблему з адресою. У цій гілці MAC — це код автентифікації повідомлення: значення, обчислене над обміном з узгодженим ключем. Пір порівняв власне обчислення з отриманим значенням, і вони різнилися. Мережева карта тут ні до чого, і жодне налаштування інтерфейсу не змінює цього порівняння.

На практиці це дають дві умови: секрети на двох кінцях не однакові, або ідентичності, за якими вибирається секрет, не відповідають одна одній. Визначте, яка саме, читаючи пару, а не окремий тунель.

Що доводить цей етап

Перевірка виконується після того, як обидві сторони обмінялися початковими параметрами й представилися. Вона вибирає ключі-кандидати для локальної та віддаленої ідентичностей і намагається перевірити отримані дані автентифікації; якщо жоден не проходить, видається діагностика. Це сильне твердження про автентифікацію й слабке твердження про причину, бо воно не каже, яка сторона помиляється.

Попередній успіх на цю перевірку не переноситься. Завершений IKE_SA_INIT або корисне навантаження виявлення NAT, що повернуло очікувані значення, доводить, що піри можуть спілкуватися. Це нічого не доводить про те, чи поділяють вони секрет.

Дві помилки конфігурації, одне повідомлення

Перша — справжня розбіжність секретів, і зазвичай це випадковість під час підготовки: згенероване значення встановили на одній консолі й набрали заново на іншій, зайвий символ залишився з одного боку або лапка потрапила під час вставлення. Друга — розбіжність ідентичностей, коли секрет правильний, але ідентичність, яку пред’являє пір, вибирає інший запис, тому потрібний секрет так і не перевіряється. Обидві дають один рядок, і саме тому здогадки коштують півдня.

Порівняйте пару, перш ніж торкатися будь-якого із секретів. Зіставте тунель, кінцеву точку піра, часове вікно й віддалену конфігурацію, бо два резервні тунелі можуть мати різні секрети, а екран перед вами може бути не тим, що відмовив.

Виявлення NAT — це інший етап

Виявлення NAT питає, як переписуються пакети, а не хто такий пір. Клієнтський шлюз за NAT усе одно автентифікується правильно, коли налаштована ідентичність збігається з очікуваною в піра, а проблема NAT виявляється як розбіжність пропозиції або порту, а не як невдале порівняння автентифікації.

Не переносьте старе твердження про версію одного постачальника в поточне розгортання. Те, що вимагає проходження через NAT у вашій версії, належить до її власної документації, а фраза «розбіжність MAC» не є доказом ні за, ні проти.

Вирішуйте за парою, а не за екраном

Прочитайте обидві конфігурації поруч, приховавши секрет, і поставте три питання. Чи ідентичність на кожній стороні точно така, якої очікує інша, символ у символ? Чи використовують обидва кінці ту саму версію IKE і той самий метод автентифікації? Чи відповідає тунель, що відмовляє, тій конфігурації, яку ви читаєте? Відповідь «ні» на будь-яке з них визначає ремонт без дотику до секрету.

Якщо всі три чисті, замініть секрет через затверджений процес, а не обходьте його редагуванням.

Після автентифікації піра

Щойно автентифікація проходить, наступна поверхня відмови — дочірня асоціація безпеки: пропозиції та селектори трафіку. Ротація вже прийнятого секрету не виправить збій дочірньої асоціації та подовжить простій. Прочитайте стан дочірньої асоціації, потім селектори й захищені діапазони з обох боків і зіставте настанови з усунення несправностей Cloud VPN з етапом, який справді відмовив.

Зіставте свіжі журнали з обох кінців для тієї самої пари й того самого вікна. Одна сторона дає вердикт без даних іншої, і це саме та неоднозначність, з якої повідомлення й постало.

Чого з цього не випливає

Не читайте повідомлення як вимогу змінити MAC-адреси й не публікуйте спільний секрет, коли просите допомоги; з фрагмента, що містить ключ, треба прибрати ключ, а не зберегти журнал. Не припускайте й помилки маршрутизації, бо піри, які не дістають один одного, взагалі не дають порівняння автентифікації. І не переносьте задокументоване обмеження одного сімейства продуктів на будь-яку реалізацію IPsec.

Запишіть пару, що відмовила, стан тунелю до і після та яку з двох умов ви змінили. Такий запис перетворює наступний випадок на п’ятихвилинну перевірку.