Политика IPsec поглощает ваш локальный трафик: как это распознать

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

Проследите поток, прежде чем менять селектор

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

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

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

Три вида локального, которые ведут себя по-разному

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

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

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

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

Читайте установленную политику, а не файл

Файлы конфигурации описывают намерение; ядро хранит политики, которые действительно совпадают. Покажите и то и другое и считайте расхождение первой находкой.

Эти команды показывают выбранный маршрут до пункта назначения и установленные политики в каждом направлении:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

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

Сузьте селектор или обойдите пункт назначения

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

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

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

Исключения, переживающие переустановку

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

Эти две проверки подтверждают, что исключение выжило, а защита нет:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Затем намеренно отключите и снова подключите туннель и повторите обе. Исключение, которое работает до переподключения и не работает после, было применено не на том уровне, и это самый частый способ возврата этой проблемы.