avn

Я не задаю ip. Утилита резолвит в iov6-адрес по умолчанию.

Я бы рекомендовал ipv6 дать приоритет. Но т.к. у большинства еще ipv4, думаю оставить ipv4. Только-что N

Есть шанс на обучение в ближайшем будущем?

Так это встроенный wg работал. Просто после загрузки некоторых параметров через wg setconf, он резолвил в ipv6. Сейчас так не получается, я пробовал.

Как не обучен, еще в 2022 году ходил. https://forum.keenetic.com/topic/14554-wireguard-ipv6/?do=findComment&comment=154862 https://forum.keenetic.com/topic/14554-wireguard-ipv6/ peer: bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo= endpoint: [2606:4700:d0::a29f:c001]:1701 allowed ips: 0.0.0.0/0, ::/0 latest handshake: 16 seconds ago transfer: 1.26 KiB received, 8.64 KiB sent Еще были темы, найти не могу. Просто что-то сломалось.

@Le ecureuil Т.е. в сухом остатке, Dns::Resolver не умеет ipv6.

Так резолвит, но если есть ipv4 адрес. Если только ipv6, то не резолвит. Проблема как и была Такой резолвер добавляет ip name-server 192.168.97.97:53 warp-1.lan Сопутствующие проблемы: С интерфейса удалить невозможно. Так удаляет ip no name-server 192.168.97.97:53 warp-1.lan Резолвер на локальный адрес не добавить { "prompt": "(config)", "status": [ { "status": "error", "code": "22544486", "ident": "Dns::Manager", "message": "invalid IP address: 127.0.0.1." } ] }

Все личные домены прописаны в /opt/etc/hosts -> Он же /tmp/hosts, /var/hosts, /etc/hosts Подтягивается сторонним dns - dnsmasq на 53 порту. ipv6 host - нет такой команды. $ ls -al /var/hosts /tmp/hosts /etc/hosts /var lrwxrwxrwx 1 root root 10 Aug 31 22:27 /etc/hosts -> /var/hosts -rw-r--r-- 1 root root 659 Sep 18 04:02 /tmp/hosts lrwxrwxrwx 1 root root 4 Aug 31 22:27 /var -> /tmp -rw-r--r-- 1 root root 659 Sep 18 04:02 /var/hosts

Никак.

Есть проблема с резолвом локальных ip адресов из клиента Wireguard при включенном dns-override. [I] Sep 16 23:58:43 kernel: wireguard: Wireguard4: handshake for peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (0.0.0.0:500) did not complete after 2164854852 seconds, retrying (try 5) [I] Sep 17 00:00:08 kernel: Core::Syslog: last message repeated 16 times. [E] Sep 17 00:00:13 ndm: Dns::Resolver: failed to resolve "ipv6.warp-1.lan": timed out. [I] Sep 17 00:00:13 kernel: wireguard: Wireguard4: handshake for peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (0.0.0.0:500) did not complete after 1 seconds, retrying (try 5) [I] Sep 17 00:00:18 kernel: wireguard: Wireguard4: handshake for peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (0.0.0.0:500) did not complete after 2164854852 seconds, retrying (try 5) [I] Sep 17 00:00:24 kernel: wireguard: Wireguard4: handshake for peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (0.0.0.0:500) did not complete after 2164854852 attempts, giving up [E] Sep 17 00:00:24 ndm: Dns::Resolver: failed to resolve "ipv6.warp-1.lan": timed out. ~ # uname -a Linux ZyAvenger 4.9-ndm-5 #0 SMP Thu Aug 29 22:15:29 2024 mips GNU/Linux ~ # dig +short aaaa ipv6.warp-1.lan @127.0.0.1 2606:4700:ff:0:91:e8a6:516c:aa99 ~ # dig +short aaaa ipv6.warp-1.lan 2606:4700:ff:0:91:e8a6:516c:aa99 ~ # resolv.conf nameserver 192.168.97.97 nameserver fe80::52ff:20ff:fe78:c254 options timeout:1 attempts:1 rotate Это можно как-то победить?

Я пока не понял как это все работает. Может у кого-то есть опыт в этом вопросе? Посмотрел текущую страницу Warp и удивился. WARP connects to the following IP addresses, depending on which tunnel protocol is configured for your device (WireGuard or MASQUE). All network traffic from your device to Cloudflare goes through these IPs and ports over UDP. Пока ничего не понятно.

