Входящий IPsec-пир не подходит ни к одному профилю? Проверьте четыре поля

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

Начните с пакета, а не с файла

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

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

Первая группа полей: определение, которое действительно загружено

Проверьте работающее состояние инструментом, которому принадлежит демон: командой состояния, перечисляющей загруженные подключения, а не буфером редактора. Убедитесь, что ожидаемая запись присутствует, включена для нужного вам поведения при запуске и была загружена после вашей последней правки. Сохранённый, но не перезагруженный файл — самая частая причина фразы «я исправил, и ничего не изменилось».

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

Вторая группа полей: конечные точки — это не идентичности

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

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

Запишите ожидаемую идентичность обеих сторон и удостоверение, которое её проверяет. Если эти две строки расходятся, никакая подгонка адресов не даст совпадения.

Третья группа полей: защищаемый трафик

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

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

Четвёртая группа полей: вы читаете одну реализацию

У Libreswan, старого Openswan и strongSwan разные инструменты управления, разный синтаксис конфигурации и разный порядок сопоставления. Работающий пример одного ничего точного не говорит о приоритете выбора профиля или формулировках ошибок другого, поэтому проверяйте по документации демона на этом хосте.

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

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