qmxocynjca

DoT от Яндекса - это нормальный DNS в этом случае? Не очень понимаю что есть "неподменные". Если речь про "Интернет-фильтры", то ими не пользуюсь, всё руками прописано, никакого adguard и прочего нет в цепочке. Это хорошо, будем посмотреть. Тут вам видней, конечно, но это не первый раз когда я пробовал dns-proxy debug и все разы получалась какая-то жесть, когда было ощущение что девайс придётся ресетить, ибо всё вставало колом.

Про это не знал, спасибо. Да, это понятно, весь список нужных доменов заполнен. Проблема воспроизвелась конкретно с этим хостом, поэтому подробности опустил. @Le ecureuil я бы рад держать dns-proxy debug включенным, чтобы отловить это, но это не реально - резолвер перестаёт отвечать через какое-то время (минута-две) и в логи начинает слать какое-то слишком низкоуровневое месиво. Сделайте чтобы dns-proxy debug был рабочим на постоянной основе?

В роутере (fw 5.0.0) прописан DNS от провайдера (обычный) и от Яндекса (DoT), в списке DNS маршрутизации прописан youtube.com. Проблема: www.youtube.com не смог зароутиться куда надо. После неудачного роутинга несколько раз делал "nslookup www.youtube.com 192.168.1.1", но результата не дало - роутер упорно вёл по провайдеру. Пробовал включить dns-proxy debug, после чего роутер почти завис секунд через 30, смог выключить эту настройку только через telnet. Кажется после этого роутинг таки заработал, но легче от этого не стало. Наблюдения: * провайдерные DNS возвращают 173.194.221.198 от primary и 64.233.162.198 от secondary на nslookup www.youtube.com. * nslookup на www.youtube.com возвращает "Tracing route to wide-youtube.l.google.com", а на youtube.com возвращает "Tracing route to youtube.com". * nslookup www.youtube.com 77.88.8.8 (обычный dns от яндекса) возвращает разные адреса на каждый запрос. Вот как это примерно выглядит: C:\Users\user>tracert -d -w 50 www.youtube.com Tracing route to wide-youtube.l.google.com [173.194.220.198] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 1 ms 1 ms 1 ms <isp_gw> ^C C:\Users\user>nslookup www.youtube.com 192.168.1.1 Server: UnKnown Address: 192.168.1.1 Non-authoritative answer: Name: wide-youtube.l.google.com Addresses: 2a00:1450:4010:c1e::c6 142.251.1.198 Aliases: www.youtube.com youtube-ui.l.google.com C:\Users\user>tracert -d -w 50 www.youtube.com Tracing route to wide-youtube.l.google.com [142.251.1.198] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 1 ms 1 ms <1 ms <isp_gw> ^C C:\Users\user>tracert -d -w 50 youtube.com Tracing route to youtube.com [173.194.221.91] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.88.88 2 91 ms 89 ms * <kvn_gw>

@Le ecureuil скажите пожалуйста, вот эта магия с включением NAT66 для OpkgTun* не реализована? Если нет, можно сделать так же как на Wireguard* интерфейсах?

