Werld

Вообще никакие устройства в сети 192.168.22.0/24 не пингуются? Трассировку еще покажите.

Проверить корректность allowed ips на обеих сторонах и правила межсетевого экрана

Отключение галочки "Доступ к приложениям домашней сети" устанавливает security-level выбранного сегмента в protected. А, как вы уже узнали из поста о настройки AirPrint между сегментами: "Требуется 2 сегмента с security-level private так как mdns работает только с private интерфейсами"

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

Пример таких роутеров в студию

В том и дело, казалось бы там под капотом netfilter с его обширными возможностями, но keenetic os представляет нам лишь два инструмента ip nat и ip static. Ни тот ни другой нужный вам snat соорудить похоже не даст, по крайней мере, я не придумал как. Попробуйте пообщаться с техподдержкой. Если не помогут с правилом, то хотя бы занесут ваш голос в копилку недовольных текущей реализацией управления nat'ом.

Я ещё раз обдумал вашу задачу и понял, что предложенный мной "финт" тут никак не поможет. 😐 Он никак не изменит факта, что адрес источника не меняется на всем пути пакета до IRZ и, соответственно, ответ будет отправлен по маршруту по умолчанию. Если белый ip адрес, с которого вы подключаетесь извне к кинетику, не меняется, то можно прописать до него маршрут через ВПН подключение на IRZ.

У меня на 3.8.4 все мои пробросы работают, правда не через wisp. С самого пк на win10 пингуется что-нибудь в 10.0.0.0/24?

Ну тогда могу только развести руки. На самом устройстве никакого фаервола нет? Может там разрешен доступ только из той же подсети , что и само устройство, и поэтому оно на себя пакеты с адресом источника из сети 10.0.0.0/24 не пускает?

Ну, судя по скринам, все должно работать, если вы действительно стучитесь на tcp 10.0.0.3:3389 находясь непосредственно в сети 10.0.0.0/24, а не подключаясь к этой сети через впн, например. Убедитесь, что на wisp интерфейсе ip с правильной маской и, соответственно, на кинетике есть маршрут в эту сеть (10.0.0.0/24)

Без понятия. Приведите скриншот окна настройки проброса портов, которое умеет этот IRZ, очень странно чтобы он не умел классический dnat проброс портов

Как? Вы не предоставили ничего кроме словесного описания. Хоть покажите правило проброса, которое вы построили.

Во-первых, на кинетике кроме изначальных трех пробросов портов, больше никаких трансляций делать не нужно. Во-вторых вы на IRZ строите какое-то не то правило проброса. Почему src ip 192.168.1.244? У вас src не меняется на всем пути пакета и равен белому ip с которого вы идете стучитесь на порты кинетика. Правило на IRZ должно пробрасывать, то есть осуществлять dnat tcp dst addr 192.168.1.244 port 8080 to dst ip 192.168.2.1 port 8080

А Вы захватывали трафик на IRZ, убеждались что до него доходят проброшенные пакеты от домашнего кинетика? А то я сходу не готов утверждать, что по умолчанию там разрешен форвард из wan к vpn-клиенту. Для начала, чтобы исключить этот момент неплохо бы создать на wan интерфейсе (в вашем случае beeline l2tp) правило в межсетевом экране. Оно должно разрешать tcp пакеты на адрес назначения 192.168.1.244 на порт 8080 (именно на него а не 3080). После этого пакеты точно смогут доходить до IRZ. Далее по поводу nat. Вы правильно рассудили, что IRZ ответы будет слать по дефолтному маршруту, а не в туннель. Чтобы обойти этот момент предлагаю сделать финт ушами и на IRZ также сделать пробросы. И на самого себя, на ip на внутреннем интерфейсе 192.168.2.1 и на комп2 192.168.2.20. Тогда ответы от IRZ автоматически будут подвергаться обратной трансляции и уходить именно в туннель

TL; DR: Привязывание acl к интерфейсу на out, означает, что правила будут применяться для трафика, выходным интерфейсом (out-interface) которого будет этот интерфейс (к которому привязали acl). Под капотом keenetic os - ядро linux, а значит и netfilter. Взаимодействовать с ним напрямую, с помощью например iptables, мы не можем (без opkg). Нам доступен некий уровень абстракции в виде наборов правил, которые мы сами конфигурируем и запихиваем в access-list'ы, которые, в свою очередь, можем привязывать к интерфейсам на in или out, т.е. на вход или на выход. Из коробки, keenetic os идет с набором предустановленных правил. Есть статья в базе знаний, которая должна пролить свет как эти правила работают, какие направления трафика, между интерфейсами с разным security-level, разрешены, а какие запрещены. В конкретном вашем случае, клиенты l2tp сервера имеют доступ в сегмент Home, благодаря настройке "Доступ к сети" в параметрах l2tp-серврера. То есть, наверное, как-то так: Доступ в другие сегменты впн-клиентам не разрешен. Работая напрямую с ipetables, нам бы понадобилось добавить правило в цепочку Forward разрешающее трафик с 172.17.1.0 в 192.168.11.0, входящим интерфейсом было бы что-то типа l2tp+, а исходящим интерфейсом bridge2. Но, используя инструменты доступные в keenetic os, мы в таком виде правило сделать не можем.Мы можем привязывать acl с правилами к интерфейсу на in - это будет аналогом -i (--in-interface) в iptables. И мы можем привязывать acl к интерфейсу на out - это будет аналогом -o (--out-interface). В вашем конкретном случае можно было бы правила привязать на in к интерфейсу l2tp - обозначающему клиента впн-сервера, но в keenetic os привязывать acl к таким интерфейсам не дают. Собственно, остается только привязать нужные правила на out на интерфейс bridge2. Таким образом, мы соорудили что-то типа вот такого в синтаксисе iptables: -A FORWARD -o $bridge2 -s 172.17.1.0/24 -d 192.168.11.0/24 -j ACCEPT

Маркетинг. Между wifi клиентами, наверное, что-то и выжимается

Уже где-то обсуждалось, что у mt7621, если говорить просто, две гигабитные сетевушки. В ультре в одну включен ван-порт (общий sfp и медный), во вторую коммутатор на 4 порта. Лан клиенты работают между собой через свич-чип коммутатора и упираются только в его производительность. Мост же между Wifi и лан коммутатором - через процессор, соответственно скорость физически не может превысить скорость "линка" между процом и коммутаторм, которая составляет гигабит. Точно так же скорость между ван и портом и коммутатором никогда не превысит гигабита в дуплексе.

На вашем роутере, на портах, куда включены оконечные устройства (телвизоры, пк и т.д.), нужно через cli прописать роль iseg. interface <имя интерфейса> role iseg

Вроде, это известная проблема. Но все равно, напишите в поддержку, чем больше обращений - тем быстрее исправят

В настройках wireguard на серверере "Разрешенные подсети" для разных пиров не должны пересекаться.

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

Дописать peer'у в AllowedIPs = 10.8.0.2/32, 192.168.1.0/24 Добавить на сервере маршрут до сети 192.168.1.0/24 через 10.8.0.2 (По идее не понадобится, если вы поднимаете wg с помощью wg-quick, тогда маршрут будет добавляться сам, при наличии сети 192.168.1.0/24 в списке allowed ips) Если на кинетике не меняли secirity-level и он для интерфейса Wireguard у вас public, то добавить разрешающие правила межсетевого экрана для интерфейса Wireguard для входящих.