Le ecureuil

Нужно быть готовым к произвольному порядку + скрипты должны быть идемпотентными (позволяющими вызвать себя произвольное количество раз с одними и теми же параметрами без каких либо посторонних эффектов).

Прежде всего вам стоит уточнить - вы точно понимаете что такое камуфляж для SSTP? Это когда на HTTP-запрос с методом SSTP_DUPLEX_POST и URI /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ вам не приходит в ответ HTTP/200 и не продолжается установка соединения, а отвечают 404. То есть камуфляж - это защита от активной проверки стандартных endpoint-ов. При этом того, что не будет доступа по TLS вообще никто и не думал обещать.

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

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