Le ecureuil

Вы же его можете выключить в любой момент.

Это невозможно, поскольку очень много вещей в ПО и в сборке на серверах завязано на это.

На мой взгляд самые доступные устройства с "неограниченной" флешкой - это DSL/DUO. Там по 128 Мбайт + проц мощнее, чем 7628. Все же устройства на 7628 - это entry-level. Да, они работают, но поскольку _большинству_ нужен только доступ в Интернет + WiFi, то именно вокруг этих параметров и крутится маркетинг. Для понимающих жизнь людей линейка выглядит так: Start (только интернет и все) -> Air/Extra/DUO (двухдиапазонник начального/среднего уровня) -> 1910/DSL/1010 (когда нужен упор не на WiFi) -> 1810.

Ждите, исправление уже в тестировании

Хотя бы версию ПО до self-test показать, ну и сказать про тип доступа: прямой али через облако.

Наверное в будущем нужно для dot/doh будет приделать привязку к домену, сейчас таковая не поддерживается (считалось, что необходимости в этом не будет). Давайте тогда отложим ненадолго это.

Работаем над этим.

Спасибо за подсветку проблемы. Сейчас этот функционал на самом деле работает, но провайдеры перехватывают нешифрованные dns и тупо их блокируют (в том числе и запросы в зону .lib). Потому нашел вам кучку opennic-серверов, которые умеют dot и doh. Добавляйте их к обычным dot/doh серверам, и все будет работать: https://servers.opennic.org/edit.php?srv=ns10.de.dns.opennic.glue https://servers.opennic.org/edit.php?srv=ns12.nh.nl.dns.opennic.glue https://servers.opennic.org/edit.php?srv=ns8.he.de.dns.opennic.glue https://servers.opennic.org/edit.php?srv=ns31.de.dns.opennic.glue Прямо сейчас не поддерживаются DoH-сервера с указанием порта в uri, но в следующих релизах это будет поправлено.

Да, ситуация воспроизвелась, но, формально говоря, это не ошибка - это следствие работы фильтра. При включенных интернет-фильтрах у нас включается блокировка транзитного DoH и DoT - чтобы никто не смог убежать наружу сквозь фильтры. При этом adguard проверяет себя через https-запрос на 443 порт на свои же домены и сервера, используемые для DNS - а мы этот транзит блокируем, потому что считаем его "попыткой пробежать мимо". Вот он и не показывает сам себя. Потому призываю всех не беспокоиться, все работает как заявлено, и даже еще жестче в плане блокировки утечек

Все время забываем Молодцы, что напомнили - постараемся сделать.

DNS на конкретное соединение не игнорируется - именно по причине, озвученной выше. Можно еще его даже до домена ограничить.

Если это возможно, то полный сброс и попытаться опять настроить. Если не залезет - то перегенерить ключи и сертификаты, чтобы занимали меньше места.

Попробуйте в официальную техподдержку обратиться.

Да, возможно. Описано все в cli guide (ищите для версий 2.05 и младше).

Неправильно. Есть firewall, а есть проброс портов / протоколов. Это разные вещи, на разных вкладках в web настраиваются.

Можно, но это не всегда возможно. Плюс в таком случае обычно вообще проще использовать L3-туннель, а не L2.

Попробуйте отключить discovery. Видимо "кривое" устройство на запрос любого IP отвечает, что он принадлежит ему.

Похоже на проблемы с физикой на линии. Проверьте кабель, насколько он хорошо подключен. Можно еще провайдера попинать.

Он работает немного не так, как этого ожидают пользователи. Потому и не выведен.

Странно. Напишите в техподдержку, там будем исправлять.

Давайте через техподдержку. Они посмотрят, что может быть настроено не так.

При включении изменения TTL ускорители отключаются - это нормально.

Там же есть рекомендация добавить нативные IPv6 DNS. С ними также плохо работает? Или на клиентов прилетает LL?

Отключить dns-proxy или сделать dns-proxy override.

В целом будет еще хуже по скорости.