avn

Какой производительности? Через entware задаётся только endpoint.

Недавно пробовал, через entware задать адрес можно.

Все правильно. Так и есть. Когда вижу js=120, думаю, товарищ тебя скоро забанят за 120 пакетов спама. s1,s1 мусок к handshake u16 init_packet_junk_size; u16 response_packet_junk_size; jc - кол-во пакетов, jmin - минимальная длина, jmax - максимальная Поэтому стандартные обмены по WG c ASC: jc jmin jmax 0 0 0 0 0 0 jc jmin jmax 0 0 1 2 3 4

Оставлю комментарий для себя на будущее. Думаю, что проблема в цепочке wg_packet_receive->prepare_skb_header->validate_header_len. validate_header_len возвращает 0. И далее все падает.

Не работает, т.к. дешифровка пакета не происходит. Я уже трейсы снял. На скриншоте видно. Без ASC все работает отлично. С ASC примерно так: client_id=0x00000. Приходит пакет 0x02000000 SKB_TYPE_LE32 = 0x02000000 & 0xFFFFFFFF = 0x02000000 => MESSAGE_HANDSHAKE_RESPONSE client_id=0x112233. Приходит пакет 0x02112233 SKB_TYPE_LE32 = 0x02112233 & 0xFFFFFFFF = 0x02112233 !=> MESSAGE_HANDSHAKE_RESPONSE ASC выключен: client_id=0x00000. Приходит пакет 0x02000000 SKB_TYPE_LE32 = 0x02000000 & 0xFF000000 = 0x02000000 => MESSAGE_HANDSHAKE_RESPONSE client_id=0x112233. Приходит пакет 0x02112233 SKB_TYPE_LE32 = 0x02112233 & 0xFF000000= 0x02000000 => MESSAGE_HANDSHAKE_RESPONSE

Ладно, это так мысли можно и без asc жить. Тем более эти настройки сейчас вместе не разрешены. Хотя если сначала задать asc, то можно.

Да, только когда 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 не исправлено