Albram

Тот же самый кинетик. Ещё момент, если PPTP серверу присвоить адрес из подсети Wireguard интерфейса кинетика (например, интерфейс Wireguard 10.0.0.1, а PPTP сервер 10.0.0.2), то PPTP соединение устанавливается. Я так понимаю, устанавливается оно из-за отсутствия NAT на пути протокола GRE.

Приветствую всех. На Keenetic Ultra (KN-1811 KeenOS 4.1.3) поднято Wireguard подключение к внешнему vds серверу, это подключение отмечено "использовать для выхода в Интернет", и оно работает. Нужно через этот wireguarg туннель подключиться к PPPTP серверу, находящемуся на другом внешнем vds сервере. Сейчас ppptp подключение не устанавливается. Подключение на tcp порт 1723 сервера ppptp проходит, но на gre пакеты ответа нет. Без wireguard, напрямую, ppptp подключение поднимается. Т.к. доступа к ppptp серверу нет, то для проверки поднял ppptp сервер в локальной сети на другом роутере, результат тот-же: при подключении через провайдерское pppoe подключение соединение ppptp поднимается, при подключении через wireguard - нет, т.к. на ppptp сервер не приходят gre пакеты. Лог подключения через wireguard выглядит так: 95.xxx.xxx.xxx - адрес PPPTP сервера 172.16.0.2 - адрес интерфейса Wireguard на кинетике Захват пакетов во время попытки подключения выглядит так: Здесь подключение через другой интерфейс Wireguard, с адресом 10.7.0.3, но результат тот же. Как я понимаю, причина в том, что протокол GRE не может пройти через NAT. Но решить эту проблему пока не удалось. Буду благодарен за советы.

Не было никакой хрени))) Ввел имя, если свободно, то получает сертификат (не всегда моментально, но недолго). Вы может в настройках уже чего-то накрутили, что мешает получению. P.S.: домен там, надеюсь, не свой вводите?)

Зачем вы всё одну кучу сваливаете?:) У меня, например, у кинетика тоже есть зарегистрированное имя keendns, но я использую своё доменное имя. Просто не трогайте keendns имя, если оно вам не нужно, и всё.

А в чем проблема в этом случае? У вас DNS запись есть, т.е., если в конфиге клиента сервер указан по имени, то имя отрезолвится в адрес, и пакеты пойдут на этот адрес (а там ваш кинетик).

Тогда зачем вам эти пляски с DDNS, не понимаю. У вас сервисы, к которым нужен доступ по доменному имени, за кинетиком находятся?

Автор пишет: "У меня есть wildcard ssl сертификат на мой домен", т.е., если я правильно понимаю, доменное имя уже есть, и использовать планируется именно его.

А зачем вам DDNS в этом случае? У меня похожая картина, просто открыл нужные порты на нужные сервисы, а в этих сервисах настроены нужные сертификаты. И никаких DDNS. Или вам доступ нужен только к веб интерфейсу кинетика, а не к сервисам, расположенным за кинетиком?

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

Скорее всего не установлен пакет smartmontools-drivedb Попробуйте его установить: opkg install smartmontools-drivedb Потом проверьте вывод smartctl -a /dev/sda

А если так: smartctl -a -d sat /dev/sda

Приветствую всех. К портам 3 и 4 KN-1811 (версия ОС 4.0.5) подключен управляемый коммутатор TP-Link TL-SG105PE, на обоих сторонах включена агрегация, и в общем-то всё работает, до момента выключения и последующего включения питания. После включения и загрузки TL-SG105PE не получает IP адрес от KN-1811. В логе роутера видно что он отвечает на запросы коммутатора, но коммутатор их игнорирует и шлёт повторные запросы к DHCP серверу. А игнорирует он их из-за неверной контрольной суммы: Видимо в агрегированном VLAN отключен подсчет контрольной суммы исходящих пакетов. Но, если перезагрузить коммутатор, то он получит адрес и будет нормально работать. Но перезагружать его после отключения и включения не всегда есть возможность. В мануале не нашел команд связанных с контрольной суммой пакетов. Как решить проблему?

Можно прописать на кинетике, который является контроллером mesh, статический маршрут в подсеть микротика, и в firewall микротика разрешить пакеты из подсети кинетика. У меня так работает, только в обратную сторону, микротик подключен в кинетик, который является контроллером mesh.

На скрине Air подключен не по кабелю, а по wifi, причем, с довольно низкой скоростью.

В общем, не помогло назначение профиля DNS, сегодня опять клиенты получают LL ipv6 адрес ретранслятора, а не контроллера. Интересно как с этим в версии 4, как-нибудь проверю.