Проблема в работе приложения из-за частого сброса правил iptables

[Ground_Zerro]

Пользователи сталкиваются с нестабильной работой приложения. Причина в принудительной очистке правил iptables со стороны системы.

Статистика за 17 минут работы:

• Сигнал `SIGUSR1` получен: 24 раза.
• Правила iptables приложения не найдены (были удалены извне) и пересозданы: 19 раз.

В среднем таблица очищается чаще, чем 1 раз в минуту.

Лог событий с таймингами (удаление и пересоздание правил приложения):

Спойлер

17:01:47 [WARN] No rule found for HydraRoute, creating!
17:02:39 [WARN] No rule found for HydraRoute, creating!
17:05:53 [WARN] No rule found for HydraRoute, creating!
17:05:54 [WARN] No rule found for HydraRoute, creating!
17:05:57 [WARN] No rule found for HydraRoute, creating!
17:05:57 [WARN] No rule found for HydraRoute, creating!
17:06:01 [WARN] No rule found for HydraRoute, creating!
17:06:11 [WARN] No rule found for HydraRoute, creating!
17:06:11 [WARN] No rule found for HydraRoute, creating!
17:06:14 [WARN] No rule found for HydraRoute, creating!
17:06:14 [WARN] No rule found for HydraRoute, creating!
17:06:15 [WARN] No rule found for HydraRoute, creating!
17:06:15 [WARN] No rule found for HydraRoute, creating!
17:06:22 [WARN] No rule found for HydraRoute, creating!
17:07:45 [WARN] No rule found for HydraRoute, creating!
17:08:05 [WARN] No rule found for HydraRoute, creating!
17:18:57 [WARN] No rule found for HydraRoute, creating!
17:19:00 [WARN] No rule found for HydraRoute, creating!
17:19:00 [WARN] No rule found for HydraRoute, creating! 

Со стороны пользователя действий не производилось: интерфейсы не создавались, не удалялись и не падали (Link всегда UP).
Постороннего ПО, управляющего iptables, не установлено.

Вопросы:

1. Что в системе может так агрессивно сбрасывать/перезагружать таблицы iptables?
2. Как избежать состояния гонки между приложением и системой?
3. Является ли добавление задержки (2-3 сек) перед обновлением правил решением, или есть более надежный подход?

@Le ecureuil @eralde @Александр Рыжов

Не знаю кого еще можно тегнуть по этому вопросу, прошу прощения если не в адрес.
Буду благодарен хотя бы за намек в какую сторону копать. Пользователи мучаются...

 

Дополнительные сведения

Спойлер

Взаимодействие с iptables ограничено: используется стандартная логика маркировки (CONNMARK/Restore Mark) для целевых ipset-ов. Блокирующие правила или сложная маршрутизация не применяются.

Пример:

-A PREROUTING ! -i nwg1 -m conntrack --ctstate RELATED,ESTABLISHED -m set --match-set nwg1 dst -j CONNMARK --set-xmark 0x3001/0xffffffff
-A PREROUTING ! -i nwg1 -m conntrack --ctstate NEW -m set --match-set nwg1 dst -j CONNMARK --set-xmark 0x3001/0xffffffff
-A PREROUTING ! -i nwg1 -m set --match-set nwg1 dst -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A PREROUTING -m conntrack --ctstate RELATED,ESTABLISHED -m set --match-set HydraRoute dst -j CONNMARK --set-xmark 0xffffaaa/0xffffffff
-A PREROUTING -m conntrack --ctstate NEW -m set --match-set HydraRoute dst -j CONNMARK --set-xmark 0xffffaaa/0xffffffff
-A PREROUTING -m set --match-set HydraRoute dst -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff

 

/opt/etc/ndm/netfilter.d/015-hrneo.sh

#!/bin/sh
[ "$type" != "iptables" ] && [ "$type" != "ip6tables" ] && exit
[ "$table" != "mangle" ] && exit

PID_FILE="/var/run/hrneo.pid"

