Le ecureuil

Нет, сейчас нет возможности ограничить запросы по geoip или его аналогу.

Ну так это вы в opkg и сейчас можете намутить без ограничений.

Спасибо за репорт, поправлено. Появится в следующей версии.

Создайте отдельную тему. Это на андроиде? Платный?

Это и есть "встроенные средства".

Начиная с 4.3.0 можно сбросить сессию через session-logout.

Лимит поднял, но нужно проверить на следующей версии.

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

Отключать журнал идея точно так себе.

На самом деле у вас failed to read feedback contents - и из-за этого все происходит. Можете прислать конфиг сервера (кусок с маршрутами), чтобы я локально попробовал воспроизвести?

Мы рассчитываем что на устройствах с 7628 будет работать хорошо около сотни, на 7621 и аналогах - по 500, на самых мощных с arm - 1000.

Если не работает и на 4.2 тоже, то скорее всего РКН помахал вам ручкой. Что с этим делать - решать вам.

ext4 самая оптимальная. Вероятнее всего у вас были процессы с постоянной записью на диск, но они угробят любой накопитель при неосмотрительном обращении.

Вы специально поиском не пользуетесь?

Для части проксей можно использовать ndns - тогда будет сертификат для доменное имя стандартное. А для другой части можно использовать domain - и для этих проксей будет ваше имя.

Так нет никакого запрета, есть отключенный проброс, но зеркального правила "на выход" - явно нет.

А сообщений об ошибках никаких нет? В логе чисто? Покажите журнал в таком состоянии.

Конечно есть. 1. tcp rst - это, по хорошему, вмешательство в трафик. Хотя вроде администратор сам этого хочет. 2. А сколько должна жить эта блокирующая запись в нетфильтре? 3. На нее могут попадать и легитимные соединения от, скажем, другого проброса - что не очень хорошо.

Эта возможность у вас уже есть. Создаете access-list, вешаете его на output ISP (в вебе только на input), создаете запрещающее правило, зеркальное пробросу, и дальше выключаете.

Еще раз повторяю - это УЖЕ ПРОИСХОДИТ. Прочитайте еще раз мой пост с подробным описанием до просветления, там все написано в деталях.

Сейчас сделано точно также.

Что значит "разорвет все активные соединения"? Очистка conntrack? Так это уже происходит. Но суть-то в том, что сокеты на клиенте и на сервере вообще никак к роутеру не относятся, и потому для них соединение продолжает жить. А поскольку трафик из локальной сети в WAN является легитимным, и никаких ограничений на него нет, то первый же пакет в ту сторону от "сервера", на который проброшен порт, опять пересоздаст запись в conntrack. Потому давайте еще раз разберемся - что такое "разорвет активные соединения"?

Отписал по существу в теме, это не дырка.

Поправлено, будет в следующей 4.3.

Если кратко, то на самом деле все работает и работает правильно, но вы видимо не очень понимаете сам принцип работы conntrack в сочетании с TCP. Да, правило в netfilter удаляется и запись в conntrack очищается. По идее этого достаточно, чтобы все прекратило работать при трафике снаружи, из WAN. Именно это и происходит. Однако если TCP сессия активна и в ней передается какой-то трафик, то в ней всегда будет обратный TCP трафик из локальной сети в Интернет (как минимум TCP ACK), и вот он тут же пересоздает запись в conntrack, которая теперь по всем признакам выглядит как полностью, 100% легитимный трафик из локальной сети в Интернет, и не имеет никакой связи с пробросом. И все дальнейшиее взаимодействие продолжается через эту запись - в обе стороны. Если делать как вы хотите, чтобы прям 100% все блокировалось, то нужно на каждую запись в conntrack создавать временную запрещающую запись в firewall, чтобы этот ответный трафик из LAN тоже блокировать. Но с какой, простите, стати? И сколько эта запрещающая запись должна существовать? А что если на нее начнут попадать другие, легитимные соединения, ведь здесь уже нельзя различить трафик, который был инициирован как проброс из WAN и трафик, который был инициирован из локальной сети? Вобщем то, как вам кажется "красивым" на самом деле имеет еще больше неопределенности, чем то, как сделано сейчас. Потому не вижу смысла что-то делать дополнительно, все работает как задумано.