Le ecureuil

@snark в self-test не включен debug на OpenConnect0.

Пока еще нет.

Вам все то же самое - включить debug и снимать логи.

Попробуйте с interface OpenConnect0 debug снять self-test.

Спасибо за репорт! Пока можете попробовать "почнить" через установку DNS руками: скажем 8.8.8.8 или 1.1.1.1 именно на 6to4 подключении, скорее всего поможет. Туда же и IPv6 можно добавить: 2001:4860:4860::8888 2001:4860:4860::8844

conform всегда ставится автоматически, если нет другой политики. Это нормально и правильно. А вот то, что не работает запрет доступа - это другое, conform по идее этому ортогонален. Это будем чинить.

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

Открыл, в следующей 4.2 будет.

Готово, в следующей 4.2 будет.

У нас connect via толком не умеет в IPv6, потому дырку откроем, но bind() на ipv6-адреса все равно не будет работать.

Если не хочется от а до я, то чуть обождите - он скоро появится в веб в таком же простом виде, как и SSTP.

Была обнаружена проблема с truncated-битом при рекурсивном резолвинге, в следующих версиях 4.1 и 4.2 будет поправлено.

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

K PPTP подключается клиент из локалки, или тот же самый кинетик?

Пока никак, будет чуть позже реализовано.

Конечно все также и останется, пока 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 нужен. Причем в случае с рекурсивным бутстрапом это иногда занимает пару минут, попробуйте подождать.