Werld

В настройках 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› В локальной сети нужное имя будет разрешаться правильно для всех устройств, которым днс-сервером назначен роутер. И тогда не придется городить А-запись с айпишником из частного диапазона на публичных днс-серверах, и не придется отключать защиту от днс ребиндинга.

А если попробовать выключить защиту от DNS Rebinding ( в cli: dns-proxy no rebind-protect ) ?

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

Судя по всему да. KeenDNS имя из переписки с техподдержкой резолвится в ip 31.180.xxx.xxx Название провайдера: OJSC Rostelecom Macroregional Branch South

Вы прям цитируете из той ссылки, что я привел)) Чудес не бывает, раз техподдержка, посмотрев конфиг, сообщила, что порт открыт, никаких правил взапрещающих в межсетевом экране нет, то что остается?

Я думаю ответ прост - блокирует провайдер. Вот есть похожие случаи на ростелекоме https://www.nn.ru/community/techno/internet/rostelekom_blokiruet_podklyucheniya_na_80_port.html

Когда вы пингуете "стыковочный адрес" трафик тоже идет в интерфейс wireguard. Я не понимаю, что вы мне пытаетесь доказать? Маршруты пропадают, с этим я согласен, здесь нужна реакция разработчиков. Но интерфейс не идет в down, говоря, что "было state: up стало state: down" - вы ошибаетесь, в посте выше я вам продемонстрировал.

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

Вот прошло время, маршруты исчезли, пир стал "сереньким" Но интерфейс все равно up: (config)> show interface Wireguard0 id: Wireguard0 index: 0 type: Wireguard description: Waffle interface-name: Wireguard0 link: down connected: no state: up mtu: 1420 tx-queue: 50 address: 10.15.57.2 mask: 255.255.254.0 uptime: 936 global: no security-level: public wireguard: public-key: mAS listen-port: 49112 status: up Интерфейс не выключается, и если в него пойдет траффик, он снова скажет link up, connected yes

Вот специально убрал PersistentKeepalive, на другом конце его тоже нет. Маршруты добавленые через этот интерфейс ушли, как вы и сказали. Но вот я посылаю пинг, и другая сторона мне сразу отвечает, т.к.маршрут в подсеть, обозначенную маской на интерфейсе остается. Так что трафик изнутри пойдет. Вопрос и остается только с пропаданием маршрутов.

Ну а я не это же самое вам и написал? Ладно опустим PersistentKeepalive. Вот вы пишете, что интерфейс идет в down, но это же не так, вам не придется включать его снова. Как только трафик пойдет в него он его прекрасно отработает. Проблема насколько я понимаю именно в этом: "из таблицы попадает маршрут привязанный к этому интерфейсу". Ну так и пишите об этом, а не о том, что интерфейс видите ли идет в down. Никуда он не идет, как я написал выше, он просто сидит и ждет когда снова в него трафик пустите. А вот то, что из таблицы пропадают маршруты, это и связано, насколько я понимаю, с тем, что кинетик судит о состоянии соединения по state, т.к. внутри там все тот же линуксовый netfilter - statefull firewall. Можно ли сделать, чтобы маршрут не пропадал из таблицы при простое интерфейса вот это, как раз, вопрос к разработчикам. Попробуем спросить @Le ecureuil

Это не для "пробития NAT", а как раз для того, чтобы state соединения оставался up, что и приводит к тому, что statefull фаерволлы считают что соединение продолжается. Wireguard,как пишут его авторы, старается оставаться как можно более тихим, это by design.

Вот как раз для этого создатели wireguard предусмотрели опцию Persistent Keepalives, в вебе кинетика она называется "Проверка активности" в настройках пира.

А какой есть повод ее ставить? Чем она настолько лучше текущей в рамках использования в роутере, какие проблемы решает, что нужно все бросать и срочно ее внедрять?

Честно говоря, не совсем понятно чего вы хотите добиться, то у вас openvpn, то вдруг gre. Но если все же вам "нужно что бы адреса не транслировались!", то попробуйте отключить глобальный нат: no ip nat Home Далее включаем обратно нат, но только для интерфейсов, которым он нужен, командой вида: ip static Home ISP - включает трансляцию адресов домашней сети Home в о внешний интерфейс ISP. Если у вас подключение к провайдеру через pppoe, к примеру, то тогда еще команда: ip static Home pppoe0 ит.д включаем нат отдельно только через нужные интерфейсы.

Сдется мне, что snat происходит на микротике, раз пакет прилетает с sourceIP 172.16.16.254, который, судя по вашему описанию, на интерфейсе микротика. Думаю, стоит сделать захват входящих пакетов на интерфейсе l2tp Кинетика, с помощью одноименного компонента. Убедится что на l2tp интерфейс кинетика пакет действительно прилетает с sourceIP 172.16.16.254 и искать проблему на микротике, очевидно какое-то правило snat'a

Сдается мне, вы путаете прошивочный ssh сервер и тот, который устанавливается при развертывании entware. Прошивочный висит на стандартном порту 22. Если прошивочный ssh установлен, то в момент разворачивания entware вешает свой на 222 порт.