avn

Все личные домены прописаны в /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.

Обновлять списки не нужно. Нужно у них выставить TTL на сутки и в ДНС выставить maxTTL на сутки. Все профит. Обновление по спискам можно делать раз в сутки, если в списках есть ип диапазоны.

Думаю ошибка где-то здесь, нужно занулить три байта header-а. Мне кажется это подходящее место. Если пойдет прием, значит мы на верном пути. Сейчас прием по нулям. static void wg_packet_consume_data_done(struct wg_peer *peer, struct sk_buff *skb, struct endpoint *endpoint) { ???????????? skb->dev = dev; /* We've already verified the Poly1305 auth tag, which means this packet * was not modified in transit. We can therefore tell the networking * stack that all checksums of every layer of encapsulation have already * been checked "by the hardware" and therefore is unnecessary to check * again in software. */ skb->ip_summed = CHECKSUM_UNNECESSARY; func (b *Bind) NewReceiveFunc(fn conn.ReceiveFunc) conn.ReceiveFunc { return func(buf []byte) (n int, ep conn.Endpoint, err error) { n, ep, err = fn(buf) if err != nil || n < 4 { return } if buf[1] != b.reseved[0] || buf[2] != b.reseved[1] || buf[3] != b.reseved[2] { err = errors.New("bad reseved") return } buf[1] = 0 buf[2] = 0 buf[3] = 0 return } }

Не завелось. Пакеты одинаковые. Слева - keenetic (неуспешно), справа (проходящий трафик) те же настройки (успешно). Я вообще не понимаю, что происходит. Не приходит ни одного пакета обратно. Трейс (WireShark) - keenetic 1.lkk, проходящий - 3.lkk 1.lkk 3.lkk

4.2 Beta 3 не исправлено

Скрипт обновления yggdrasil. Отказался от tor в пользу yggdrasil, в котором нашлись нужные мне ресурсы. Установлен на VPS и гоню его траффик через Wireguard нат. Обычный v6 траффик без нат. Конфиг WG такой:

Попробую на 4.3

Путаюсь добавить ipv6 маршрут так: ipv6 route 200::/7 301:8a63:d5c1:f37c::97:91/128 Wireguard0 или ipv6 route 200::/7 Wireguard0 301:8a63:d5c1:f37c::97:91/128 или ipv6 route 200::/7 Wireguard0 301:8a63:d5c1:f37c::97:91 или ipv6 route 200::/7 301:8a63:d5c1:f37c::97:91 Wireguard0 получаю ошибку: Для 3 Network::Ip6::RoutingTable error[4980739]: invalid route format. - все остальные Command::Base error[7405602]: argument parse error. Для ipv4 все проходит без проблем, синтаксис совпадает ipv6 route ({prefix} | default) (({interface} [{gateway}]) | {gateway}) [auto] [{metric}] [reject] ip route (({network} {mask}) | {host} | default) (({gateway} [{interface}]) | {interface}) [auto] [{metric}] [reject] Что я делаю не так?