Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

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

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 в ядре.