То ли я дурак то ли лыжи не едут. Почему-то в amneziawg-tools_1.0.20250903-1_aarch64-3.10.ipk лежит awg с версией "amneziawg-tools v1.0.20210914 - https://amnezia.org". Зашел уже в ipk руками, тоже вижу старую версию. Почему пришёл сюда - явные тупняки в вызове setconf наблюдаю, хотя конфиг точно валидный, никаких левых кавычек и прочего там нет. Line unrecognized: `MTU=1280' Configuration parsing error Недопересобран этот пакет или как? Как тогда другие настраивают на aarch64? upd: удалил MTU, Address, DNS и заработало. Версия в awg --version не отражает действительность.

@slomblobov Хотите сказать даже на UTF-16 не похоже? Девайс же новый, должен уметь в актуальные стандарты, разве нет? Тут уже спортивный интерес зачитать локализованное имя сети. Вон что нашел https://sre.ring0.de/ofono/commit/src/util.c?id=467db7dd7f22637859d5780dc2bc403bf3155c6b

Тут уже не подскажу, но скорей всего надо разрешить доступ по SMB без шифрования. Попробуйте передать в -o дополнительно "vers=1.0", тут похожую проблему обсуждали: https://serverfault.com/questions/414074/mount-cifs-host-is-down

Как будто в вызов insmod не пришел путь к cifs.ko. Это модуль ядра для работы SMB, проверьте что он есть где-то в недрах /lib/modules

cat backup_opt_tar_to_remote.sh #!/bin/sh BACKUPS_REMOTE=/tmp/mnt/router-backups mkdir -p $BACKUPS_REMOTE lsmod | grep -q ^cifs || insmod $(find /lib/modules -type f -name cifs.ko) cat /proc/mounts | grep -q $BACKUPS_REMOTE && umount $BACKUPS_REMOTE mount -t cifs -o username=1,password=1 //192.168.1.1/Router_backups/$(uname -n) $BACKUPS_REMOTE if [ $? -ne 0 ] ; then echo "Mount failed" exit 1 fi echo 'Saving /opt...' OUT_FILE=$BACKUPS_REMOTE/`date +%Y%m%d-%H%M%S` tar cfzv - -Xexclude /opt > $OUT_FILE.tar.gz umount $BACKUPS_REMOTE cat exclude *.DS_Store root/.cache/ tmp/

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

5.0b3, NC-1812, раздел Mobile есть в списке, но ни одного компонента не установлено. На старичке KN-1010 раздел отсутствовал, если компоненты не были установлены.

С удивлением обнаружил что параметр opkg initrc удаляется, если выбрать накопитель "Не выбран" на странице настройки OPKG и сохранить. Параметр initrc я не трогаю и ожидаю что он останется, а не деле он удаляется. Казалось бы мелочь, но нет - если проморгать, то после восстановления накопителя, внезапно запускаются все сервисы, даже те которые не начинаются с "S", т.к. прошивка переходит в режим "initrc не указан, значит запускаю всё подряд из /opt/etc/init.d/". Пожалуйста, не удаляйте этот параметр из конфига, если юзер руками явно не трогал его.

Включил на Wireguard3 и на Vlan100, через который идёт соединение. Подождал подольше и коннект произошёл где-то через 3 минуты после рестарта.

Коннект идёт через другое соединение, у которого гвоздями прибито 1280 и изменить нельзя (особенности оф. клиента CF Warp), поэтому здесь пришлось уменьшить. На момент заведения этого топика всё шло напрямую и MTU был в порядке, а сейчас вот так, ибо напрямую уже не работает. На другом коннекте, у которого MTU правильный, всё работает корректно, спасибо!

В такой конфигурации, после перезагрузки роутера, коннект у WG не может подняться. По логам видно что пытается, пытается, но в итоге "did not complete after 339245505 attempts, giving up" и всё, попытки коннекта больше нет. После ручного down/up через веб-интерфейс, подключается сразу. self-test следующим сообщением. wireguard peer ... connect via GigabitEthernet0/Vlan100

Да, спасибо, уже почитал про это. Думаю эту ситуацию можно чуть лучше обрабатывать в Кинетике, чтобы юзер сам мог понять свою ошибку.

Проблема из-за MTU 1200. Если выставляю в 1280, то inet6 адрес можно установить на интерфейсе. Всё что меньше 1280 - ошибка. ip -6 addr add dev nwg3 fc00:bbbb:bbbb:bb01::b:6a74/128 RTNETLINK answers: No buffer space available

В 5.0 beta 3 есть какие-то изменения, но маршрут не выставляется, в логах разные ошибки на интерфейсе Wireguard3. Прикладываю self-test следующим сообщением.

Видимо у всех разный опыт, у меня на постоянке включен роуминг и ноль проблем уже годами, но как только включаю BS для интереса, то через день-два обнаруживаю проблемы то с одним то с другим устройством. Я не очень понимаю как BS вообще может работать при отключенном роуминге, будут же обрывы связи при переходе с одной сети на другую. Или нет?

Зря выключили роуминг 802.11r, он нужен чтобы девайсы могли переключаться с 2.4ггц на 5ггц бесшовно даже в рамках одного роутера. В Band Steering лучше оставить "Не использовать", по опыту использования проблем с ним больше чем пользы.

Работает, но "role inet for GigabitEthernet<x>/<vlan>" на физическом порту лучше не выставлять. Это приведёт к тому, что подключение станет доступно для настроек в разделе "Подключения к интернету по Ethernet-кабелю", и любое изменение там подрежет switchport параметры. Просто пока смиритесь что этот конфиг нужно настраивать через CLI и не пытаться с ним взаимодействовать через веб. Без этого нюанса всё остальное работает адекватно - соединение видно в разделе "Системный монитор", можно включать/выключать, видно график скорости, его параметры, оно доступно в политиках. Я таким образом настроил клиент к Warp через виртуалку в proxmox, чтобы выжимать максимум скорости, т.к. сам роутер ещё на MIPS.

Есть более общая идея для кастомизации кнопок:

Думал исправление подъедет в одной из альф, но пока всё по-старому. Возможно не сильно приоритетно, но хочется корректности работы в этом месте. Может более логичный фикс - это добавить в дефолтную таблицу ipv6 маршрутов правила аналогичные 451, 452, 453 как в таблице ipv4? ~ # ip rule 0: from all lookup local 10: from all fwmark 0xffffa00 lookup main 100: from all fwmark 0xffffaaa lookup 10 101: from all fwmark 0xffffaaa blackhole 102: from all fwmark 0xffffaab lookup 11 103: from all fwmark 0xffffaab blackhole 104: from all fwmark 0xffffaac lookup 13 105: from all fwmark 0xffffaac blackhole 106: from all fwmark 0xffffaad lookup 15 107: from all fwmark 0xffffaad blackhole 108: from all fwmark 0xffffaae lookup 17 109: from all fwmark 0xffffaae blackhole 110: from all fwmark 0xffffaaf lookup 19 111: from all fwmark 0xffffaaf blackhole 112: from all fwmark 0xffffab0 lookup 21 113: from all fwmark 0xffffab0 blackhole 451: from <redacted_ip1> lookup 75 452: from <redacted_ip2> lookup 76 453: from <redacted_ip3> lookup 77 500: from all lookup 248 30001: from all lookup 1001 30002: from all lookup 1002 30003: from all lookup 1003 32766: from all lookup main 32767: from all lookup default ~ # ip -6 rule 0: from all lookup local 100: from all fwmark 0xffffaab lookup 10 101: from all fwmark 0xffffaab blackhole 102: from all fwmark 0xffffaac lookup 12 103: from all fwmark 0xffffaac blackhole 104: from all fwmark 0xffffaad lookup 14 105: from all fwmark 0xffffaad blackhole 106: from all fwmark 0xffffaae lookup 16 107: from all fwmark 0xffffaae blackhole 108: from all fwmark 0xffffaaf lookup 18 109: from all fwmark 0xffffaaf blackhole 500: from all lookup 248 32766: from all lookup main

У меня тоже не сразу завелось, так как устройство было в политике, в которой нужное соединение (вкуда роутить дополнительно) было выключено галочкой.

Поигрался с фичёй, получилось настроить всё что хотел, но делал приседания с dns-proxy debug, чтобы понять куда ломятся некоторые приложения. Есть какой-то адекватный способ мониторить DNS запросы от клиентов? Или может историю смотреть недавних запросов в Кинетике? show dns-proxy ничего интересного не показывает. Такой вариант нашёлся: opkg install wireshark tshark -i br0 -f "udp port 53" -Y "dns.flags.response == 0" -T fields -e dns.qry.name