4.2b3 не исправлено

На b3, или b4 все таки?

Становится понятен алгоритм. Перед отправкой данных на сервер, уже в готовом пакете данных с рассчитанным mac1 и полем type = 0x00000001 записывается client-id. При получении пакета от сервера, для его успешной расшифровки поле client-id зануляется. Сейчас пакет шифруется в месте с полем client-id. Это приводит к тому, что мы не видим ответов от сервера. Для пакетов с типами 2,3,4 алгоритм такой же. Т.е client-id как бы ещё один уровень транспортного пакета. Перед отправкой установили, при получении сняли. Но во внутренних процессах все работает по старому без client-id.

@Le ecureuil У нас WireShark не декодирует пакет. Т.е. mac1 не соответствует данным. if (wg_noise_handshake_create_initiation(&packet, &peer->handshake, wg->advanced_security_config.init_packet_magic_header, peer->client_id)) { wg_cookie_add_mac_to_packet(&packet, sizeof(packet), peer); Можете попробовать, сделать присвоение client_id после вызова wg_cookie_add_mac_to_packet() (Т.е. тут wg_noise_handshake_create_initiation client_id не задавать)?

@slomblobov @Le ecureuil Версия 4.2 beta 3 не исправлено. *mangle :_NDM_HTTP_INPUT_TLS_ - [0:0] :_NDM_HTTP_INPUT_TLS_PASS_ - [0:0] -A INPUT -p tcp -m tcp --dport 443 -j _NDM_HTTP_INPUT_TLS_ -A _NDM_HTTP_INPUT_TLS_ -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -j CONNNDMMARK --set-xmark 0x20/0x0 -A _NDM_HTTP_INPUT_TLS_ -p tcp -m tcp --dport 443 --tcp-flags SYN SYN -j RETURN -A _NDM_HTTP_INPUT_TLS_ -p tcp -m tcp --dport 443 --tcp-flags ACK ACK -j CONNNDMMARK --set-xmark 0x20/0x0 -A _NDM_HTTP_INPUT_TLS_ -p tcp -m tcp --dport 443 --tcp-flags ACK ACK -m connskip --connskip 2 -j RETURN -A _NDM_HTTP_INPUT_TLS_ -j _NDM_HTTP_INPUT_TLS_PASS_ -A _NDM_HTTP_INPUT_TLS_PASS_ -p tcp -m tls --tls-sni "*61413ac0945b6ece48b952e2.keenetic.io" -j CONNNDMMARK --set-xmark 0x0/0x0 -A _NDM_HTTP_INPUT_TLS_PASS_ -p tcp -m tls --tls-sni "*61413ac0945b6ece48b952e2.keenetic.io" -j RETURN -A _NDM_HTTP_INPUT_TLS_PASS_ -j DROP 4.2b4 не исправлено

Надо в /tmp ложить.

Пересмотрел еще раз патч, смущает кусок с cpu_to_le32 для маски: #define SKB_TYPE_LE32(skb, asc) ((((struct message_header *)(skb)->data)->type) & ((asc) ? 0xFFFFFFFF : cpu_to_le32(0xFF))) Не может он быть корнем проблемы?

Обязательно

На githab полно тем.

Возьми sing-box, он поднимает интерфейс tun.

Прописал ключи в WireShark. Сразу видно разницу в пакетах. WireShark не может расшифровать пакет с Keenetic

KN-1011 4.2 Beta (2,3) утечки и ребутов нету и не было. hwnat=1,swnat=1

Штатно нигде. dnsmasq max-ttl=86400 # Set a maximum TTL value that will be handed out to clients ipset ipset create unblock4-ssp hash:net timeout 86400 family inet -exist ipset create unblock6-ssp hash:net timeout 86400 family inet6 -exist agh cache_ttl_min: 86400 cache_ttl_max: 86400 Если ipset типа hash:net, то да - туда можно ложить ip адреса. Вся маршрутизация крутится вокруг ipset.

А зачем их вообще обновлять? ipset - timeout XXXX dnsmasq - max-ttl=XXX Обновление по спискам можно делать раз в сутки, если в списках есть ип диапазоны. Если только домены - обновление ipset вообще не требуется. Все делает dnsmasq.