qmxocynjca

Да, извиняюсь, прочитал вскользь, упустил что с ноутбука доступ есть и конечное устройство совсем не такой же роутер. Попробуйте включить interface debug, возможно будет что-нибудь интересное в выводе. 1. Идёте на страницу ввода команд роутера: http://192.168.1.1/a 2. Вводите: interface OpenConnect0 debug Смотрите в логах что-нибудь интересное. Если ничего интересного не увидите, то путь в официальную техподдержку.

Failed to connect to host: vpn.xxxxx.ru Не факт что в этом дело, но лучше используйте более безобидные субдомены. Проявите фантазию, не нужно мастерам TLS парсинга так упрощать жизнь 🤭. Возможно как-то изменился секрет у OC сервера, если у вас включен камуфляж. Проверьте что он совпадает. В любом случае, если доступ через основной домен к устройству есть (не через OC), то надо разбираться дальше где затык.

(config-subnet)> dns-server Usage template: dns-server (({address1} [{address2}]) | disable) В общем случае жмёте Tab в CLI и смотрите как выглядит подсказка, оттуда берёте имена переменных. В этом случае думаю надо в "dns-server" передавать объект { "address1": "..." }. { "ipv6": { "subnet": { "Default": { "dns-server": { "address1": "2001:4860:4860::8844" } } } } } Можно через devtools браузера смотреть как именно это делает веб роутера, там сразу будет понятно что куда.

А ведь можно написать на go тестовый фреймворк, законнектить его с кинетиком по API, симулировать любые конфигурации dns, спрашивать чего роутер там нарезолвил, какие списки наполнил и куда что роутит в реальности. Эх, мечты, мечты... Мне даже интересно как устроен процесс тестирования в компании сейчас. Не хочу никого обидеть - все мы люди, но кажется есть куда расти, товарищ мистер @admin!

@slomblobov есть какие-нибудь подвижки по применению однострочного патча на avahi из моего поста выше? в 5.1 альфу катните плиз.

