Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

SINGLE_PAIR_REQUIRED Сетевое оборудование и VPN

IPsec Error SINGLE_PAIR_REQUIRED: сбой сужения селекторов трафика (Narrowing)

Обновлено: 24.08.2026 · Официальная документация ↗

При согласовании туннеля IKEv2 между различными вендорами происходит сбой:

  • В логах фиксируется ошибка: IPsec Error: SINGLE_PAIR_REQUIRED: Narrowing of traffic selectors failed или received SINGLE_PAIR_REQUIRED notify error.
  • Удаленный пир отказывается принимать список из нескольких подсетей внутри одного обмена CREATE_CHILD_SA.
  • Фаза 1 завершается штатно, но Фаза 2 мгновенно переходит в статус FAILED.

1. Специфика ошибки SINGLE_PAIR_REQUIRED (RFC 7296 Section 2.24)

Некоторые реализации IPsec (например, старые версии Cisco IOS, Juniper ScreenOS или прошивки со строгим аппаратным ASIC-ускорением) не поддерживают мульти-селекторы (множество подсетей в одном Child SA). Когда инициатор отправляет список из нескольких подсетей, ответчик возвращает уведомление SINGLE_PAIR_REQUIRED (Notify 34), требуя пересогласовать SA, содержащую строго одну пару: один IP-диапазон источника и один IP-диапазон назначения.

2. Диагностика входящего отказа

# strongSwan log output
[IKE] received SINGLE_PAIR_REQUIRED notify, peer requires individual Child SAs
[IKE] establishing Child SA failed

3. Исправление конфигурации в strongSwan

Разделите комплексный список подсетей на отдельные независимые дочерние секции children.

Неправильная конфигурация (вызывает сбой):

# Одна секция с несколькими подсетями
children {
    all-subnets {
        local_ts  = 10.10.1.0/24, 10.10.2.0/24
        remote_ts = 192.168.1.0/24, 192.168.2.0/24
    }
}

Правильная конфигурация (индивидуальные пары):

children {
    net-1-to-1 {
        local_ts  = 10.10.1.0/24
        remote_ts = 192.168.1.0/24
    }
    net-2-to-2 {
        local_ts  = 10.10.2.0/24
        remote_ts = 192.168.2.0/24
    }
}

4. Включение поддержки Narrowing на ответчике

Если вы управляете ответчиком, разрешите ему самостоятельно сужать селектор до первой подходящей пары вместо отправки ошибки:

# swanctl.conf
connections {
    peer-conn {
        children {
            sa-name {
                # Активация автосужения
                narrowing = yes
            }
        }
    }
}

5. Перезапуск демона и повторная инициализация

swanctl --load-all
swanctl --initiate --child net-1-to-1
swanctl --initiate --child net-2-to-2
💡 Практика специалистов: Если вы настраиваете VPN с облаком AWS (Virtual Private Gateway) или Azure VPN Gateway в режиме Policy-Based, они жестко требуют ровно одну пару селекторов на SA. Всегда объявляйте подсети отдельными дочерними блоками.

Частые вопросы (FAQ)

Почему шлюз требует SINGLE_PAIR_REQUIRED?

Многие аппаратные криптопроцессоры (ASIC/FPGA) в маршрутизаторах архитектурно привязаны к модели 'одна пара политик на один SPI безопасности'. Они не умеют сопоставлять сложные списки подсетей с одним ключом шифрования.

Увеличивает ли разделение подсетей на разные Child SA нагрузку на CPU?

Нагрузка возрастает незначительно. Каждая пара создает свою собственную запись Security Association (SA) в ядре, требуя отдельного процесса Rekeying, но объем передаваемого трафика шифруется с той же производительностью.

Поддерживает ли IKEv1 уведомление SINGLE_PAIR_REQUIRED?

Нет, это специфичное для протокола IKEv2 уведомление, так как в IKEv1 мульти-селекторы не поддерживались архитектурно изначально.

Как влияет параметр mode = tunnel на single pair?

В туннельном режиме каждое правило маршрутизации трафика привязывается к своей паре TSi/TSr. Разделение на единичные пары гарантирует корректную работу таблицы политик XFRM в ядре.

Полезные материалы
Рекомендуем