Порожня таблиця 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 окремо і тримайте схвалені винятки для кінцевих точок явними, а не уявними.