Несовпадение MAC в IKE означает, что проверка общего ключа не прошла

В журнале Cloud VPN видно попытку с общим ключом, за которой следует сообщение о несовпадении MAC, и первая мысль часто — искать проблему с адресом. В этой ветке MAC — это код аутентификации сообщения: значение, вычисленное по обмену с согласованным ключом. Пир сравнил собственное вычисление с полученным значением, и они разошлись. Сетевая карта здесь ни при чём, и никакая настройка интерфейса это сравнение не меняет.

На практике это дают два условия: секреты на двух концах не одинаковы, либо идентификаторы, по которым выбирается секрет, не соответствуют друг другу. Определите, какое именно, читая пару, а не отдельный туннель.

Что доказывает этот этап

Проверка выполняется после того, как обе стороны обменялись начальными параметрами и представились. Она выбирает ключи-кандидаты для локального и удалённого идентификаторов и пытается проверить полученные данные аутентификации; если ни один не проходит, выдаётся диагностика. Это сильное утверждение об аутентификации и слабое утверждение о причине, потому что оно не говорит, какая сторона неправа.

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

Две ошибки конфигурации, одно сообщение

Первая — реальное несовпадение секретов, и обычно это случайность при подготовке: сгенерированное значение установили на одной консоли и набрали заново на другой, лишний символ остался с одной стороны или кавычка попала при вставке. Вторая — несовпадение идентификаторов, когда секрет верен, но идентификатор, который предъявляет пир, выбирает другую запись, поэтому нужный секрет так и не проверяется. Оба дают одну и ту же строку, и поэтому догадки стоят потраченного дня.

Сравните пару, прежде чем трогать любой из секретов. Сопоставьте туннель, конечную точку пира, временное окно и удалённую конфигурацию, потому что два резервных туннеля могут хранить разные секреты, а экран перед вами может быть не тем, что отказал.

Обнаружение NAT — это другой этап

Обнаружение NAT спрашивает, как переписываются пакеты, а не кто такой пир. Клиентский шлюз за NAT по-прежнему аутентифицируется правильно, когда настроенный идентификатор совпадает с ожидаемым у пира, а проблема NAT проявляется как несовпадение предложения или порта, а не как неудачное сравнение аутентификации.

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

Решайте по паре, а не по экрану

Прочитайте обе конфигурации рядом, скрыв секрет, и задайте три вопроса. Идентификатор на каждой стороне точно такой, какой ожидает другая, символ в символ? Используют ли оба конца одну версию IKE и один метод аутентификации? Соответствует ли отказавший туннель той конфигурации, которую вы читаете? Ответ «нет» на любой из них определяет ремонт без прикосновения к секрету.

Если все три чисты, замените секрет через утверждённый процесс, а не обходите его правкой.

После аутентификации пира

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

Сопоставьте свежие журналы с обоих концов для той же пары и того же окна. Одна сторона даёт вердикт без данных другой, и это как раз та неоднозначность, из которой сообщение и возникло.

Чего из этого не следует

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

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