К роутеру подключено два сервера на которых в сумме два gitlab и один openvpn.
Примерно раз в неделю зависает роутер с различными симптомами. Чаще всего просто не дает делать новых подключений и не пускает к себе в веб интерфейс по проводу.
Сегодня удалось во время возникновения проблемы зайти в интерфейс и глянуть логи. Там всё было забито сообщениями о переполнении таблицы подключений
nf_conntrack: table full, dropping packet
После перезагрузки, естественно, проблема снимается. Далее в терминале я мониторил как регулярно растет количество подключений и не уменьшается при этом.
Пробовал ставить net.netfilter.nf_conntrack_tcp_timeout_establishedвплоть до 10 сек. и это не помогло - соединения продолжают расти как будто они все активны и сбросу не подлежат. Кроме того эта настройка не сохраняется и после перезагрузки сбрасывается.
Это поддается какой-то перенастройке или отключению на роутере?
Здравствуйте. Первоначально обновите прошивку до последней версии, её можно взять на сайте routerich.ru в разделе прошивки или же в тг чате в теме “Прошивка”. Вам нужно взять правильную прошивку под ваш usb порт и прошить без сохранения настроек. С нуля настроить и далее сделать так: Система - система - ведение журнала - размер системного журнала увеличить до 1280 - Записывать системные события в файл - сделать путь /root/system.log - применить. Перезагрузить роутер и наблюдать, как снова перезагрузится - Раздел Nas - файловый менеджер - по пути что прописали достаём лог и присылаем его. Ещё есть вариант с увеличением таблицы соединений, но лучше сделать первый вариант сначала. В последней прошивке по сравнению с 24.10.1 очень много изменений внутренних, в том числе с кол-вом соединений
на сайте мне выдает последнюю прошивку 24.10.4 от 01.11.2025. То есть до 25.12 еще не скоро?
Как его правильно удалить? Через терминал, как пакет или через какие-то настройки в интерфейсе?
Удалять необязательно. Можно просто выключить его через LUCI, этого достаточно.
Если всё-же надумаете удалять, тогда через менеджер пакетов, либо через консоль.
Релиз 25.12 будет уже очень скоро. Команда Routerich явно не станет медлить с релизом.
Есть хорошая статья, в которой много чего описывается довольно детально:
Если нажать 16 раз PgDn, там будет про conntrack, его работу и причины возникновения ваших ошибок. Но лучше потратить время и прочитать все целиком.
net.netfilter.nf_conntrack_tcp_timeout_established вплоть до 10 сек. и это не помогло - соединения продолжают расти, как будто они все активны и сбросу не подлежат.
В статье по ссылке рекомендуют тюнить nf_conntrack_tcp_timeout_time_wait.
Эта настройка только для TCP, и она не единственная. А есть еще UDP, помимо TCP.
Я рекомендую сначала посмотреть командой netstat или netstat -n какие соединения открыты.
У меня на домашнем роутере (Xiaomi AX3200 с OpenWRT) основная часть открытых сокетов - это TCP-шные запросы к DNS (на 53 порту) в состоянии TIME_WAIT, их 36 штук. В то же время ESTABLISHED - всего 3.
Можно еще установить пакет conntrack и напрямую смотреть таблицы командой conntrack -L
Кроме того, эта настройка не сохраняется и после перезагрузки сбрасывается.
Немного дополню - похожая проблема. Прошивка последняя (24.10.5 r29087-d9c5716d1d RR-3.9.0).
Я искал причину на разных компьютерах внутри сети, думал - возможно, кто-то качает торренты, или завёлся какой-нибудь зловред. Нашёл там, где не ожидал. Поставил на роутер Zabbix agent, сделал пару настроек для отслеживания текущего размера conntrack -C, стал искать корреляцию с другими метриками, и с удивлением обнаружил: conntrack растёт, когда ходят пакеты через VPN SSTP-туннель, через который подключена одна удалённая площадка с парой серверов Proxmox. И если в веб-браузере открыта страница сервера Proxmox, на ней постоянно обновляется информация о статусе серверов, виртуальных машин и т.д., и при этом таблица conntrack растёт. С локальными серверами Proxmox такого не происходит. Если закрыть - не растёт, но и никогда не уменьшается.
Ничего не изменилось. Выглядит так, как будто таймауты в sysctl net.netfilter.nf_conntrack полностью игнорируются, или для данных соединений используются другие таймауты.
Что ещё проверил: miniupnpd установлен, но выключен. Статус службы active with no instances, остановил полностью - то же самое. Пока больше никаких идей нет.
Спасибо за дополнение.
Я лично грешил на gitlab runnerы не подключенные. Если раннер запущен, то регулярно обновляет подключение создавая новое до тех пор пока его не подхватит сервер гитлаба. Но впн там тоже работал и вполне возможно они вдвоем захламляли счетчик.
В итоге тоже не нашел как его скорректировать и мы пока сменили основной роутер, а данную модель используем для локальных целей.
