qmxocynjca

@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

Смотрите где накосячили, возможно ENABLED=no прописали и забыли. В этом случае скрипт вот так ничего не делает прям как у вас. Может что-то ещё сломали, постарайтесь разобраться просто сравнив два файла S21 и S22.

Никак. После выкл/вкл интернета оно вроде само поднимается. Но если надо, то логично в iflayerchanged.d отлавливать ipv4==running на интерфейсе провайдера и дёргать рестарт необходимым сервисам в /opt/etc/init.d.

вот так делать не надо. путь должен быть в PATH ниже, а здесь должно быть только имя экзешника, иначе логика по остановке/перезапуску работает некорректно. Починили в итоге? В чём прикол был?

Проверьте по startup-config что OpkgTun1 настроен по аналогии с OpkgTun0, но при этом IP адрес должен быть другим. У меня работает сетап с двумя интерфейсами корректно. interface OpkgTun0 description awg-go-warp security-level public ip address 172.16.0.2 255.255.255.255 ip mtu 1280 ip global 7281 ip tcp adjust-mss pmtu ping-check profile warp up ! interface OpkgTun1 description awg-go-warp1 security-level public ip address 172.16.0.3 255.255.255.255 ip mtu 1280 ip global 3640 ip tcp adjust-mss pmtu ping-check profile warp up ! Бинарь amneziawg-go симлинками заведен на amneziawg-go0 и amneziawg-go1, чтобы при остановке одного не останавливался другой. Скрипт для запуска первого бинаря. Второй думаю осилите сами: #!/bin/sh ENABLED=yes PROCS=amneziawg-go0 AWG_INTERFACE=opkgtun0 ARGS="$AWG_INTERFACE" PREARGS="" DESC=$PROCS PATH=/opt/sbin:/opt/bin:/opt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin post_cmd() { COUNTER=0 LIMIT=10 while [ "$COUNTER" -le "$LIMIT" ]; do if awg setconf $AWG_INTERFACE /opt/etc/awg_$AWG_INTERFACE.conf 2>/dev/null; then logger -t "$0" "Successfully configured $AWG_INTERFACE" break fi logger -t "$0" "Failed to configure $AWG_INTERFACE, retrying... ($COUNTER/$LIMIT)" sleep 1 COUNTER=`expr $COUNTER + 1` done if [ "$COUNTER" -gt "$LIMIT" ]; then logger -t "$0" "ERROR: Failed to configure $AWG_INTERFACE after $LIMIT attempts" fi } POSTCMD="post_cmd"

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

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

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

Получилось через CLI задать ft mdid на нужных точках, т.е. диапазоны одной сети объединились, но выглядит так что максимум может быть 3 уникальных значения ft mdid. Если больше - ошибка.

5.0.1. Можете проверить что в основном и доп сегменте у вас действительно в веб показывает что роуминг включен и на 2.4 и на 5ггц? Я могу в одном сегменте включить на оба диапазона, а в других только что-то одно сохраняется - или 2.4 или 5. Некоторые сети явно с отдельными именами, но у меня меш и задача иметь роуминг между точками.

Есть три сети, в каждой по два диапазона. Включить FT на всех сетях между всеми диапазонами нельзя что ли? Какие-то ограничения железа или что это? Отваливается с ошибкой, когда пытаюсь включить FT на более чем 3-х WiFi интерфейсах: mtkiappd too many AP interfaces (3)

В списке ретрансляторов надо нажать галочку на нужном и появится кнопка настроек. Это очень неочевидно, сам обнаружил буквально сегодня.

На контроллере в настройках ретранслятора можно менять привязку порта к сети.

Ситуация: 1. DoT DNS1, указано ходить через ISP1. 2. DoT DNS2, указано ходить через ISP2. 3. Есть отдельная политика только с ISP2. Ожидаю что в этой политике будет использоваться только DNS2, а по факту используются оба. Так задумано или что-то не работает?

5.0.1. Включаю SNTP, жму сохранить, обновляю страницу, получаю: По ощущениям сервер работает, порт 123 открыт, запросы к нему обрабатываются.

Чтобы браузеры не шарили хранилище между a.keenetic.link и b.keenetic.link, есть специальный лист, в который можно добавить верхний домен. Браузер будет использовать это для разделения сайтов и их хранилищ по субдоменам. Пожалуйста, озаботьтесь этим и добавьте все верхние домены, которые используются в Keen/NetcrazeDNS в этот лист. Это должен делать владелец доменов. Сейчас ситуация достаточно неприятная, когда сервисы с одного субдомена внезапно могут пошарить свои данные на другом субдомене, т.к. браузеру никто не сказал что это по сути динамический DNS, который нужно разграничивать. https://publicsuffix.org/ https://publicsuffix.org/submit/

