Архитектура взаимной аутентификации IKE и природа AUTHENTICATION_FAILED

После успешного завершения диффузного обмена Диффи-Хеллмана (IKE_SA_INIT) стороны переходят к фазе взаимной аутентификации IKE_AUTH (в IKEv1 — Phase 1 Aggressive/Main Mode auth step). При использовании аутентификации по общему предварительному ключу (Pre-Shared Key, PSK) обе стороны независимо вычисляют криптографический хеш блока данных (AUTH Payload), включающий в себя значение общего секрета PSK, идентификаторы сторон (IDi/IDr) и одноразовые случайные числа (Nonces). Если вычисленный ответчиком хеш не совпадает с хешем инициатора, отправляется уведомление IKE_NOTIFY: AUTHENTICATION_FAILED (код 24), и туннель немедленно разрывается.

Бизнес-риски

Невозможность поднятия туннелей филиальной сети, ложные подозрения на аппаратный сбой оборудования, блокировка удаленных пользователей при смене паролей.

Типовые причины сбоя AUTHENTICATION_FAILED

Пошаговый регламент устранения ошибки AUTHENTICATION_FAILED

Сценарий 1: Проверка и сброс общего ключа PSK на обоих шлюзах

Для исключения ошибок кодировок используйте надежные алфавитно-цифровые ключи длиной от 32 до 64 символов (только символы A-Z, a-z, 0-9):

# Генерация стойкого PSK-ключа в Linux консоли
openssl rand -base64 32
# Пример вывода: 4vK9mZ8xL2wQp0rT5yU8vB1nM4kP7sJ9xR2tF5vW8yM=

# Назначение идентичного секрета в MikroTik RouterOS v7
/ip ipsec identity set [find peer="PEER_SITE_B"] secret="4vK9mZ8xL2wQp0rT5yU8vB1nM4kP7sJ9xR2tF5vW8yM="

Сценарий 2: Синхронизация идентификаторов IKE Identity (Local / Remote ID)

Если один из шлюзов находится за NAT, шлюзы обязаны явно сопоставлять идентификаторы (FQDN, Email или Key ID):

# Конфигурация Identity на MikroTik за NAT
/ip ipsec identity add peer="PEER_HQ" auth-method=pre-shared-key \
    secret="ComplexSecretKey123" \
    my-id=fqdn:branch.company.com \
    remote-id=fqdn:hq.company.com

# Конфигурация strongSwan на стороне штаб-квартиры (HQ)
connections {
   branch-vpn {
      local {
         id = hq.company.com
      }
      remote {
         id = branch.company.com
         auth = psk
         secret = "ComplexSecretKey123"
      }
   }
}

Сценарий 3: Анализ логов отклонения аутентификации

# Проверка логов IPsec в Linux strongSwan
sudo journalctl -u strongswan -e | grep -E "AUTH|AUTHENTICATION_FAILED"
# Типичный вывод при неверном пароле:
# [IKE] verification of AUTH payload with signature failed
# [IKE] sending AUTHENTICATION_FAILED notify

Типовые ошибки администраторов

• Копирование пароля с пробелом на конце: Копирование ключа мышью из мессенджера или текстового редактора часто захватывает знак переноса строки \n или пробел.
• Использование кириллических символов в PSK: Разные операционные системы (Windows/Linux/Cisco IOS) используют разные кодовые страницы (CP1251 vs UTF-8), что делает байтовое представление пароля абсолютно разным.