Как работает IPsec на основе маршрутов с интерфейсом XFRM

IPsec на основе маршрутов передаёт таблице маршрутизации решение, которое раньше принимали селекторы политики. В Linux той частью, которая это позволяет, является интерфейс XFRM: виртуальное устройство, чей трафик сопоставляется с состоянием IPsec по идентификатору интерфейса, а не по селектору. Создание одного требует одной команды и ничего не доказывает о существовании туннеля. Устройство — это крючок между маршрутизацией и политикой безопасности, и обе стороны этого крючка должны быть настроены, прежде чем что-то будет защищено.

Что такое устройство и чем оно не является

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

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

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

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

Начните с внешнего устройства и числа, которое вы также укажете в конфигурации демона. В примере внешним интерфейсом служит eth0, а идентификатором — 42, эти адреса следует заменить своими.

Поднимите устройство, затем подтвердите идентификатор, записанный ядром, прежде чем трогать конфигурацию VPN:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

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

Держите IKE и ESP вне маршрута туннеля

Маршрут по умолчанию, указывающий в устройство XFRM, перехватывает инкапсулированные пакеты и трафик, который они несут. Результат — петля: шлюз пытается отправить свой ESP через туннель, который ESP должен построить.

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

Что бы вы ни выбрали, проверьте, что внешний пакет выходит неинкапсулированным. Быстрая проверка — пинг внешнего адреса партнёра после поднятия туннеля; если это не удаётся, пока интерфейс поднят, подозревайте перехват, а не доступность. То же рассуждение относится к порту IKE, потому что собственный UDP-трафик демона не должен маршрутизироваться в устройство, которое он пытается установить.

Проверьте счётчики в двух местах, прежде чем винить шифрование

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

Прочитайте оба, затем прочитайте взгляд демона на дочернюю ассоциацию:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

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

Решите, кто устанавливает маршруты

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

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

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