Werld

Общий вид команды ip static ‹protocol› ( ‹interface› | ( ‹address› ‹mask›) ) ( ‹port› through ‹end-port› (‹to-address› | ‹to-host›) | [port] (‹to-address› | ‹to-host›) [to-port] | ‹to-address› | ‹to-host› | ‹to-interface›) Соответственно речь о 192.168.0.0/16, когда в описании упоминается interface или network. И речь о PPPoE, когда в описании сказано to-address | to-interface Ну не знаю. На мой взгляд, все же проблема именно в том, что роутер считает 192.168.0.0/16 соответствующей public. Поэтому и создаются два правила. Попробуйте в официальную поддержку обратиться, возможно они смогут подсказать решения для такой ситуации.

Интересно. Видимо сеть 192.168.0.0/16 у вас соответствует public интерфейсу, поэтому роутер и создает правило dnat заодно с snat. Т.к. судя по справочнику "Если interface или network соответствует интерфейсу c уровнем безопасности public, то будет выполняться трансляция адреса назначения (DNAT). Если to-address соответствует интерфейсу c уровнем безопасности public, то будет выполняться трансляция адреса источника (SNAT)." У вас, видимо, получается выполняются оба условия вот и создаются сразу два правила. Как выход, что если попробовать интерфейсу, за которым у вас сеть 192.168.0.0/16 (я так понимаю, это впн интерфейс), присвоить security-level private?

На Air стоит MT7628, там ускоряется только AES. Ну и, соответственно, 30 Мбит/с - это нормально для этого устройства. По отзывам на форуме, WG на MT7628 должен быть побыстрее, так что да, имеет смысл попробовать на нем.

А какое устройство клиент? Если это кинетик, маршрут будет выглядеть так, шлюз можно не указывать:

Для начала, убедиться, что на устройстве впн-клиенте (за которым сеть 192.168.2.0/24) есть маршрут до 172.16.2.0/24 (или какой там диапазон у вас для впн клиентов) через впн интерфейс.

Можно сказать, это особенность аппаратной реализации любого маршрутизатора, не только на Кинетиках. Все описанное далее мое ИМХО, так сказать, как я это вижу) Вот возьмем маршрутизатор, у него есть ЦП и есть чип коммутатора. Отдельный чип коммутатора нужен чтобы локальный трафик проводных клиентов не грузил ЦП. Т.е. локальный трафик проводных клиентов нагружает только аппаратный чип свича, соответственно любая фильтрация этого трафика может осуществляться только силами этого чипа, если он такое умеет. По типу, как в некоторых железных управляемых коммутаторах есть опции навроде Traffic segmentation для l2 трафика. Аналогично с wireless чипом. Трафик беспроводных клиентов обрабатывается этим wifi чипом. В отличие от чипа свича, используемый в Кинетике wifi чип имеет функцию изоляции клиентов, что и выведено в настройку peer-isolation. А вот трафик между сетями (например между локальной и глобальной) задействует уже обработку процессором, а значит может быть обработан пакетным фильтром в ядре ОС роутера.

Изолировать друг от друга хосты одного l2-сегмента хоть проводные хоть беспроводные (без peer-isolation) не получится никак, не зависимо от того делаете вы правила на in, out или даже nearby)). Доступ к самому роутеру при этом запретить можно, в том числе выборочно. Использовать для этого правила на out для интерфейса home концептуально не принято. Но если только так вам удалось добиться желаемой фильтрации доступа к роутеру, то и ладно) Вы интерпретируете неправильно. "iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT" означает, что если имеет место некий, каким каким-то образом разрешенный, исходящий траффик, то в рамках установленного соединения не требуется отдельно разрешать входящий трафик этого соединения. А вот в цепочке OUTPUT нет правила всегда разрешающего уже установленные соединения. Поэтому когда вы вдруг создаете запрещающее правило на out, то оно запрещает)). Т.е. происходит следующее, хост отправляет трафик на роутер, роутер его принимает, обрабатывает формирует ответ и отправляет назад, только вот из-за появившегося запрещающего правила ответ не доходит. Поэтому я и написал, что концептуально неверно для данного случая запрещающие правила вешать на out. Запрещать надо in, чтобы роутер зря не принимал и не обрабатывал запросы к себе, ответ на которые все равно не дойдет.

Во-первых, соединение между проводными хостами одного l2-сегмента, как уже написано выше, не заблочить правилами фаерволла на роутере. Поэтому у вас не получилось в качестве эксперимента "заблочить в качестве эксперимента такой путь только в In правилах". Во-вторых, если пакеты все же идут через роутер транзитом не в пределах одной l2, а между сетями (например, когда у вас два сегмента 192.168.1.0/24 и 192.168.2.0/24, или между локальной и глобальной сетью), то запрещающее правило в фаерволле роутера достаточно на in (если запретить инициацию соединения, то никакого ответа и не последует).

Для запрета доступа к админке роутера всем, кроме 192.168.1.2 достаточно двух правил на in для интерфейса home. permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 80 deny tcp 192.168.1.0/24 192.168.1.1/32 port eq 80 На out никаких правил при этом не нужно. Правилом deny ip 192.168.1.0/24 192.168.1.1/32 вы зарежете не только вообще весь доступ к роутеру, включая телнет и проч, но еще и форвард для устройств заодно. Такое правило использовать не надо. Далее, запретить проводным устройствам общаться между собой правилами фаерволла не получится, т.к.между проводными устройствами ходят кадры через l2-свитч. Запретить беспроводным клиентам общение между собой и проводным сегментом при этом возможно, с помощью peer-isolation.

Видимо так и есть. Как один из вариантов решения :возвращать на сегмент 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'ы, судя по скринам, у вас и так разрешают все.