Le ecureuil

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

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

Конечно есть. 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

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

Обратно переходите через cli. Это сделано специально, чтобы относительно малоиспользуемый канал delta не мозолил глаза массовому пользователю, так как на подавляющем большинстве современных устройств никакой delta просто нет.

Вариант с socat вполне себе unix-way и работает как задумано. Не вижу тут никакого "костыля".

Разве что руками их дернуть. Или у вас есть ситуация, что после старта opkg netfilter.d не вызывается ни разу?

Система полностью асинхронная и никто никого ждать, а также переделывать не будет. Ну и система записывает таблицу целиком за раз, а не цепочку за цепочкой - реализация userspace netfilter у нас своя, потому он записывает всю таблицу целиком атомарно. Правильное решение такое: - накапливаем вызовы netfilter.d, если он пришел, то надо текущую запись точно прервать (при активном процессе) и начать заново - если при записи возникла хоть какая-то ошибка из разряда ENOENT, значит нужно начать все заново, не кидая ошибок эти два процесса лучше всего делать в независимых тредах, и тред-обработчик netfilter.d по получению обновления должен посылать сигнал перезапуска в тред-коммитер таблицы. Коммитер таблиц правильнее сделать таким, чтобы он сперва все удалял, и только потом начинал заполнение. Да, это сложно, но только такая схема является совместимой.

Это устройство - K3 - называется in_rb. Подходящее вам ПО находится тут: https://osvault.keenetic.net/in_rb/2.16/