Почему политика безопасности IPsec — не запись в таблице маршрутизации

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

Начните с поиска, а не с таблицы

Спросите ядро, что оно действительно сделает: ip route get 10.20.0.5 печатает выбранный маршрут, исходящий интерфейс и адрес источника, который будет использован. Префикс, правило политики, метка или предпочтительный источник могут изменить этот ответ, поэтому живой поиск лучше чтения таблицы на глаз.

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

Согласуйте селекторы с обеих сторон

База данных политики имеет собственные записи, и каждая называет направление, источник, назначение и протокол, а затем указывает, что делать с подходящими пакетами. Используйте ip xfrm policy, чтобы их перечислить; флаги показывают, что действие — защита, обход или блокировка. Политика, чьи селекторы шире или уже вашего тестового потока, с ним не совпадёт, и пакет уйдёт незащищённым. Это и есть та неисправность, которую вы ищете, а не отсутствующий маршрут.

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

Совпадение с политикой — не установленное состояние

Совпадающая политика лишь говорит, что пакет должен быть защищён; ядру всё ещё нужна ассоциация безопасности, чтобы выполнить защиту. Перечислите их с помощью ip xfrm state, или с помощью swanctl --list-sas, когда переговоры ведёт strongSwan, и прочитайте селекторы и счётчики в каждой записи.

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

Что по-прежнему требует туннель на основе маршрута

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

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

Определите владельца, прежде чем что-то править

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

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