Что фиксировать в записи для межсайтового VPN: селекторы и охват

Через полгода после запуска туннеля новая подсеть перестаёт попадать под политику, а единственный документ на общем диске гласит «VPN офиса». Именно такой отказ и предотвращает запись о селекторах, и он конкретен: набор адресов изменился, а документация — нет. Правильно написать запись означает понимать, какой из нескольких наборов адресов вы описываете, и фиксировать тот, который действительно применяет вторая сторона, а не тот, который вы настроили.

Настроенный селектор — не согласованный

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

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

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

Туннели на основе маршрутов выбирают иначе

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

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

Трансляция относится в ту же таблицу

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

Вот та деталь, которая ломает работающий туннель после изменения NAT: селектор по-прежнему совпадает с исходным префиксом, вторая сторона теперь получает транслированный, а её обратный маршрут указывает на адрес, которого больше нет. Ничто не пишет ошибку в тот момент, когда они перестают совпадать.

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

Приложите требование к сервису

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

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

Превратите запись в план тестирования

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

swanctl --list-sas

Пятистрочного скелета обычно достаточно, чтобы запись оставалась честной. Версия ниже помещается в тикет на изменение без обрезки:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Пинг только до шлюза — не приёмочный тест. Он никогда не задействует транзитный путь, поэтому может проходить, пока каждый пересылаемый поток отказывает. Тестируйте с хоста на одной стороне к сервису на другой и подтвердите, что ответ приходит через туннель. Если проходит только пинг, значит запись только что нашла ту самую проблему с пересылкой, которую должна была предотвратить. Документация strongSwan о пересылке объясняет, как селекторы, маршруты и пересылка взаимодействуют на узле Linux.