Le ecureuil

Мы рассчитываем что на устройствах с 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 и трафик, который был инициирован из локальной сети? Вобщем то, как вам кажется "красивым" на самом деле имеет еще больше неопределенности, чем то, как сделано сейчас. Потому не вижу смысла что-то делать дополнительно, все работает как задумано.

interface ip tcp adjust-mss

Это другое дело, спасибо за репорт, проверим. Так быть не должно - все скрипты должны вызваться хотя бы раз после первого запуска.

Ну так у вас на SSTP8 стоит одновременно up и no connect. Все верно, оно не будет подключаться. Чтобы были попытки, нужно чтобы было и up, и connect. Но connect без via, просто connect и все.

Ну вот видите, прекрасно же поняли что нужно. Так где же логи?

Тогда комбинация из > opkg no disk > opkg disk XXX будет самой правильной, как мне кажется.

Вы точно поняли про interface debug? Нужно ввести эту команду когда все отключено, и затем включить. Ну и логи приложить нормально, в виде self-test, а не обрубком, которым вам показалось достаточно.

Спасибо за репорт, поправлено.

Что такое "выдернуть питание из жопы"? Просто перезагрузить по питанию? Ну наверное может такое случиться, но если ситуация повторяется - почему бы не поменять по гарантии?

По идее oc-server no route или oc-server no route 1.2.3.4 255.255.255.255

Подробностей хотелось бы, или журнал хотя бы.