Ім'я ланцюга — не гак: iptables проти nftables

Обидва міжмережеві екрани можуть фільтрувати пересиланий трафік VPN, і вони прикріплюють правила до шляху пакета по-різному. У iptables вбудовані ланцюги містяться в таблиці, тому FORWARD існує як іменована точка гака. nftables відокремлює ім'я ланцюга від його типу, гака й пріоритету, а отже, звичайний ланцюг з іменем FORWARD нічого не фільтрує. Порівняння двох моделей пояснює, чому запис, який виглядає правильним в одному інструменті, не дає ефекту в іншому.

Ланцюг — це контейнер. Чи звертається до нього ядро, залежить від реалізації та від того, як набір правил його прикріплює.

Дві моделі, два різні прикріплення

У iptables таблиця filter постачається з трьома вбудованими ланцюгами, INPUT, FORWARD і OUTPUT, а -N створює ланцюг, визначений користувачем, який діє лише тоді, коли на нього переходять з одного з них. Посібник nftables натомість визначає базові ланцюги, які оголошують свій тип, гак і пріоритет, та звичайні ланцюги, які цього не роблять. Базовий ланцюг може мати будь-яке ім'я, а звичайний ланцюг з іменем FORWARD не отримує жодних властивостей від своєї мітки. У цьому вся різниця, і вона невидима в посібнику, який показує лише текст правил.

Бекенди сумісності додають другу причину не виводити поведінку з імені команди. Документація iptables зазначає операції, які відрізняються під iptables-nft, тому розглядайте рідний nftables, iptables-nft і застарілий набір правил як три системи, а не як три написання однієї.

Читайте помилку в її реальному контексті

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

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

Лічильники доводять досягнення, а не вердикт

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

Пересилання IP у ядрі — цілком окреме налаштування. Наявність ланцюга не вмикає пересилання, а відсутність знайомої мітки не означає, що пересилання зупинилося.

Опишіть потік, який ви хочете захистити

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

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

Порівняння закінчується одним питанням: який гак ядро насправді викликає для цього пакета? Дайте відповідь на це, і ім'я ланцюга перестає мати значення.