Werld

Ну тогда могу только развести руки. На самом устройстве никакого фаервола нет? Может там разрешен доступ только из той же подсети , что и само устройство, и поэтому оно на себя пакеты с адресом источника из сети 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 для входящих.

Ну почему никто не читает базу знаний? Читаем статью https://help.keenetic.com/hc/ru/articles/360000969039-FTP-сервер, видим выделенное жирным: Важно! При использовании авторизации клиенту нужно настроить права доступа к папкам USB-накопителя, иначе не получится подключиться к FTP-серверу. Кстати, в стандартный набор компонет "Контроль доступа к папкам" не входит, т.е. вы сами его доустановили а настроить не подумали. Подробнее здесь https://help.keenetic.com/hc/ru/articles/360000797340

Это предположение. У меня нет 12 андроида чтобы попробовать. Но по логике вещей это ikev2/ipsec mschapv2 на скринах должно быть как раз то что нужно, в кинетике используется сервер ikev2/ipsec с аутентификацией клиента eap-mschapv2.

Туда Keendns доменное имя вашего роутера, на которое получен сертификат, например xxx.keenetic.pro

По идее, используя вариант ikev2/ipsec mschapv2 вы должны суметь подключиться к кинетику с настроенным Vpn-сервером IKEv2

@Sereja Smirnoff В этой статье, на которую вы ссылаетесь просят выключить "NAT для клиентов" в настройках l2tp/ipsec сервера. Попробуйте включить эту галочку и снова проверить.

Читаем внимательно вверху вашего скрина: Чтобы добавить правило межсетевого экрана, выберите из списка интерфейс, на котором будет отслеживаться входящий трафик... Т.е. через веб-интерфейс мы создаем правила для входящего трафика для интерфейсов. Создавать правила для исходящего трафика можно через cli. Подробнее по ссылкам: Межсетевой экран Как реализован межсетевой экран? Примеры использования правил межсетевого экрана

Для примера ситуация. Хотим ограничить удаленный доступ к веб-интерфейсу, разрешив доступ только определенным айпишникам. Включаем удаленный доступ. Далее создаем два правила в межсетевом экране для интерфейса провайдера: И все работает как нам хотелось бы. Но если к роутеру подключается впн клиент по ikev2 ipsec, то на нем в таком случае не открываются никакие веб-страницы. Т.к. созданные правила межсетевого экрана на интерфейсе провайдера применяются и для входящих ipsec подключений. Самым простым решением было бы написание более конкретного правила фаерволла, где в графе "Адрес назначения" был бы адрес роутера на интерфейсе провайдера. Но зачастую на интерфейсе провайдера мы имеем динамический ip-адрес, а значит прописывать вручную текущий адрес на интерфейсе бесполезно, т.к. после переподключения айпишник будет уже другой. Поэтому и хотелось бы иметь возможность в графе "IP-адрес назначения" выбрать "Адрес роутера на этом интерфейсе", чтобы айпишник на интерфейсе определялся автоматически и создавалось правило в нетфильтре уже с соответствующим адресом. По типу того, как это сделано, когда мы задаем правило вида: ip static Home ISP, а в нетфильтре при этом создается src: 192.168.1.0/24, dst: 0.0.0.0/0, in: "*", out: "eth3", proto: "any"; "ndmmark" match, value: 0x4/0x4, invert: 0x0; SNAT, address: x.x.x.x Т.е. роутер сам подставляет адрес интерфейса ISP в правило нетфильтра. Описанный пример не единственный, когда было бы полезно иметь возможность создавать более конкретные правила в фаерволле, выбирая "Адрес роутера на этом интерфейсе" в графе "IP-адрес назначения". Поэтому прошу разработчиков рассмотреть возможность реализации такого функционала. Спасибо.

Вы уже используете обратный прокси на роутере. "На роутере назначен доступ из Интернет к веб-приложениям домашней сети site1.dom.keenetic.link и site2.dom.keenetic.link" - это оно и есть. Вам лишь нужно прописать вышеприведённые команды в cli роутера, чтобы заголовок "host" не перезаписывался.

Так может проблема в том, что сервер не шлёт никакие данные после перехода, а ждёт их от клиента, который не знает нового ендпоинта? Попробуйте включить keepalive на стороне сервера для пира клиента. Тогда сервер будет периодически слать пакеты клиенту, и при смене ip это позволит клиенту увидеть новый адрес.