Чому nftables не бачить трафік OpenVPN між клієнтами

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

Простежте один пакет через сервер

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

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

Тест лічильником, який вирішує, який шлях виконувався

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

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

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

Дві деталі запобігають хибному прочитанню. Ім'я інтерфейсу, записане в мітці ланцюга, саме собою нічого не фільтрує, бо зіставлення відбувається за полями інтерфейсу всередині правил. А мостове рішення 2-го рівня поводиться знову інакше: там клієнти поділяють один широкомовний домен, тому виявлення вузлів очікуване, а не дефект маршрутизації.

Комутатор — це не список доступу

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

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

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

Вибір точки пересилання

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

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

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

Що перевірити перед зміною правил

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

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