Короткий ответ: скорее всего падает таблица отслеживания соединений (nf_conntrack) — роутер перестаёт распознавать входящие пакеты как ESTABLISHED/RELATED, и они блокируются правилами файрвола. Это объясняет поведение «после перезагрузки работает, через какое‑то время — нет».
Почему это похоже на вашу проблему
- После сброса всё работает несколько перезагрузок — при перезапуске таблица conntrack пуста.
- Потом со временем (торренты, P2P, большое количество коротких соединений, NAT‑сервер) таблица заполняется и новые входящие пакеты считаются NEW и отбрасываются.
- DNS может работать (кэш, короткая нагрузка), а ping/прочие пакеты отправляются, но ответы отбрасываются потому, что нет соответсвующей записи в conntrack.
Как это проверить (на OpenWrt)
1. Просмотреть системный журнал на предмет сообщений о переполнении:
- logread | grep -i conntrack
- dmesg | grep -i conntrack
Вы увидите строки вроде "nf_conntrack: table full, dropping packet".
2. Посмотреть текущее и максимальное количество:
- cat /proc/sys/net/netfilter/nf_conntrack_count
- cat /proc/sys/net/netfilter/nf_conntrack_max
Или (если установлен conntrack-tools): conntrack -C
3. Посмотреть реальное число записей:
- cat /proc/net/nf_conntrack | wc -l
4. Содержимое правил файрвола:
- iptables -L -n -v | grep ESTABLISHED
Как исправить
1. Увеличить размер таблицы (временно):
- sysctl -w net.netfilter.nf_conntrack_max=65536
Учтите: увеличение требует RAM — одна запись занимает память (приблизительно сотни байт). Подберите значение по памяти устройства.
2. Сделать изменение постоянным (пример):
- echo "net.netfilter.nf_conntrack_max=65536" >> /etc/sysctl.conf
- /etc/init.d/sysctl restart (или перезагрузка)
3. Подкорректировать таймауты (если нужно уменьшить удержание неактивных соединений):
- sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600
(по умолчанию может быть часы; уменьшение сократит число держимых записей)
4. Ограничить источник большого количества соединений:
- отключить/ограничить P2P/торренты, UPnP, активные загрузки и т. п.
5. Рассмотреть переход в режим точки доступа (если ваш второй роутер должен быть именно AP):
- подключить к LAN‑порту, отключить DHCP и firewall на OpenWrt, задать статический IP в основной подсети — тогда conntrack практически не нужен.
6. В новых версиях OpenWrt — включить hardware flow offloading (в LuCI: Network → Firewall → Flow Offloading), это уменьшает нагрузку на conntrack/CPU (в зависимости от чипа).
7. Мониторинг: установить conntrack‑tools и периодически смотреть conntrack -L | wc -l или настраивать скрипт оповещений.
Ещё возможные причины (проверить, если conntrack не подтверждается):
- Ассиметричная маршрутизация: ответы идут на другой шлюз/интерфейс — проверьте маршрут (ip route) и что gateway установлен правильно.
- Дублирование IP в сети (конфликт адресов) — проверьте, не даёт ли основной DHCP тот же адрес другому устройству.
- Неправильное подключение (подключение во WAN‑порт вместо LAN при желании работать как AP).
Резюме
1) Сначала проверьте логи dmesg/logread на сообщения nf_conntrack и текущее/максимальное число записей.
2) Если таблица заполняется — увеличьте nf_conntrack_max, сократите время таймаутов или переведите устройство в режим AP (без NAT/файрвола).
3) Если сообщений об переполнении нет — проверьте маршруты, конфликт IP и правильность подключения (LAN vs WAN).
Если хотите, пришлите выводы команд:
- dmesg | grep -i conntrack
- cat /proc/sys/net/netfilter/nf_conntrack_max
- cat /proc/sys/net/netfilter/nf_conntrack_count
- ip route
и я подскажу конкретные значения и настройки.