Werld

У Вас в правилах разрешено всё для 172.16.203.67 и 172.16.212.115, поэтому правило запрещающее все, расположенное внизу, на эти IP не распространяется. А iphone - это 91.234.60.135?

Не знаю. Никаким особым левелом не обладаю, однако имея ноль знаний о wireguard, прочитал и теперь использую без вопросов. И в кинетике и на vps'ке на линухе. Я не говорю, что там нужно понять всю внутреннюю кухню устройства протокола, но базовые принципы, endpoint'ы, allowed ip и т.д. там расписаны очень хорошо, вопросов не возникло.

Вы плохо искали. https://www.wireguard.com/papers/wireguard.pdf

https://help.keenetic.com/hc/ru/articles/115003690689-Какой-интервал-используется-для-обновления-ключей-rekey-interval-между-клиентом-и-точкой-доступа-Wi-Fi-

Каждый сегмент - это отдельный бридж, то есть l2 связность, то есть "широковещательный домен". Это не прихоть разработчиков, что dhcp (по сути броадкаст) работает только в пределах широковещательного домена. Это концептуально так, это основа сетевых взаимодействий. Так что тут не в переделывании логики дело. Как я вам выше показал, вы можете разбить подсети и привязать их на разные бриджы, но это не имеет смысла, т.к. l2 связности между бриджами это все равно не даст, да и не может дать. А l3 связность можно получить и без извращений с разбиением 24ой сетки на подсети для сегментов.

Если грамотно разбить на подсети 24-ую сеть, то возможно привязать на разные сегменты. Например: Домашняя сеть: И в тоже время гостевая сеть: Так можно сделать уже сейчас, можете проверить. Зачем так делать, это другой вопрос. Смысла, конечно, мало. Да и ТС спрашивает не об этом. Он просит один сквозной dhcp с одним пулом на два бриджа. А это принципиально невозможно.

@T3ch Cat Думаю, еще на роутере провайдера нужен маршрут до 192.168.3.0/24. Так как, по идее, кинетик 2 пересылая пакеты от кинетик 1 не натит их, то до провайдерского роутера они доходят с адресом источника из сети 192.168.3.0/24, а значит чтобы отправлять ответы, этому роутеру тоже нужен маршрут.

На кинетике 2 есть маршрут в сеть кинетика 1(192.168.3.0/24)? На впн-интерфейсе кинетика 2 есть разрешающие правила межсетевого экрана? На кинетике 1 есть маршрут в сеть кинетика 2 (192.168.1.0/24)?

В начале вы упоминаете vps'ку c ikev2/ipsec сервером, при этом кто к ней подключен и какое она вообще имеет отношение, никакой информации. intel nuc с win 10 - дома или на работе? Что значит "wi-fi - интернет. ethernet - провод от keenetic" по wifi интернет не от кинетика, а от куда? Рисуйте схему, потому что вообще ничего не понятно.

В cli с помощью команды show netfilter можно посмотреть все текущие правила. В filter->INPUT есть правило вида -A INPUT -m conntrack --ctstate DNAT -j ACCEPT . Правила межсетевого экрана созданные через веб-морду располагаются выше приведенного правила. Соответственно, вам нужно в межсетевом экране создать два правила. В первом нужно разрешить доступ к пробрасываемому порту для нужных IP. Во втором запретить доступ к этому порту всем. Разумеется, порт надо указывать тот, который уже после DNAT преобразования. Поднобнее об устройстве МСЭ в keenetic здесь, здесь и здесь.

ip static tcp ISP 443 185.0.0.1 443 - работает. Если посмотреть show netfilter, можно увидеть, что правило создается: src: 0.0.0.0/0, dst: х.х.х.х/32, in: "*", out: "*", proto: "TCP"; "tcp" match, mask: , cmp: , dport: 443; DNAT, address: 185.0.0.1, port: 443 Это правило аналог того, что приведено на вашем скрине с микротика. Так что копайте дальше, что вообще должно происходить по вашему? Может у вас микротик еще и snat выполнял, чтобы ответные пакеты от 185.0.0.1 шли к нему? Иначе ответные пакеты от 185.0.0.1 пойдут в соответствии с его таблицей маршрутизации во внешний интернет. Что вообще вы пытаетесь получить таким перенаправлением?

Что-то типа такого ip static tcp ISP 443 185.0.0.1 443 , ISP здесь имя входного интерфейса, у вас может быть другое. cli manual взять здесь

https://forum.keenetic.net/announcement/5-где-взять-тестовые-прошивки/

Согласен. Особенно учитывая, что под капотом то по сути нетфильтр, где все это элементарно выполняется. Ну, допустим, есть проблема с интерпретацией команды ip static, слишком она сложная и универсальная, ну так сделали бы две отдельные ip snat и ip dnat.

Ничего себе какие дела. Очень плохо, что такие замечания к работе не записаны в cli manual'e. Полагаю, в данном конкретном случае, должна сработать как нужно только ip static Wireguard0 PPPoE0

Тут пришло в голову. Раз у вас интерфейс wireguard, так сделайте ip static Wireguard0 PPPoE0

Общий вид команды 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.