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, который вы пытались опередить, может также перерезать путь, которым вы пользуетесь для исправления.

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