@Le ecureuil К первоначальной проблеме: воспроизвелось, но теперь уже на 5.0.1. Трейс по интересующему домену опять не ведёт куда нужно. Делаю запрос с устройства в дефолтной политике: nslookup www.youtube.com Server: ... Address: 192.168.1.1 Non-authoritative answer: Name: wide-youtube.l.google.com Addresses: 2a00:1450:4010:c03::c6 209.85.233.198 Aliases: www.youtube.com youtube-ui.l.google.com Адрес не появляется в show object-group fqdn для интересующего домена: "fqdn": "www.youtube.com", "type": "runtime", "deadline4": 12779, "deadline6": 1531545, "fail-counter4": 0, "fail-counter6": 0, "last-external": 88586, "last-list-changed": 88586, "parent": "youtube.com", "ipv4": [ { "address": "74.125.131.198", "ttl": 249, "last-updated": 79343 }, { "address": "74.125.205.198", "ttl": 162, "last-updated": 89695 }, { "address": "108.177.14.198", "ttl": 271, "last-updated": 91759 }, { "address": "142.250.150.198", "ttl": 278, "last-updated": 94667 }, { "address": "142.251.1.198", "ttl": 260, "last-updated": 87750 }, { "address": "173.194.221.198", "ttl": 218, "last-updated": 88125 } ], "ipv6": [ { "address": "2a00:1450:4010:c02::c6", "ttl": 147, "last-updated": 46964 }, { "address": "2a00:1450:4010:c0a::c6", "ttl": 285, "last-updated": 88109 }, { "address": "2a00:1450:4010:c0e::c6", "ttl": 135, "last-updated": 82176 }, { "address": "2a00:1450:4010:c0f::c6", "ttl": 151, "last-updated": 91653 }, { "address": "2a00:1450:4010:c1c::c6", "ttl": 250, "last-updated": 94667 }, { "address": "2a00:1450:4010:c1e::c6", "ttl": 206, "last-updated": 87773 } ] dot прокси на роутере отвечает нормально: В конфиге ndnproxy: dns_server = 127.0.0.1:40500 . # 77.88.8.8:853@common.dot.dns.yandex.net $ nslookup www.youtube.com 127.0.0.1:40500 Server: 127.0.0.1 Address 1: 127.0.0.1 localhost Name: www.youtube.com Address 1: 209.85.233.198 lr-in-f198.1e100.net Address 2: 2a00:1450:4010:c03::c6 lr-in-f198.1e100.net Другие адреса добавились, а этот не хочет. Что примечательно, ipv6 адрес тоже отсутствует в списке.

Добавляем любой домен в include, идем на субдомен, видим что он добавился в "show object-group fqdn", добавляем его в exclude, видим что он появился в "excluded-fqdns", но при этом он так же висит в массиве "entry" и маршрутизация всё так же идёт по правилам dns. "show rc object-group fqdn" также показывает все верно - видны оба списка include и exclude с нужными доменами. "group": [ { "group-name": "domain-list5", "enabled": true, "ipv4-addresses-count": 8, "ipv6-addresses-count": 8, "fqdn-count": 2, "entry": [ { "fqdn": "www.example.com", "type": "runtime", "deadline4": 22, "deadline6": 20, "fail-counter4": 0, "fail-counter6": 0, "last-external": 42, "last-list-changed": 42, "parent": "example.com", "ipv4": [ { "address": "88.221.132.115", "ttl": 35, "last-updated": 42 }, { "address": "88.221.132.120", "ttl": 35, "last-updated": 42 } ], "ipv6": [ { "address": "2a02:26f0:4600::210:6738", "ttl": 45, "last-updated": 42 }, { "address": "2a02:26f0:4600::213:cc32", "ttl": 45, "last-updated": 42 } ] }, { "fqdn": "example.com", "type": "config", "deadline4": 143, "deadline6": 240, "fail-counter4": 0, "fail-counter6": 0, "last-external": 41, "last-list-changed": 41, "ipv4": [ { "address": "23.192.228.80", "ttl": 176, "last-updated": 41 }, { "address": "23.192.228.84", "ttl": 176, "last-updated": 41 }, { "address": "23.215.0.136", "ttl": 176, "last-updated": 41 }, { "address": "23.215.0.138", "ttl": 176, "last-updated": 41 }, { "address": "23.220.75.232", "ttl": 176, "last-updated": 41 }, { "address": "23.220.75.245", "ttl": 176, "last-updated": 41 } ], "ipv6": [ { "address": "2600:1406:5e00:6::17ce:bc12", "ttl": 259, "last-updated": 41 }, { "address": "2600:1406:5e00:6::17ce:bc1b", "ttl": 259, "last-updated": 41 }, { "address": "2600:1406:bc00:53::b81e:94c8", "ttl": 259, "last-updated": 41 }, { "address": "2600:1406:bc00:53::b81e:94ce", "ttl": 259, "last-updated": 41 }, { "address": "2600:1408:ec00:36::1736:7f24", "ttl": 259, "last-updated": 41 }, { "address": "2600:1408:ec00:36::1736:7f31", "ttl": 259, "last-updated": 41 } ] } ], "excluded-ipv4": [], "excluded-ipv6": [], "excluded-fqdns": [ { "address": "www.example.com" } ], "fqdn-count-runtime": 1 } ]

Настроил вчера на 5.0.1 mesh (nc-1812 + kn-3910). BE на 1812 выключил, чтобы устройства не держались за более новый стандарт. На самом деле не уверен нужно ли это, но пока так. В веб морде иногда девайсы тоже будто через провод коннектятся, но если подождать, то со временем картина меняется и все становится корректно. Перед настройкой сразу был включен mws encapsulation.

Спасибо, но как раз не хочу. Я лишь хочу чтобы dns запросы из политик наполняли ipset, который используется в маршрутизации dns в основной политике.