if [ ! -f "$PID_FILE" ]; then
    exit 0
fi

PID=$(cat "$PID_FILE")

if [ ! -d "/proc/$PID" ]; then
    logger -t hrneo "hrneo process with PID $PID does not exist, deleting PID file"
    rm -f "$PID_FILE"
    exit 1
fi

kill -USR1 "$PID"
logger -t hrneo "Updating hrneo iptables rules"

 

 

[Ponywka]

Раз уж началась такая пляска, то добавлю свои пять копеек в этот тред, т.к. он касается и меня в том числе, а также повлиял на мою дальнейшую смену роутера (в отрицательном для сообщества Keenetic значении).

Моему софту MagiTrickle это тоже мешает. Я писал свой софт так, чтобы все правила жили в своих iptables chain, и уже они подключались в конец всех правил, и чтобы не пересекались с основными правилами (чтобы, например, если возникли какие-либо проблемы - мои правила можно было очень быстро найти и подчистить, не высматривая их среди огромного списка iptables-save).

Под капотом в моём софте происходит что-то по типу:

iptables -t nat -N MT_DNSOR
iptables -t nat -A MT_DNSOR -d 192.168.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination :3553
iptables -t nat -A MT_DNSOR -d 192.168.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination :3553
iptables -t nat -A PREROUTING -j MT_DNSOR

Время выполнения команды "iptables" если быть честным - очень долгое (уже не помню, но чот около 100мс на каждый индивидуальный вызов iptables, что выливается в секунды выполнения, за которые Keenetic успевает выполнить чистку правил). И по факту между выполнением этих команд Keenetic начинает чистку iptables, после чего я получаю ошибку в стиле "iptables: no chain MT_DNSOR", потому что мой код не успел вовремя заполнить таблицу нужными значениями.

Моё ПО кросс-платформенное. Я не ориентируюсь только на один Keenetic. Городить костыли по типу "если зафейлилось - повторить" не собираюсь, потому что вместо ошибки "iptables: no chain MT_DNSOR" вполне может затесаться ошибка по типу "iptables: no module loaded" (условно), и в подобном случае аварийная остановка моей программы - оправдана, и пытаться выполнить перезагрузку - бессмысленно. 

В результате, из-за частых сбросов iptables, особенно в момент запуска роутера, мне пришлось городить костыль, который бы пытался запускать сервис после перезагрузки роутера в течении 5-ти минут. GitLab (/opt/etc/init.d/S99magitrickle)

Потенциально эта проблема исправляется вызовами iptables-save и iptables-restore --noflush (высчитывая разницу между тем, что есть, и тем, что должно быть, формируя diff в формате iptables-restore), что я реализовал в коммите GitLab (Commit 6e4bd9c0), однако (далее скорее является моим багом, но если бы не ситуация с очисткой - мне бы и не пришлось делать что-то подобное) теперь возникает такая ситуация, что если Keenetic вызовет несколько раз вызов netfilter.d, то я получу такую ситуацию, что:

--- Вызов netfilter.d ---
iptables-save > (/dev/stdout)
iptables-restore --noflush < (/dev/stdin)
--- Вызов netfilter.d ---
iptables-save > (/dev/stdout)
iptables-restore --noflush < (/dev/stdin)
--- Вызов netfilter.d ---
iptables-save > (/dev/stdout)
--- Вызов netfilter.d ---
iptables-save > (/dev/stdout)
iptables-restore --noflush < (/dev/stdin)
iptables-restore --noflush < (/dev/stdin)

По итогу из-за того, что я не могу заблокировать iptables между запросами iptables-save и iptables-restore - у меня происходит дубликация правил.

Реализовывать нативную работу iptables на Go (как это делает сам бинарник "iptables" работая с самим ядром Linux) ради одного KeeneticOS, когда на других платформах всё работает и без этого - желания как такового ноль. 

