Одна служба хоста має відповідати інтернету через фізичний висхідний канал, поки все інше на машині продовжує використовувати тунель. Три умови вирішують, чи витримає маршрутизація на основі політик таке навантаження, і кожну з них дешево перевірити перед написанням правила. Служба має завершуватися на цьому хості, а не за DNAT чи перенаправленим портом, власні правила VPN мають дозволяти виняток, і зіставляти треба відповідь, а не запит. Якщо не виконується будь-яка з трьох, команди нижче завантажаться без помилок, але не зроблять нічого корисного.

Перевірте три умови, перш ніж писати правило

Контейнер, що публікує порт через DNAT, або сервер за перенаправленням порту створює пакети, які не виникають на цьому хості. Ці пакети пересилаються, тому правило, прив'язане до локального входу хоста, їх ніколи не бачить і трафік продовжує використовувати маршрут за замовчуванням. Підтвердьте, де служба насправді працює, перш ніж продовжити, бо саме в цій умові люди помиляються найчастіше.

Друга умова — політика, а не механіка. Будь-який маршрут в обхід тунелю є винятком із призначення тунелю, і на керованому хості це рішення належить власникові політики, а не людині, яка налагоджує тайм-аут.

Зіставляйте відповідь, а не порт призначення клієнта

Відповідь сервера, що слухає TCP 443, залишає хост із портом джерела 443. Браузер на тому самому хості, підключаючись до віддаленого сайту HTTPS, надсилає ефемерний порт джерела й порт призначення 443. І те, і те — трафік порту 443, і лише один із них має використовувати таблицю WAN, тому зіставлення за портом призначення захопило б не ту половину.

Напрямок відповіді — це те, що можна розрізнити. Зіставте порт джерела, обмежте правило локально створеними пакетами, і правило охопить власні відповіді служби, не торкаючись запитів браузера.

Побудуйте повну таблицю повернення, перш ніж правило на неї вкаже

Порожня таблиця означає відсутність маршруту, що виглядає як зламана служба, а не зламана політика. Спершу заповніть її, з номером таблиці й пріоритетом, які більше ніщо на хості не займає:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Зчитуйте номери з живого хоста, а не копіюйте їх. ip -4 rule show показує, які пріоритети зайняті, а додавання правила на наявний пріоритет тихо змінює порядок двох правил, які окремо виглядають правильно.

Справжню роботу тут виконують два селектори. iif lo — це спосіб, у який ядро повідомляє про пакети, створені самим хостом, тож правило не може випадково перехопити пересланий трафік, що надходить ззовні. ipproto tcp sport 443 звужує його до одного транспорту й одного порту, що так само вузько, як дозволяє вимога. Приберіть селектор протоколу, і правило захопить також UDP 443, а це інша служба з іншою поведінкою.

Тримайте приватні відповіді всередині тунелю

Якщо той самий слухач відповідає і клієнтам на приватному боці, маршрут WAN за замовчуванням, що перехоплює все в таблиці 100, спробує надіслати ці відповіді назад через висхідний канал. Додайте приватні префікси, які не повинні йти за WAN за замовчуванням, або дозвольте їм перейти до наступного правила політики:

ip -4 route add table 100 throw 10.90.0.0/24

Маршрут throw завершує пошук у цій таблиці й повертає пакет спискові правил, тому наступна політика VPN отримує свій шанс. Сам він нічого не спрямовує в тунель, і якщо жодне пізніше правило не має відповідного маршруту, пакет усе одно не проходить; перевірте наступну політику, а не вважайте throw виправленням.

Фільтрація зворотного шляху й правила брандмауера хоста досі застосовуються до запиту, що надходить. Подивіться на їхні реальні вердикти, перш ніж послаблювати перевірку, бо виняток маршрутизації не змушує rp_filter прийняти зворотний шлях, який він вважає неможливим.

Перевірте TCP, потім QUIC, потім перезавантаження

Відкрийте одне з'єднання з авторизованого зовнішнього клієнта й одне з приватного боку, потім дослідіть пошук відповіді з реальними адресами й портами. Якщо зовнішня відповідь потрапляє в таблицю 100, а приватна ні, політика робить те, що ви просили.

HTTP/3 обслуговується через UDP і не буде зіставлений правилом TCP, тож слухачеві QUIC потрібен власний селектор, інакше він продовжить використовувати тунель, поки HTTPS працює. Зберігайте правила, на яких ви зупинитеся, у компоненті, що володіє інтерфейсом, і підтверджуйте їх після повторного підключення або оновлення DHCP. Коли конкуруючий менеджер видаляє маршрут часу виконання після перезавантаження, це проблема володіння, яку треба вирішувати в джерелі, а не привід додавати зверху ширші правила NAT.

Схожі статті