VPN между площадками на основе маршрутов и на основе политик: в чём разница

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

Два способа решить, что попадает в туннель

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

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

Читайте сравнение ниже как набор признаков отказа, а не как турнирную таблицу, потому что ни один столбец не побеждает сам по себе.

На основе политик: селектор — это договор

Селекторы согласуются, а не просто настраиваются. Предложите 10.10.0.0/16 с одной стороны и 10.10.1.0/24 с другой, и ассоциация покроет то, на чём остановились переговоры, а все остальные хосты останутся снаружи.

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

sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas

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

На основе маршрутов: интерфейс — это договор

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

Интерфейс не убирает необходимость в политике. Демон устанавливает правила для каждого интерфейса, привязанные к идентичности интерфейса, поэтому пакет, пришедший на неверный интерфейс, всё равно не проходит. Адрес источника, который партнёр не примет, тоже не проходит, даже при идеальном маршруте. На основе маршрутов означает, что маршрут решает вход, а не что политика исчезла.

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10

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

Где эти два проекта действительно расходятся

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

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

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

Переход без потери обратного пути

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

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

ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns

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