Werld

Уже написал выше. У вас нет маршрута в сеть за кинетиком, это обьясняет почему пингуется с самого кинетика, а из сети за ним - нет. Я думал у вас все маршруты настроены, поэтому и писал про межсетевой экран. Нужен маршрут на дачном роутере до сети 192.168.1.0/24 через интерфейс "ppp5"

а где маршрут в подсеть за кинетиком? Маршрут до 192.168.1.0/24 У ваас на картинке есть только до 192.168.1.1, поэтому то с кинетика вы пингуете, а из сети - нет

Кто знает, что там на этом Xiaomi, может там Input на vpn интерфейсы разрешены, а forward в локальную сеть за ним - нет.

Приведенный маршрут, должен быть на Keeneticе не на модеме. И правила фаерволла на самом роутере, что поднимает тоннель.

В межсетевом экране роутера, на котором поднят туннель до домашнего keenetic Air, нужно разрешить входящие соединения для pptp интерфейса, чтобы все работало

Маршрут должен быть такого вида:

Да, извините. Я скопипастил команду и забыл изменить имя акла. Разумеется, раз создали акл l2tpusers, то и привязывать нужно его))

Перечисленные Вами действия не ведут к решению проблемы, поэтому их нужно отменить, т.е. все правила, маршруты, все что крутили руками уберите как было. Далее идем в cli и выполняем следующие команды: access-list l2tpusers - создали access list permit ip 192.168.1.200 255.255.255.248 10.10.10.0 255.255.255.0 - добаили в созданный acl правило для клиентов l2tp сервера. У Вас 192.168.1.200-205, т.е. ближайшая подсеть /29. А вообще лучше впн клиентам назначить адреса из сети отличной от домашнего сегмента. exit - вышли из подгруппы команд access-list в основной конфиг interface openvpn0 ip access-group myacl out - привязали созданный acl к интерфейсу openvpn. Тут Вам нужно быть внимательным, т.к. название вашего openvpn интерфейса может отличаться от openvpn0 system configuration save - сохраняем проделанные изменения

Я, конечно же, писал о ситуации, когда терминал уже будет в режиме бриджа

Прямой доступ с серым ip невозможен. А при белом ip есть варианты впн поинтереснее sstp

Да, именно так, динамический ip, который выдавался на wan интерфейс rt-gm3, будет присвоен вашему кинетику. Если этот ip адрес белый, хоть и динамический, то вы сможете использовать KeenDNS с прямым доступом, а значит любой поддерживаемый кинетиком тип vpn. Если этот ip серый, то, как вам выше подсказали, либо использовать sstp, либо приобретать у провайдера белый ip.

Обратиться к провайдеру с просьбой перевести терминал rt-gm3 в режим бриджа.

Подробнее и конкретнее опишите ситуацию. Не очень понятно, кто и куда подключается и к каким локальным ресурсам нет доступа. Скорее всего все решается настройками

https://help.keenetic.com/hc/ru/articles/360005236300-Сегменты-сети В конце статьи вы найдете как разрешить доступ между сегментами.

В настройках l2tp/ipsec сервера поставить галочку "nat для клиентов". В настройках wireguard клиента поставить галочку "Использовать для выхода в Интернет". После выставления этой галочки, убедиться на странице "Приоритеты подключений", что wireguard соединение ниже приоритетом чем основное соедиенение с провайдером. После проведенных манипуляций все должно заработать. Для l2tp/ipsec сервера рекомендую использовать диапазон не из пула домашней сети.

А если посмотреть в сторону команды interface ipsec encryption-level (см. в cli manual). Там есть разные предустановленные "уровни шифрования". Думаю, стоит попробовать что-то типа interface l2tp0 ipsec encryption-level strong В наборе "strong" только AES128 и AES256, 3DES отключен. Не уверен на 100%, что эти уровни применяются к созданным через веб l2tp/ipsec интерфейсам, но попробовать определенно стоит.

На первом роутере (за которым сеть 192.168.10.0/24) необходимо добавит маршрут вида: На дальнем роутере (за которым сеть 192.168.11.0/24) необходимо добавить правило в межсетевой экран для Wan интерфейса:

Выключать не надо.

Смотреть в сторону mtu. Автоподстройка tcp mss на pptp интерфесе включена?

Я так понимаю в настройках vpn сервера на GigaIII для впн-клиентов доступ к сети указан как раз Home? Я подобную задачу решал следующим образом: создаем правила в фаерволле разрешающие впн-клиентам доступ в подсеть 192.168.2.0/24 и навешиваем эти правила на сегмент LAN2 на out. Т.к. правила надо вешать на out, то делать это можно только через сli. Команды следующие: Создаем ACL access-list myacl Далее команды добавляют в созданный акл нужные правила, т.к. впн-клиенты получают у вас 172.16.2.х, а в вашем новом сегменте адресация 192.168.2.0 /24 : permit ip 172.16.2.0/24 192.168.2.0/24 Далее команда exit - это мы выходим из подгруппы комманд access-list в основной конфиг. Теперь нам осталось привязать созданный ACL к нужному бриджу. Основной Home сегмент - это Bridge0, гостевой - Bridge1, допустим ваш сегмент LAN2 - это Bridge2. interface bridge2 ip access-group myacl out И сохраняем изменения: system configuration save

А не блокирует ли случаем провайдер вам 80 порт, борясь тем самым с любителями держать web-серверы дома? Поставьте обратно свой предыдущий роутер, чтобы это проверить, возможно, блокировка началась не давно.

Одинарное нажатие запускает wps на точке доступа 2.4 ГГц, двойное нажатие запускает wps на точке доступа 5 ГГц. Так как двухдиапазонные модели соединяются в мэш на диапазоне 5 ГГц, то и нажимать на обоих устройствах нужно кратковременно два раза , как и сказано в мануале, что вы процитировали. После соединения устройств, можно будет на контроллере произвести захват экстендера. После захвата экстендер будет раздавать те же сети в тех же диапазонах, что и контроллер.

К слову, реализовать необходимый вам сценарий возможно, просто сделав статическую днс-запись на самом роутере. В cli: ip host ‹domain› ‹address› В локальной сети нужное имя будет разрешаться правильно для всех устройств, которым днс-сервером назначен роутер. И тогда не придется городить А-запись с айпишником из частного диапазона на публичных днс-серверах, и не придется отключать защиту от днс ребиндинга.