Пустая таблица VPN сама по себе ничего не блокирует

Правило политики отправляет помеченные пакеты в отдельную таблицу, и обычное ожидание состоит в том, что потеря маршрута VPN их заблокирует. Механизм делает другое. Когда в таблице нет подходящего маршрута, поиск продолжается по следующему правилу вместо остановки, и таблица main по-прежнему содержит обычный маршрут по умолчанию для uplink. Результат — конфигурация, которая выглядит как fail-closed, а ведёт себя как fail-open.

Ничего не сломано; именно так определена маршрутизация на основе политик.

Поиск продолжается, когда в таблице ничего нет

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Возьмите этот набор правил: помеченный поиск идёт в таблицу 42, а следующее правило отправляет ту же метку в таблицу с именем default. Пока в таблице 42 есть пригодный маршрут по умолчанию, первый поиск даёт путь. Когда этот маршрут исчезает и больше ничего в таблице 42 не подходит, поиск не превращается в отбрасывание; обработка переходит к следующему правилу, а когда и оно ничего не находит, доходит до таблицы main. Ничто в этой последовательности не сообщает, какое правило дало окончательный ответ, поэтому работающее соединение выглядит как работающая политика.

Таблица 253, обычно называемая default, — это обычная таблица маршрутизации, и обычно она пуста. Её имя не является указанием отбрасывать пакеты и не совпадает с маршрутом назначения по умолчанию внутри таблицы.

Терминальные действия завершают поиск

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Терминальное правило может идти после поиска VPN вместо поиска в пустой таблице. С той же меткой действие prohibit, размещённое после правила таблицы 42, завершает поиск, когда эта таблица ничего не даёт, и возвращает административный отказ вместо того, чтобы дать таблице main ещё один шанс. Unreachable и blackhole тоже терминальны, с иным поведением ошибки для отправителя.

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

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

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

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

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

Два состояния отказа, а не одно

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

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

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