nftables: вставте правило дозволу VPN перед дескриптором drop

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

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

Два розміщення, два різні результати

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

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

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

Дескриптор ідентифікує правило, а не номер рядка

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

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

iptables --version
nft -a list ruleset

Версія iptables повідомляє, який backend використовується. Набір правил iptables-nft і незалежно керована вбудована таблиця можуть співіснувати, тому список з одного frontend не є автоматично повною картиною фільтрації. Перевірте обидва подання, перш ніж вибирати ланцюг.

Знайдіть ланцюг і правило, які справді виконують drop

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

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

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

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

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

Дозвіл обмежений, drop термінальний

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

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

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

Перевірте файл, потім підтвердьте живий результат

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

nft -c -f reviewed-vpn-rule.nft

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

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