Le ecureuil

Конечно все также и останется, пока self-test не пришлете.

Да, порт резервируется сразу при создании интерфейса и он его "держит" до удаления. Другое ничего там не появится, потому не страшно. Насчет secondary port - пусть будет, жить не мешает.

То есть, если выполнить no zerotier network-id, то запись пропадет, а если опять вступить в сеть, то не появляется?

Покажите дамп трафика к роутеру с запросами NTP, посмотрим что отвечает Keenetic. А пока дампа нет, то и "неработащего NTP" нет.

Нужно зайти на Keenetic через telnet, например через putty.

Покажите вывод ip http ssl acme list

connect via спроектирован так, что исходящий трафик он стремится пускать по определенному WAN, но входящий разрешен отовсюду. Для ZT такое поведение, конечно, недопустимо - он лезет везде. Для Wireguard, учитывая, что он сам всегда является инициатором обмена - это ок.

Ну вот смотрите. Приходит DNS запрос из локальной сети от клиента 192.168.1.5 на 192.168.1.1:53 (этот клиент в основной политике) и приходит DNS запрос из локальной сети от клиента 192.168.1.6 на 192.168.1.1:53 (этот клиент в политике Wireguard). Подскажите, как без редиректа второго клиента "разделить" потоки DNS запросов и обслуживать их "персонально"? Сейчас для разделения весь трафик DNS с хоста 192.168.1.6 направляется редиректом в другой порт, а там слушает другой экземпляр DNS-proxy с другими апстримами. Если убрать редирект, они пойдут все в основной.

Нет людских ресурсов для старых веток. Я даже сейчас legacy отложил совсем, потому что нет времени. delta тоже страдает, задержка по паре месяцев.

self-test нужен. Причем в случае с рекурсивным бутстрапом это иногда занимает пару минут, попробуйте подождать.

Покажите-ка self-test, возможно UPnP 443 порт прокидывает.

Это на последней 4.2 такое?

Реализовано открытие порта и bind только на актуальный адрес. Будет доступно уже в следующей 4.2. Давайте проверим, возможно удастся обойтись и без команды.

Пробовал много раз, не воспроизводится. Нужна дополнительная информация.

А как вы прописываете DNS в "не основную" политику?

А вы резервный канал сделали security-level private с другой стороны (на сервере)? А включили на нем NAT? Проще вам еще один WG между точками поднять, но только для интернета - и его уже сделать private, и на нем сделать NAT.

Ok, это тоже приделаем.

Прошу как можно раньше на этапе драфтов тестировать и сообщать, "узкие" фичи кроме как силами энтузиастов протестировать невозможно.

Исключительно маркетинговое дело провайдеров. Они хотят дешево от производителя, а самим наценку конскую в карман класть. Нам это невыгодно. К технической части имеет отношение в пятой-десятой степени.

UDP поправлен.

Это, скажем так, известная особенность. Альтернативой ей может быть просто блокировка всего DNS в политике. Предложите ваше видение, как dns-override должен сосуществовать с политиками.

show ip hotspot

Понял, спасибо, будем работать.

А разве connect via не спасает?

You can obvoiusly speedup integration by showing us opensource pure-C implementation of DoQ proxy. Go is not an option. Вы можете ускорить интеграцию, показав нам открытую реализацию DoQ-прокси на C. Go не подходит.