Werld

Видимо так и есть. Как один из вариантов решения :возвращать на сегмент security-level private, А затем уже в правилах фаерволла для этого сегмента указать разрешающее Source IP - 192.168.1.2, Destination IP - 192.168.1.1, Destination port - 80. И следом запрещающее Source IP - 192.168.1.0/24, Destination IP - 192.168.1.1, Destination port - 80. Если кроме веб-морды надо запрещать доступ к другим службам роутера, также создавать правила запрета на порт 23 (telnet), 22 (ssh) и т.д. Из описания опции peer-isolation "Блокирует передачу трафика от беспроводных клиентов внутри L2-сети." Фаерволл работает на L3, поэтому и не отрабатывают эти правила. Можно сказать, что peer-isolation приорететнее. Через веб-конфигуратор создаются правила только к входящему трафику интерфейсов. Через CLI можно создавать правила и навешивать их на любое направление.

Используя роутер как пограничное устройство, т.е. интернет-шлюз, вы не беспокоитесь о безопасности, о ней за вас беспокоится производитель роутера.)) У Кинетика с этим все в порядке, Можете смело ставить speedster основным устройством, из коробки там все достаточно хорошо закрыто от доступа в локалку извне. В этом вы, кстати, убедились, когда вам пришлось настривать разрешающее правило в межсетевом экране, чтобы дать доступ ПК-1 в локалку за роутером.

Если на ПК-1 винда, то это имхо в целом так себе затея использовать ее как шлюз, как раз из-за всяких возможных глюков подобных. Если хочется стабильности, рекомендую подумать о смене топологии, чтобы шлюзом был роутер, если есть такая возможность. Конкретных шагов по решению таких проблем windows в качестве сетевого шлюза, я, увы, подсказать не могу, т.к. всегда избегал использовать ее в такой роли.

Да, только протокол выберите IP, а не TCP, тогда пинг тоже заработает.

На ПК-1 нужен маршрут до сети 192.168.1.0/24 через шлюз 192.168.159.2 Далее в веб-морде роутера, в межсетевом экране для интерфейса isp разрешить протокол ip с адреса источника 192.168.159.1/32 . Этого должно быть достаточно.

InternetChecker и ping check - это разные вещи.

Опишите, какие шаги вы пробовали. Как вы можете видеть из приведенной темы, можно даже поставить впн-клиентам доступ в домашнюю сеть и дополнительно к этому организовать доступ в дополнительно созданный сегмент. При правильной настройке все должно работать.

Видимо на ddwrt включен нат только для адресов 192.168.0.0/24 Поэтому в приведенной вами документации рекомендовано впн-клиентам назначать адреса оттуда же. В принципе, раз адреса впн-клиентов не пересекаются с пулом dhcp сервера, то можно оставить как было у вас в первом посте. Проблема все равно не в этом, у вас нет нужных маршрутов, по крайней мере на кинетике. На кинетике у вас должен быть маршрут вида. На впн-сервере должен быть маршрут в сеть клиента, т.е. маршрут до сети 192.168.1.0/24 через шлюз 192.168.0.ххх - адрес, получаемый кинетиком от впн-сервера ( например 192.168.0.103) При наличии двух этих маршрутов (один на сервер и один на клиенте) все должно работать.

В конфиге руками удалить...

https://help.keenetic.com/hc/ru/articles/360014436120-Возможно-ли-использовать-контроллер-Wi-Fi-системы-в-режиме-обычной-точки-доступа-

Из статьи на help.keenetic: Если AdGuard не блокирует рекламу, ломает какой-то сайт или приложение, пожалуйста, отправляйте жалобу напрямую разработчикам на почтовый адрес support@adguard.com

Да, давайте не будем. Достаточно почитать немного хотя бы здесь, или вот это, или тут. "Решения о подключении или переходе между точками доступа принимает клиент (смартфон, планшет, ноутбук) на основе своей внутренней логики. Каждый производитель мобильных устройств сам задает критерии о начале миграции от одной точки доступа к другой. Чаще всего это низкий уровень RSSI, а также загруженность точки доступа, низкая скорость передачи данных и др. Повлиять на эту логику мы не можем. Роутер только взаимодействует с клиентом, сообщая ему о соседних точках доступа и отправляет предложение о переходе, но решение о переключении осуществляются только по инициативе самих клиентов."

Решение о переходе всегда принимает клиент. Если клиенты держатся до последнего - это зашито в их драйвер. Со стороны точек доступа никакой принудиловки к переключению не может быть в принципе.

Надеюсь это вас не остановило и вы попробовали Wireguard0 с большой буквы)

Для начала, на сервере временно удалите два других пира кроме WG-home, чтобы исключить пересечения по alowed ip. На сервере и клиенте выполните show interface wireguard0 , там будет видно security-level. Acl'ы, судя по скринам, у вас и так разрешают все.

Ну упоминавшийся уже eoip - это l2 туннель. Но с ним своих проблем хватает, одно то, что нужно решать проблему двух dhcp в одном l2 сегменте чего стоит.

Wireguard - это l3 туннель. Через него не идут широковещательные запросы. Советую крепко подумать так ли нужен вам netbios через vpn. Городить ради него EoIP, который подкинет вам новых проблем для решения, такое себе.

Ну, то есть как я и говорил, на дачном роутере не было маршрута в подсеть за кинетиком

Ну так что в итоге было?

Ну удалите созданные через веб маршруты до 192.168.1.0/24 через br0, и попробуйте в консоли: route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1 dev ppp5

Должны быть маршруты в обе стороны, чтобы все корректно работало. Сейчас все сводится к отсутствию маршрута на дачном роутере. Если вам удастся этот маршрут прописать, то все будет работать.

На приведенном скрине маршрута нет. ТС написал, что открывается веб-морда сервера, т.е. кинетика. Это и понятно, маршрут до 192.168.1.1 есть. Также, отсутствием маршрута до сети 192.168.1.0/24 за кинетиком объсняетмя то, что с самого кинетика пингуется и дачный роутер и устройства за ним, а из домашней сети за кинетиком - нет

Маршруты на картинке у вас на br0, это ваш лан. Маршрут должен вести в pptp интерфейс. Покажите скрин диалога создания маршрута на этом дачном роутере, посмотрим, что он там дает указать

Раз интерфейс указать нельзя (что странно), Сделайте маршрут до сети 192.168.1.0/24 через шлюз 192.168.1.1