avn

Да, только когда clientid=0. А с заданным значением нельзя. Маска будет раскрываться неправильно. что h1/h2/h3/h4 должны быть меньше чем 255 Тоже работать не будет, только 0 0 0 0 или 1 2 3 4 Это видно из кода wg->advanced_security_config.init_packet_magic_header = MESSAGE_HANDSHAKE_INITIATION; wg->advanced_security_config.response_packet_magic_header = MESSAGE_HANDSHAKE_RESPONSE; wg->advanced_security_config.cookie_packet_magic_header = MESSAGE_HANDSHAKE_COOKIE; wg->advanced_security_config.transport_packet_magic_header = MESSAGE_DATA; Далее, если значение параметра 0, оно не будет перетираться. Сейчас приходит пакет, и он его идентифицировать не может. Т.к. SKB_CLEAR_TYPE не сбросит биты при включенном ASC. А без client_id, они уже = 0. #define SKB_TYPE_LE32(skb, asc) ((((struct message_header *)(skb)->data)->type) & ((asc) ? 0xFFFFFFFF : cpu_to_le32(0xFF))) #define SKB_CLEAR_TYPE(skb, asc) ((((struct message_header *)(skb)->data)->type) &= ((asc) ? 0xFFFFFFFF : cpu_to_le32(0xFF))) static size_t validate_header_len(struct sk_buff *skb, struct wg_device *wg) { __le32 type = 0; if (unlikely(skb->len < sizeof(struct message_header))) return 0; type = SKB_TYPE_LE32(skb, wg->advanced_security_config.advanced_security_enabled); if (type == cpu_to_le32(wg->advanced_security_config.transport_packet_magic_header) && skb->len >= MESSAGE_MINIMUM_LENGTH) return sizeof(struct message_data); if (type == cpu_to_le32(wg->advanced_security_config.init_packet_magic_header) && skb->len == MESSAGE_INITIATION_SIZE) return MESSAGE_INITIATION_SIZE; if (type == cpu_to_le32(wg->advanced_security_config.response_packet_magic_header) && skb->len == MESSAGE_RESPONSE_SIZE) return MESSAGE_RESPONSE_SIZE; if (type == cpu_to_le32(wg->advanced_security_config.cookie_packet_magic_header) && skb->len == MESSAGE_COOKIE_REPLY_SIZE) return MESSAGE_COOKIE_REPLY_SIZE; return 0; Т.е. сейчас обмен с включенным asc выглядит так: typeid = 0x028c284 И протокол его дешифровать не может. Можно попробовать задать параметры 0x018c284 0x028c284 0x038c284 0x048c284, но мне кажется все умрет к чертям

Как Вам такая идея для поддержки asc и отправки мусорных пакетов перед коннектом. Для Warp многие задают такие настройки: {jc} {jmin} {jmax} 0 0 1 2 3 4 {jc} {jmin} {jmax} 0 0 0 0 0 0 Заводим еще одну переменную advanced_security_enabled_mask = wg->advanced_security_config.advanced_security_enabled && ( wg->client_id == 0 || wg->advanced_security_config.init_packet_magic_header != MESSAGE_HANDSHAKE_INITIATION || wg->advanced_security_config.response_packet_magic_header != MESSAGE_HANDSHAKE_RESPONSE || wg->advanced_security_config.cookie_packet_magic_header != MESSAGE_HANDSHAKE_COOKIE || wg->advanced_security_config.transport_packet_magic_header != MESSAGE_DATA || wg->advanced_security_config.init_packet_junk_size != 0 || wg->advanced_security_config.response_packet_junk_size != 0) И переделываем вызов макросов на нее #define SKB_TYPE_LE32(skb, asc) ((((struct message_header *)(skb)->data)->type) & ((asc) ? 0xFFFFFFFF : cpu_to_le32(0xFF))) #define SKB_CLEAR_TYPE(skb, asc) ((((struct message_header *)(skb)->data)->type) &= ((asc) ? 0xFFFFFFFF : cpu_to_le32(0xFF))) на: SKB_TYPE_LE32(skb, advanced_security_enabled_mask) SKB_CLEAR_TYPE(skb, advanced_security_enabled_mask) Это позволит использовать asc для Warp и client_id.

После снятия asc параметров пришлось роутер перегрузить. Команда не снимает параметры с kernel-space. interface Wireguard2 no wireguard asc

Работает! Только с ASС не очень дружит. Посмотрю потом на ASC. Браво, спасибо.

@eralde 4.2b4 не исправлено. Берем калькулятор Network: 192.168.97.96/27 11000000.10101000.01100001.011 00000 (Class C) Broadcast: 192.168.97.127 11000000.10101000.01100001.011 11111 HostMin: 192.168.97.97 11000000.10101000.01100001.011 00001 HostMax: 192.168.97.126 11000000.10101000.01100001.011 11110 Hosts/Net: 30 (Private Internet) Т.е. диапазон отличный, удовлетворяет маске. 192.168.97.111 192.168.97.126 Считаем ip: 01 192.168.97.111 02 192.168.97.112 03 192.168.97.113 04 192.168.97.114 05 192.168.97.115 06 192.168.97.116 07 192.168.97.117 08 192.168.97.118 09 192.168.97.119 10 192.168.97.120 11 192.168.97.121 12 192.168.97.122 13 192.168.97.123 14 192.168.97.124 15 192.168.97.125 16 192.168.97.126 Откуда 15 разрешенных ip? Явно ошибка.

Прошу добавить возможность добавлять/ или использовать интерфейс tun+. Реализация. Сделать новый раздел в интерфейсе vpn - tun. Дать возможность добавлять, удалять tun интерфейс или использовать уже созданный из entware интерфейс. При добавлении нового интерфейса tun, при загрузке роутера создавать его в системе. Если tun интерфейс создан как настройка к существующему tun интерфейсу, то создавать его не нужно. Для чего это необходимо. Что бы в политиках использовать этот tun интерфейс. Это своеобразная связь entware с текущим web-интерфейсом.

Сейчас entware userspace не работает, как раньше. Байтики после загрузки конфигов не идут. Но это и не нужно. Надеюсь на исправление прошивки.

Я не задаю 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))) Не может он быть корнем проблемы?