keenet07

у кого? кто куда подключается? 192.168.5.3 это что?

Что касается самого правила, вам в любом случае придётся сначала выяснить IP адрес активного клиента RDP чтоб создать это зеркальное правило запрещающее со стороны сервера отправлять по порту RDP исходящие пакеты на адрес клиента. И делать это вручную в интерфейсе каждый раз, ну такое себе... А если создать правило на "любой" ip-адрес по порту RDP и включать его когда нужно экстренно выкинуть клиента с RDP (конечно на ряду со всеми прочими необходимыми для этого действиями). То наверное это вариант. главное не забыть что такое правило полностью запретит вам подключаться к любому RDP с WAN интерфейса. Ну и домашней сети тоже.

Куда вы там подключаться собрались? Как настроен VPN вообще роли не играет. Ну введите там что-нибудь произвольное. Включать его в интерфейсе подключений вам не нужно, от слова совсем. Просто создали и забудьте о нем. А лучше назовите его как-то понятно типа WAN out чтоб не путаться. Всё правила которые вы будете добавлять в эту вкладку "для VPN" будут применяться как для самого VPN, так и для исходящих на WAN (то что вам и требуется), если вы сделаете всё так как написано в том сообщении. Третий раз это повторять не буду. Возьмите да проверьте. Создайте правило блокировки для какого-то сайта по IP и попробуйте на него зайти.

Создается вкладка и access-list для VPN. А мы просто берем и второй строчкой прописываем в блоке WAN (интерфейсе) конфига этот самый access-list с параметром out, как показано в примере. И всё. Теперь всё правила которые создаются в этой вкладке применяются для исходящих на WAN интерфейсе и к VPN для входящих, но т.к. VPN у нас фейковый, чисто для создания структуры, роли это не играет. Внимательно почитайте, что там написано и разберитесь.

Если вы про мою ссылку, то описан способ выноса в веб-интерфейс в меню Межсетевой экран вкладки которая позволит создавать там правила для исходящих соединений на WAN. VPN там используется только для того чтоб создать в веб эту вкладку. Вам это нужно было для быстрого и удобного создания зеркального правила вместе с основным запрещающим входящие. (чтоб выбрать никнейм напишите @ и сразу начинайте писать никнейм как есть. @Bolt)

Или перестало работать какое-то другое устройство. ) Что там по соответствию пулу?

Стандартный размер пула 40 адресов, на моем кинетике по крайней мере. (у меня конфиг старый, может что-то уже поменялось). Если у вас вдруг в какой-то момент может стать больше 40, включая незарегистрированные, это теоретически может вызвать какой-нибудь эффект. Проверьте. Эта настройка меняется в веб-интерфейсе.

Пул устройств какой для подсети стоит? И сколько их фактически?

Т.е. даже перезагрузка роутера не помогает? А после сброса сразу начинают все работать? Сколько раз проверялся этот сценарий?

Проблема отсутствия интернета на устройстве также может быть связана с разными настройками DNS на устройствах. Убедитесь что все они у вас работают именно с DNS роутера.

Проверьте ещё теорию потери сети для некоторых устройств подключающихся по 2.4 WIFI на 13 канал. Некоторые устройства его не видят. А роутер может динамически менять канал. Вообще это проблема старая, может уже и не актуальная, но проверьте.

В момент когда пропадает инет на устройстве, оно точно имеет корректный IP адрес и пингуется ли с роутера или на роутер? Не присутствует ли в сети какое-либо устройство на котором может быть активен свой DHCP сервер (второй для сети)?

Устройство зарегистрировано в системе? Статический адрес по DHCP получает? Или может быть адрес задан на самом устройстве?

Если возможно будет, то сделают. Я говорю о том как оно изначально сделано. Вам сейчас одной буковки не хватает. Кому-то двух или трех не хватает, чтоб не было переноса. А кто-то просто выбирает слова не длинее 7 символов. А на деле на низких разрешениях может появиться некрасивая полоса прокрутки. На разных моделях разное количество портов. И вписать нужно все варианты.

1. Но в рамках стандарта. И исключительно точечно. 2. В теории пока есть исходное общее запрещающее правило фаервола. Как правило будет деактивировано, можно и эту блокировку удалять. Но опять же наверное есть нюансы. 3. Тут да. Всякое может случиться. Эту блокировку можно и не ставить отдельно. По идее TCP RST если сработает и так уже должен будет прервать соединение. Серверная сторона же не должна после этого что-то слать клиенту наружу. А новые входящие и так будут заблокированы фаерволом. Или не так?

При добавлении торрента система должна на носителе зарезервировать под файлы место. Возможно именно в этот момент у вас и происходит перегруз. Ещё и файл подкачки у вас там. Потом уже службы все попадали, в том числе DNS. Т.к. сбой этот у вас не на регулярной основе происходит вполне вероятно что на DNS провайдера просто вам повезло. Попробойте отключить PreAllocation в клиенте. Так для проверки. Ну и в подтверждение вашей теории поставьте другие публичные DNS резолверы. Особенно хорошо было бы если присутствовали не только DOH, но и DOT резолверы.

Потому-что всё зависло ))

Носитель на который должно качаться в порядке? Что-то вызвало ожидание системы. Там у вас куча ошибок вызванных процессом торрента из-за которого вся система впала в длительный лок. Все службы подзависли, а потом дружно выругались в лог. У вас там случайно файл подкачки в сжатом рам диске не включен на роутере?

Дело то может и не в DNS вовсе, а в том куда вы сохраняете торрент. А что добавляли? На добавлении одного файла с фильмом например висло хоть раз? Или наоборот когда добавляете торрент с некоторым количеством крупных файлов. Или большим мелких.

output isp это исходящий трафик направленный в интернет на WAN интерфейсе. input isp соответственно входящий. Подробно для вашей конфигурации посмотрите в самом конфиге роутера как это выглядит. В команде ставится либо IN, либо OUT. Правило для исходящих на WAN сможете создать только в CLI или ручками в конфиге. Соответственно включать и отключать так же. Но можно сделать и для веб-интерфейса. Но это дольше и сложнее. Но удобнее. На форуме есть метода.

Понятно. А если так: вместо DROP используем REJECT с отправкой TCP RST на сервер или и на клиент и на сервер для надежности. (REJECT --reject-with tcp-reset). Удаляем conntrack запись. Сокет закроется по правилам TCP. Соединение разовётся. Не даем пересоздавать запись CONNTRACK как NEW из-за запрещающего правила фервола. Или есть какие-то нюансы?

Ну если по другому не хотят или проблемотично сделать. То как частное решение может сгодиться. Ставим хук на изменение правил фаервола по которому произойдет сброс всех соединений интерфейса или вообще всех. Как решение для частного случая вполне может сгодиться. Вам срочно нужно отключить сервис с отключением клиентов, вы идёте на жертвы. Ну хотя бы такое решение будет. Вы часто что-то меняете в фаерволе? Что нужно само переподключится. А что сейчас? Ждать или перезагружать устройство.

А есть какая-то команда которая просто в любой момент разорвёт все активные соединения? Со всеми вытекающими. Кому-то уже этого было бы достаточно. Наверное можно было бы хук на событие поставить. Если просто отключить и включить WAN это поможет или не поможет в этих целях?

Возможно отступы сделаны согласно минимальному разрешению экрана в котором нормально отображается веб-интерфейс.