Зміна правила фаєрвола не працює: порядок правил і стан з'єднання

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

Порядок правил і стан з'єднання — різні несправності

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

Відстеження з'єднань створює другий симптом, і зовні він виглядає однаково. Щойно потік потрапляє до таблиці станів, дозвіл для established-or-related біля вершини ланцюжка повертається ще до того, як ваше нове правило буде розглянуто. У NAT-відображень та сама властивість: трансляція зафіксувалася під час старту потоку, тому змінене правило postrouting не переписує вже запущену сесію. Саме тому зміна ніби працює о 09:00 для нового з'єднання і ніби нічого не робить для сесії, яку хтось відкрив о 08:55.

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

Читайте активний набір правил, а не файл, який ви редагували

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

nft list ruleset
iptables-save

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

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Правило блокування з нулем пакетів після реальної спроби тесту — це не проблема політики, а проблема позиції. Перемістити його — зміна в один рядок, а синтаксис — саме те, що спричинило початкову помилку. У iptables -I вставляє, а -A додає в кінець; у nftables insert ставить правило на початок ланцюжка, а add додає в кінець. Коли правило має перемогти, скажіть це явно, замість того щоб довіряти порядку, який випадково завантажився.

Доведіть, чи відстежується потік

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

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

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

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

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

Тестуйте з нового потоку зі шляхом назад

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

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

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

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

Записуйте мету та позицію разом із правилом

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

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