Когда IKEv2 возвращает TS_UNACCEPTABLE, сравните реальные подсети

Читайте TS_UNACCEPTABLE как несогласие по покрытию, а не как повреждённый профиль. Шлюз говорит, что две стороны не смогли договориться, какие адреса может нести этот туннель. IKE SA к этому моменту может быть уже поднята, поэтому клиент может выглядеть подключённым без дочерней SA за ним. Если сформулировать так, работа становится механической. Запишите задуманные префиксы обеих сторон, сравните их в одном направлении и сужайте, пока они не пересекутся.

Сначала запишите задуманные пары

Прежде чем трогать конфигурацию, перечислите четыре значения: диапазон источника инициатора, его диапазон назначения и ту же пару с точки зрения ответчика. Запишите также семейство адресов каждого из них. Диапазон IPv4 и диапазон IPv6 — разные типы селекторов, и ни один нельзя свернуть в полезную нагрузку другого.

Добавьте любое ограничение протокола или порта, которое несёт политика. Правило, разрешающее только TCP 445 к файловому серверу, описывает более узкое множество, чем подсеть, в которой оно находится. Если оставить это вне заметок, результат переговоров покажется несогласованным по причинам, которых вы не видите.

Поменяйте метки местами до сравнения

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

Ответчик может сузить предложение до приемлемого подмножества вместо того, чтобы отклонить его. Такой исход хуже чистого провала, потому что работает наполовину. Запросите 10.0.0.0/16, когда политика разрешает 10.0.5.0/24, и вы можете получить дочернюю SA, покрывающую только эту /24. Отвечает один хост, всё остальное остаётся снаружи, и ничто в клиенте об этом не говорит. Читайте принятые селекторы, а не запрошенные, прежде чем заключить, что переговоры удались.

Профили road warrior, запрашивающие маршрут по умолчанию, попадают сюда постоянно. Шлюз, построенный для разделённого доступа, сужает предложение полного диапазона до своих подсетей, и клиент должен принять суженный результат или громко провалиться.

Читайте отказ из одной попытки

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

Затем проверьте, что действительно установлено. swanctl --list-sas показывает селекторы дочерней SA, а ip xfrm policy показывает те же диапазоны как записи политики ядра. Дочерняя SA в этом списке с селекторами, которых вы не задумывали, — это событие сужения; отсутствие дочерней SA и TS_UNACCEPTABLE в журнале — это отказ.

Пока вы там, отделите близких соседей. INVALID_SELECTORS жалуется на селектор внутри установленной дочерней SA, тогда как INTERNAL_ADDRESS_FAILURE означает, что ответчик не смог выделить виртуальный адрес, а это проблема пула, а не покрытия.

Проверьте, что тихо уменьшает множество

Три вещи уменьшают множество селекторов, ничего не говоря. Политика ответчика — первая: списки подсетей, групповые правила или авторизация по пользователю сводят предложение к подмножеству. Семейство адресов — вторая: клиент с двумя стеками часто предлагает IPv6 рядом с IPv4 и получает отказ для диапазонов, которые шлюз никогда не настраивал.

Ограничения протокола и порта — третья. Там, где политика разрешает только TCP 445, дочерняя SA может подняться, тогда как ICMP и UDP остаются вне её, и пользователь сообщает о сломанном туннеле, хотя разрешён был всего один протокол.

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

Докажите покрытие подходящим трафиком

После установки дочерней SA отправьте один запрос, который точно попадает внутрь принятых диапазонов. Смотрите на счётчики, а не на значок состояния: ip -s xfrm state и счётчики за ip xfrm policy растут, когда пакет сопоставляется и защищается. Число байтов, которое после реального трафика остаётся нулевым, означает, что ядро так и не выбрало эту политику.

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

Завершите, записав принятую пару в заявку, рядом с диапазоном, который запрашивали изначально. Держите выбор таким же узким, как требование, потому что устранение ошибки заменой частного диапазона всеми адресами даёт гораздо больше доступа, чем было одобрено для учётной записи.