Селекторы трафика IPsec: что они покрывают, а что нет

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

Читайте их с обоих концов

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

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

Запишите обе стороны в одну таблицу, прежде чем что-либо менять. Это упражнение обычно решает вопрос, не касаясь файла конфигурации.

Сужение — решение отвечающей стороны

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

Поэтому подсеть, добавленная на клиенте, может дать работающий туннель, который всё же отвергает новое назначение. Сервер сузил предложение до того, что допускает его политика, тогда как файл клиента всё ещё перечисляет более широкий диапазон. Только согласованное состояние показывает правду: в Linux ip xfrm policy и список child SA в документации strongSwan по IKEv2 сообщают, что установлено, а не что запрошено. Когда эти двое расходятся, менять нужно политику отвечающей стороны.

Отклонённое предложение — это другой симптом, чем суженное. Отказ появляется в журнале переговоров и вообще не оставляет связи child.

Проследите одно назначение от начала до конца

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

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

Запрос маршрута называет интерфейс и адрес источника, которые понесут пакет. Список политик показывает, существует ли подходящая туннельная политика для этой пары, включая её направление и уровень. Список SA показывает согласованные селекторы child вместе со счётчиками, поэтому связь child с нулём пакетов после попытки трафика — это подпись селекторов, исключающих то, что отправляется. Три команды, три разных ответа, и только одна из них объясняет тихое отбрасывание.

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

Держите две цели раздельно

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

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