Мітки nftables і маршрутизація VPN: яке правило справді перемагає

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

Перевірка 1: прочитайте правило, якому відповідає ядро

Почніть із правила політики, а не з міжмережевого екрана. Ядро переглядає правила в порядку пріоритету, і перший збіг визначає таблицю. Прочитайте значення fwmark і маску з самого правила, потім переконайтеся, що пакет із заданою вами міткою справді йому відповідає. Правило, яке очікує повне 32-бітне значення, не збіжиться з пакетом, що несе лише один біт.

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

Це вирішують дві команди: список правил і пошук маршруту до призначення в цій таблиці.

Перевірка 2: мітка пакета чи мітка з’єднання

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

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

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

Перевірка 3: хто ще пише цю мітку

Власні засоби WireGuard позначають свої UDP-пакети, щоб зашифрований транспорт не спрямовувався назад у тунель, якому він належить. Якщо ваш набір правил призначає тому самому полю стороннє значення, це виключення зникає, і зовнішній трафік тунелю намагається увійти в себе. Симптом — тунель, який встановлюється і потім перестає пропускати трафік.

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

Перелічіть записувачів, перш ніж додавати ще одного.

Перевірка 4: маска вирішує, що ви зберігаєте

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

Задокументуйте розподіл бітів поруч із набором правил.

Інакше наступна людина повторно використає значення, у якого вже є власник, і конфлікт тут виглядає як помилка маршрутизації, хоча насправді це помилка адресації. Документація nftables про метадані пакетів описує самі операції з мітками.

Перевірка 5: перевіряйте реальним потоком, а не пошуком

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

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

Запишіть мітку, маску й таблицю в одному місці, і наступне редагування стане перевірюваним.