И это не говоря о том, что мне в целом приходится ловить эвент с помощью Bash скриптов, оборачивать их в RAW HTTP соединение (либо городить внутренний бинарный API либо по собственному протоколу, либо gRPC), и уже обрабатывать это событие индивидуально в программе, что опять же, считаю костылём. GitLab (/opt/etc/ndm/netfilter.d/100-magitrickle)

Этих проблем нет на таких прошивках, как DD-WRT и OpenWRT (где на последний я в итоге перешел, ведь он мне даёт больше возможностей, как энтузиасту-разработчику).

Изменено 17 января пользователем Ponywka

[gaaronk]

8 часов назад, Ground_Zerro сказал:

В среднем таблица очищается чаще, чем 1 раз в минуту.

 

 

Это никак не исправить. Это такой дизайн и логика работы.

 

Используйте таблицу raw

При старте системы подгружаете модуль

insmod /lib/modules/$(uname -r)/iptable_raw.ko

 

И далее все делаете в raw

 

[gaaronk]

2 часа назад, Ponywka сказал:

Моему софту MagiTrickle это тоже мешает. Я писал свой софт так, чтобы все правила жили в своих iptables chain, и уже они подключались в конец всех правил, и чтобы не пересекались с основными правилами (чтобы, например, если возникли какие-либо проблемы - мои правила можно было очень быстро найти и подчистить, не высматривая их среди огромного списка iptables-save).

С NAT вы это никак не победите. Печаль. Прошивка не позволит. У меня бывали ситуации когда таблицы iptables системой "передергивались" несколько раз в секунду. Никакие скрипты в хуках в таком случае работать нет будут.

Изменено 17 января пользователем gaaronk

[bzzztomas77]

а почему нельзя напрямую использовать таблицу маршрутизации? причем через ndmc

[Ponywka]

4 minutes ago, bzzztomas77 said:

а почему нельзя напрямую использовать таблицу маршрутизации? причем через ndmc

Ну потому что если брать мой случай - в других прошивках (OpenWRT, DD-WRT, AsusWrt-Merlin и прочих) нет ndmc - это есть исключительно на роутерах семейства Keenetic (и, потенциально, на других роутерах, с ПО от https://ndmsystems.ru/)?

[Ponywka]

On 1/17/2026 at 9:20 PM, Ponywka said:

iptables-restore

По итогу даже такой костыль не помог моей программе. Вообще этот лог я получил давно, просто руки никак не доходили отписать об этом здесь.

Я получаю ошибку "iptables-restore: line 8 failed" при применении следующей цепочки:

*nat
:PREROUTING - [0:0]
:MT_DNSOR - [0:0]
-F MT_DNSOR
-A MT_DNSOR -p tcp -d 192.168.133.1 --dport 53 -j DNAT --to-destination :3553
-A MT_DNSOR -p udp -d 192.168.133.1 --dport 53 -j DNAT --to-destination :3553
-I PREROUTING 1 -j MT_DNSOR
COMMIT

Т.е. да, оно падает на операции "COMMIT".

Добавлю немного контекста - эта пробема происходит во время запуска роутера, и, соответсвенно, во время прогрузки сервисов Entware. Если без остановки перезагружать роутер, то с шансом на 1496 запусков 280 будут провальными. Инфу случайно собрал на моменте, когда в init скрипте на Dev-роутере у меня была реализована перезагрузка раз в 3 минуты, и когда у меня дома кто-то передёрнул свет, тем самым позволив собрать такую статистику.

 

Я понимаю, что необходимость в MagiTrickle как в утилите для настройки выборочной маршрутизации немного отпала, т.к. у Keenetic появилась своя стоковая, но всё же - много кто отписывает, что моё решение, которое по факту является костылём, работает лучше этого самого стокового решения (сам не использовал - много кто в моём чате об этом пишет). Собственно я уже немного без понятия куда писать, ибо ветка по факту мертва. Подсказали, что нужно пингануть @admin, и в таком случае на неё могут обратить внимание, поэтому... Надеюсь, что в эту ветку заглянут.

Изменено 4 апреля пользователем Ponywka