Le ecureuil

Нужно зайти на 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 должен сосуществовать с политиками.

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

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

Пришлите self-test когда не работает, и когда работает.

Провайдеры выдают что подешевле и одной ногой сделанное, и наплевать на качество.

На новом draft таймауты немного подправлены, больше быть не должно. А вот про UDP - поправлю.

Да, не хочу туда лезть просто так.

219.100.37.219 отвечает connection refused - соединение отклонено. Телепаты тоже не могут вам сказать большего.

Купить устройство с opkg Или пользоваться Keenetic SDK