Вижу пошла ветка 5.1, где можно пока всякое вертеть. Если будет возможность, вот этот фикс накатите плиз: Index: avahi-0.6.31/avahi-daemon/static-hosts.c =================================================================== --- avahi-0.6.31.orig/avahi-daemon/static-hosts.c +++ avahi-0.6.31/avahi-daemon/static-hosts.c @@ -138,7 +138,7 @@ static void add_static_host_to_server(St p = (h->address.proto == AVAHI_PROTO_INET && config->publish_a_on_ipv6) || (h->address.proto == AVAHI_PROTO_INET6 && config->publish_aaaa_on_ipv4) ? AVAHI_PROTO_UNSPEC : h->address.proto; - if ((err = avahi_server_add_address(avahi_server, h->group, AVAHI_IF_UNSPEC, p, 0, h->host, &h->address)) < 0) { + if ((err = avahi_server_add_address(avahi_server, h->group, AVAHI_IF_UNSPEC, p, AVAHI_PUBLISH_NO_REVERSE, h->host, &h->address)) < 0) { avahi_log_error ("Static host name %s: avahi_server_add_address failure: %s", h->host, avahi_strerror(err)); return; }

👍 https://github.com/publicsuffix/list/pull/2713 И тоже самое для netcraze.* доменов, пожалуйста.

Хотите сказать, что даже с этой выключенной настройкой устройства обновляются при привязке к мешу? Она в http://192.168.1.1/wifiSystem/settings upd: ага, увидел выше. Ну это провал, согласен.

Правила-то может и прописаны, но включены ли они? Я пару раз о такое спотыкался.

На 5.0.4 аналогично через пару дней CPU начинает уходить в потолок. Очень похоже на классический n^2, когда на мелких объемах баг не заметен, но с ростом тормозить начинает очень сильно.

Включил тут на свою голову этот сервис, дабы роутер по-умному делил канал между клиентами, но тоже постоянно вижу похожую дичь при смешных нагрузках (5-10мбит), т.е. дело явно не в большом трафике. Один раз дошло до того, что веб даже не мог открыть, пришлось ребутать через telnet. Девайс NC-1812, канал всего 100мбит. По началу оно работает, но через какое-то время начинается такое безобразие.

@slomblobov понимаю что приоритет вообще нулевой, но может вот этот фикс накатите хотя бы? https://github.com/avahi/avahi/issues/40#issuecomment-531047292 Он влияет только на файл с кастомными хостами, который Кинетик пока никак не создаёт. Я его попробую через entware подсовывать и погляжу на сколько это работоспособно.

Хорошее дело! Терминал в веб через ttyd поднимается в один вызов, это я тоже осилил Более интересный вариант - запустить ndmc через авторизацию по куке или как-нибудь еще без ввода явного пароля. Может придумаете/доработаете в прошивке? Тогда ttyd вполне и в нативный веб можно дотащить, было бы шикарно.

Что-то грустно. Даже с mws encapsulation не работает?

Такое ощущение что DNS ответы парсятся на сколько это возможно, и если что-то парсеру не нравится то в логику наполнения списков они не попадают. Вручную nslookup www.youtube.com тоже как-то не ахти наполняет списки сейчас. Даже не знаю что ещё сказать... Ждём, надеемся, верим.

На 5.0.3 всё ещё какая-то явная проблема. После перезагрузки роутера включаю запись на chrome://net-export, иду на youtube.com, вижу фигу. В логе net-export вижу UDP DNS запрос к роутеру, по dependency явно виден ответ от роутера и следующим за ним коннект к 173.194.222.198:443. При этом 173.194.222.198 не появился в show object-group fqdn. DNS на роутере настроен в режиме интернет-фильтра где в системном профиле заданы несколько DoT, включая 8.8.8.8. Устройство точно использует системный DNS профиль и дефолтную политику. Ответ включал именно этот адрес: HOST_RESOLVER_DNS_TASK_EXTRACTION_RESULTS --> results = [ { "domain_name": "wide-youtube.l.google.com", "endpoints": [ { "address": "173.194.222.198", "port": 0 } ], "hosts": [], "query_type": "A", "source": "dns", "strings": [], "timed_expiration": "13410556011478764", "type": "data" },

@Le ecureuil похоже есть проблема с обработкой DNS TCP запросов. Хром в какой-то момент вместо UDP может использовать TCP на 53 порт. Я вижу что зарезолвленные IP не наполняют списки в этом случае. Воспроизводится так: 1. Добавляем список с единственным доменом example.com 2. Делаем nslookup set vc example.com www.example.com Видим что example.com наполнился IP адресами в show object-group fqdn, а www.example.com уже нет. Делаем nslookup www.example.com (в UDP режиме), и видим что IP адреса появились у www.example.com. Конец.

На 5.0.2 улучшений нет, к сожалению. Всё так же некоторые IP идут мимо.

Присоединяюсь к вопросу. Точно так же думал что создам отдельный сегмент со всеми VPN-юзерами, а правилами уже разрешу куда кому можно, но по факту это либо не работает, либо правила нужны какие-то не очевидные. Я ещё не пробовал вариант с указанием диапазона адресов в sstp/oc сервере в той же сети что и сегмент. Это вроде как должно работать, и может даже правила тогда тоже заработают. Если у кого есть время и желание, попробуйте, пожалуйста.

Кто-то пользуется usque сейчас? Работает? У меня пинги через туннель идут, но "curl --interface opkgtunX ip.wtf" висит и ничего не происходит. MTU покрутил - толку не дало. upd: создал отдельный opkgtun, там завелось. До этого пытался через тот же что был в использовании на awg до этого, видать что-то не стыковалось.

@Le ecureuil почему-то openconnect URL не отдаёт всю цепочку сертификатов, как это происходит в обычном URL. * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (OUT), TLS alert, unknown CA (560): * SSL certificate problem: unable to get local issuer certificate Посмотреть на цепочку можно так, там видно что отсутствует один серт: # вот это не работает без явного указания -k/--insecure curl -w %{certs} -4 -k https://abcd.server.netcraze.link/?secret > cacerts_bad.pem # тут всё норм, curl не ругается curl -w %{certs} https://server.netcraze.link/ > cacerts.pem Сертификаты на системе из ca-certificates_20250419_all.deb. Обойти это можно, но кажется что это баг.

Пытаюсь повесить ping-check на Proxy интерфейс, использую для проверки mode connect, хост доступен, ping-check успешно переводит соединение в рабочий режим, но в логах начинает сыпаться такое. Пока отказался от ping-check. Ноя 26 19:08:34 Proxy0 0x7f909217c0 socks5 session connect Ноя 26 19:08:34 Proxy0 0x7f909217c0 socks5 client connect Ноя 26 19:08:34 Proxy0 0x7f909217c0 socks5 client connect

Не уверен что это будет работать в реальности. На айфоне, например, нельзя выбрать тип MAC до авторизации в сети. Замкнутый круг получится. upd: а нет, нашёл где можно менять. Но не очень очевидно.

Да, с сохранением маршрутов какая-то беда. Там то одно удаляется из конфига, то другое, когда пытаешься добавить несколько.

Гляньте, пожалуйста, в startup-config, сколько у вас уникальных двухбуквенных значений ft mdid <...> найдётся?