avn
-
Posts
449 -
Joined
-
Last visited
-
Days Won
4
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by avn
-
-
27 минут назад, Илья Картавенко сказал:
Попробуйте откатиться на предыдущую версию и проверить, возможно проблемы у провайдера
У провайдера все хорошо. А вот у кинетика явно проблема
-
Добрый день!
После обновления на 4.1.3 перестал приходить шлюз по умолчанию.
Посмотрите, пожалуйста.
-
1 час назад, vasek00 сказал:
Все просто не имеет значения WAN или TUN или PPP, а имеет значение
default dev ppp0 scope link 10.10.xxх.0/24 dev eth2.9 ... 10.147.ххх.0/24 dev zt_br0 ... 104.21.ххх.ххх dev nwg4 ... 109.126.ххх.ххх dev ppp0 ... 185.107.ххх.ххх dev ppp0 ... 188.114.ххх.ххх dev ppp0 ... 192.168.100.0/24 via 10.147.ххх.ххх dev zt_br0 .... 192.168.130.0/24 dev br0 ... 192.168.150.0/24 dev br1 ... ...В таблице имеет значение только это, остальное косвенное
default dev ppp0 scope link -
1 час назад, zyxmon сказал:
@r13 @avn - господа! А как быть, если "резервное" подключение создается средствами Entware. Например sing-box. Как найти mark?
PS Создал политику по имени скрипта запуска S99sing-box. `show ip polycy` всегда выдает
{ "policy": { "Policy1": { "description": " S99sing-box", "mark": "ffffaac", "table4": 12, "route4": { "route": [ { "destination": "10.0.0.0/24", "gateway": "0.0.0.0", "interface": "GigabitEthernet1", "metric": 0, "flags": "U", "rejecting": false, "proto": "boot", "floating": false, "static": false }, { "destination": "172.16.250.0/30", "gateway": "0.0.0.0", "interface": "", "metric": 0, "flags": "U", "rejecting": false, "proto": "boot", "floating": false, "static": false }, { "destination": "192.168.1.0/24", "gateway": "0.0.0.0", "interface": "Bridge0", "metric": 0, "flags": "U", "rejecting": false, "proto": "boot", "floating": false, "static": false } ] }, "table6": 11, "route6": {} } }, "prompt": "(config)" }Первый маршрут всегда wan (10.0.0.0), второй tun0 (sing-box), третий lan (bridge). Или так и должно быть?
PS Это стенд с 1811 на прошивке 4.1
Может я вопроса не понял?
json=`curl -kfsS http://localhost:79/rci/show/ip/policy 2>/dev/null | jq -r '.[] | select(.description == " S99sing-box")'` xt_mark=`echo $json | jq -r '.mark'` xt_table=`echo $json | jq -r '.table4'` xt_iface=`ip -4 route show table ${xt_table} | awk '/default/ { print $3 }'` -
21 минуту назад, Denis Datsko сказал:
Странное поведение, не блокирует рекламные блоки на сайтах, хотя по dns рекламные хосты блокирует.
1. Установил ADH, траффик пошел от клиентов на 192.168.1.1.
Проверил, что на клиентах подтянулся dns роутера 192.168.1.1.
2. Поставил несколько фильтров, включая AdList RU, счетчик заблокированных растет.
3. Убедился в наличии записи в списке правил на примере ozon.ru, но при заходе на сайт, рекламные блоки отображаются.
Если посмотреть лог запросов, видно что отдельные правила по хостам из списка AdList RU отрабатывают, но правила с указанием конкретного блока не работают (например ozon.ru##[data-widget="advBanner"]).
ADH настроен следующим образом:
1. В качестве downstream dns указал:
https://dns.cloudflare.com/dns-query https://dns.google/dns-query2. upstream:
1.1.1.1 1.0.0.1 8.8.8.8 8.8.4.43. Опция Block domains using filters and hosts files включена.
Кто-нибудь сталкивался с проблемой или есть идеи что можно проверить?
Не надо путать agh с браузером и dpi. Dns сервера режут рекламу, только по dns имени. Хотите резать рекламу пользуйтесь dpi, например squid
-
1
-
-
20 часов назад, Sirex сказал:
Может кто-то подсказать, пожалуйста, на сервере можно в sni установить два разных сайта одновременно или два inbounds на порту 443?
Возможно пустить весь трафик через xray, в том числе служебный keenetic? Приложение не работает, так как интернета нет без xray 👉👈
Можно с помощью nginx, хоть 100 sni
Скрытый текстstream { map_hash_bucket_size 128; map_hash_max_size 16384; upstream vless_grpc_reality_sock { server unix:/dev/shm/xray-vless-grpc-reality.socket; # xray-vless-grpc-reality } upstream web_sock { server unix:/dev/shm/nginx-ssl-web.socket; # nginx-ssl-web } map $ssl_preread_server_name $upstream { "www.youtube.com" vless_grpc_reality_sock; default web_sock; } log_format log_stream '$remote_addr [$time_local] $protocol $ssl_preread_server_name $upstream $status $bytes_sent $bytes_received $session_time'; access_log /var/log/nginx/stream.log log_stream; server { listen 443 reuseport so_keepalive=on backlog=131072 fastopen=256; listen [::]:443; proxy_protocol on; proxy_pass $upstream; ssl_preread on; } }{ "listen": "/dev/shm/xray-vless-grpc-reality.socket,0666", "protocol": "vless", "settings": { "clients": [ { "email": "...email...", "id": "...id...", "alterId": 0, "level": 0 } ], "decryption": "none" }, "streamSettings": { "network": "grpc", "grpcSettings": { "serviceName": "...serviceName..." }, "security": "reality", "realitySettings": { "dest": "www.youtube.com:443", "serverNames": [ "www.youtube.com" ], "privateKey": "...privateKey...", "shortIds": [ "...shortIds..." ] }, "sockopt": { "acceptProxyProtocol": true } }, "tag": "proxy-vless-grpc-reality" }-
2
-
-
В 08.12.2023 в 23:39, AmiGO сказал:
Приветствую всех!
Ситуация следующая: Ростелеком через GPON заходит на ZTE F670 в режиме моста, от него уже Ethernet-фреймы попадают на выделенный порт Keenetic Peak с 4.0.7, на котором уже поднята PPPoE-сессия.
Провайдер выдаёт только /64 на стыке (т.е. PPPoE-интерфейсе) с помощью SLAAC, на DHCPv6 запросы же как через PPPoE, так и через Ethernet интерфейс провайдера никакого ответа не поступает и ожидаемый /56 (согласно информации с version6.ru) не прилетает. Проверялся этот факт по мере роста сомнений в собственной вменяемости сначала на оригинальном ZTE F670 при поднятом PPPoE прямо с него, потом на микроте RB4011 с ROS 7.12.1 и ZTE снова возвращённом в бридж, потом на свежей полновесной генте и под конец мероприятия на всё том же F670, но уже "правильно поднастроенном", т.е. с полноценным доступом к busybox, iptables, ebtables, arptables и так далее - для исключения наличия какой-либо непонятной фильтрации с помощью файрволла или eBPF на стороне железки. Результат прежний: на DHCPv6 со стороны ISP ничего не отвечает.
Однако, т.к. провайдер всё-таки выдаёт полностью рабочий /64, которого мне вполне достаточно, возникла идея его переанонсировать в локальную сеть и выяснилось (в том числе после общения с поддержкой Keenetic), что такого мой Keenetic Peak не умеет и уметь не планирует.
Научить его этому благодаря наличию Entware оказалось довольно просто: занялся этим скрипт 01_wan_ipv6_config.sh(ахтунг! много башизмов!), закинутый в `/etc/ndm/wan.d/` + симлинк на него же в `/etc/cron.1min/`.
Для достижения искомого поведения, как видно из скрипта, оказалось достаточно конфига для установленного в Entware radvd, логика же для ndppd не понадобилась, т.к. всё работает и без пересылки NDP-пакетов. Помимо доработок напильником также потребовалось полностью удалить из конфига Keenetic корневую секцию `ipv6` с целью предотвращения запуска встроенного radvd.
Вот так выглядит избавленный от всего лишнего конфиг роутера: config.txt
Вопрос без TL;DR: могли бы вы, уважаемые разработчики, добавить в NDMS нативную возможность переанонсирования полученного от провайдера с помощью SLAAC IPv6 /64 префикса в LAN через тот же SLAAC или DHCPv6 на роутере без необходимости получения DHCPv6-PD /56 от провайдера? Спасибо.
P.S. Пример конфига radvd, который для этого используется у меня: radvd.conf и конфиг ndppd (у меня всё отлично работает и без него): ndppd.conf
Может у провайдера проверка на мак адрес используется?
-
1 час назад, Valery Lutoshkin сказал:
@Zeleza а можно ли научить kvas не убивать полностью dnsmasq.conf при обновлении? Или хотя бы записывать в него по умолчанию что-то типа conf-file=/opt/etc/dnsmasq.local.conf (или что-нибудь подобное), в котором уже будут храниться специфические настройки?
У меня в отдельном файле форвардеры для специфических доменов, и при каждом обновлении приходится не забыть сходить и поправить dnsmasq.conf руками.И еще - не знаю, баг это или фича, но после обновления сегодня на обоих роутерах пропали ранее добавленные vpn net, пришлось их тоже после обновления добавлять заново.
Лучше перейти на каталог и писать туда хоть 100 конфигов
conf-dir=/opt/etc/dnsmasq.d/,*.dnsmasq-
1
-
1
-
-
В 03.01.2024 в 07:49, Skrill0 сказал:
Доброго Вам утра!
Да, звонки не работают, так как Redirect не поддерживает UDP.
В текущей версии 0.9.9 есть только 2 режима.
Other и Redirect.
Для решения проблемы нужно подождать обновления.
На данном этапе я сделала TPROXY для клиентов Xray и Sing-box.
Также полноценный TUN для sing-box.
Сейчас переписываю код. Пришлось очень много переделать)
С обновлением все заработает. Включая DoQ, при желании)Кто вам такое сказал, что redirect не поддерживает udp? Достаточно посмотреть на правила
iptables -t nat -nvL _NDM_HOTSPOT_DNSREDIRи понять, что кинетик активно использует redirect для udp
-
-
21 час назад, jameszero сказал:
Провайдерский dns в данной связке вполне рабочее решение, он нужен только для одного запроса - отрезовлить адрес DoH\DoT сервера, а затем всё начинает идти по шифрованному каналу и провайдерский dns не используется.
При указании имени сервера, используйте ip адрес
-
3
-
-
27 минут назад, V3ktor сказал:
Всем привет, подскажите разобрались с прямым эфиром на тв приставке Ростелеком ?( у меня архив и весь платный контент показывает, а вот прямой эфир ошибку выдает )
А плэйлист как выглядит? Надо понять что за траффик - мультикаст или обычный.
-
2 часа назад, jameszero сказал:
Да, учитываю, что роутеры у большинства это не aarch64, это отличная идея гнать весь траффик через v2ray\xray. Это правила, которые работают у меня, под себя модифицируем их самостоятельно.
Мой выбор xray+dnsmasq+ipset
-
Остановился пока на такой конфигурации. Работают как запросы с bridge так и локальный траффик. Это просто магия какая-то.
/opt/etc/ndm/netfilter.d/10m-v2ray.sh
Скрытый текст#!/bin/sh [ "$type" != "iptables" -a "$type" != "ip6tables" ] && exit 0 [ "$table" != "mangle" ] && exit 0 ipt4() { if ! iptables -C "$@" &>/dev/null; then iptables -A "$@" || exit 0 fi } ipt6() { if ! ip6tables -C "$@" &>/dev/null; then ip6tables -A "$@" || exit 0 fi } ipt() { local F=ipt4 [ "$type" == "iptables" ] || F=ipt6 "$F" "$@" } # V2Ray TABLE_ID=233 MARK_PROXY=233 MARK_DONE=234 PROXY_PORT=9172 if [ "$type" == "iptables" ]; then PROXY_IP=127.0.0.1 EXCLUDE_NETS='0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16 172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 203.0.113.0/24 224.0.0.0/3' EXCLUDE_NETS_LOOP=255.255.255.255/32 IPSET=unblock4-ssp IPFAMILY=4 iptables -N V2RAY_REDIRECT -t mangle 2>/dev/null iptables -N V2RAY_LOOP -t mangle 2>/dev/null else PROXY_IP=::1 EXCLUDE_NETS='0000::/8 0100::/64 0200::/7 2001:0002::/48 2001:0010::/28 2001:0db8::/32 2002::/16 3ffe::/16 fc00::/7 fe80::/10 fec0::/10 ff00::/8' EXCLUDE_NETS_LOOP=::/128 IPSET=unblock6-ssp IPFAMILY=6 ip6tables -N V2RAY_REDIRECT -t mangle 2>/dev/null ip6tables -N V2RAY_LOOP -t mangle 2>/dev/null fi; ip -$IPFAMILY route add local default dev lo table "$TABLE_ID" 2>/dev/null ip -$IPFAMILY route show table main |grep -Ev ^default |while read ROUTE; do ip -$IPFAMILY route add table "$TABLE_ID" $ROUTE 2>/dev/null; done ip -$IPFAMILY rule add fwmark "$MARK_PROXY" table "$TABLE_ID" priority "$TABLE_ID" 2>/dev/null ipt V2RAY_REDIRECT -t mangle -m mark --mark "$MARK_DONE" -j RETURN for net in $EXCLUDE_NETS; do ipt V2RAY_REDIRECT -t mangle -d "$net" -j RETURN; done ipt V2RAY_REDIRECT -t mangle -p tcp -j TPROXY --tproxy-mark "$MARK_PROXY/$MARK_PROXY" --on-ip "$PROXY_IP" --on-port "$PROXY_PORT" ipt V2RAY_REDIRECT -t mangle -p udp -j TPROXY --tproxy-mark "$MARK_PROXY/$MARK_PROXY" --on-ip "$PROXY_IP" --on-port "$PROXY_PORT" ipt V2RAY_LOOP -t mangle -m mark --mark "$MARK_DONE" -j RETURN for net in $EXCLUDE_NETS; do ipt V2RAY_LOOP -t mangle -d "$net" -j RETURN; done ipt V2RAY_LOOP -t mangle -d "$EXCLUDE_NETS_LOOP" -j RETURN ipt V2RAY_LOOP -t mangle -j MARK --set-mark "$MARK_PROXY" ipt PREROUTING -t mangle -p tcp -m set --match-set "$IPSET" dst -j V2RAY_REDIRECT ipt PREROUTING -t mangle -p udp -m set --match-set "$IPSET" dst -j V2RAY_REDIRECT ipt PREROUTING -t mangle -m mark --mark "$MARK_DONE" -j CONNMARK --save-mark ipt OUTPUT -t mangle -m connmark --mark "$MARK_DONE" -j CONNMARK --restore-mark ipt OUTPUT -t mangle -p tcp -m set --match-set "$IPSET" dst -j V2RAY_LOOP ipt OUTPUT -t mangle -p udp -m set --match-set "$IPSET" dst -j V2RAY_LOOP ipt OUTPUT -t mangle -m mark --mark "$MARK_DONE" -j MARK --set-mark 0 exit 0/opt/etc/v2ray/10-tproxy.json
Скрытый текст{ "inbounds": [ { "listen": "127.0.0.1", "port": 9172, "protocol": "dokodemo-door", "settings": { "network": "tcp,udp", "followRedirect": true }, "streamSettings": { "sockopt": { "tproxy": "tproxy" } }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls", "quic" ] }, "tag": "tproxy4" }, { "listen": "::1", "port": 9172, "protocol": "dokodemo-door", "settings": { "network": "tcp,udp", "followRedirect": true }, "streamSettings": { "sockopt": { "tproxy": "tproxy" } }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls", "quic" ] }, "tag": "tproxy6" } ] }/opt/etc/v2ray/outgoing*
Скрытый текст"outbounds": [ { "protocol": "vmess", "settings": { }, "streamSettings": { "sockopt": { ~~~~"mark": 234~~~~~ },-
2
-
2
-
-
2 минуты назад, Skrill0 сказал:
Можно переназначить порт 443 на 8443, к примеру.
ip http ssl port {port}
В таком случае будет~ # iptables -t mangle -nL _NDM_HTTP_INPUT_TLS_ Chain _NDM_HTTP_INPUT_TLS_ (1 references) target prot opt source destination CONNNDMMARK tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8443 flags:0x02/0x02 CONNNDMMARK xor 0x20 RETURN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8443 flags:0x02/0x02 CONNNDMMARK tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8443 flags:0x10/0x10 CONNNDMMARK xor 0x20 RETURN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8443 flags:0x10/0x10 connskip 2 _NDM_HTTP_INPUT_TLS_PASS_ all -- 0.0.0.0/0 0.0.0.0/0Т.е. если сторонний сайт будет висеть на порту 8443, то будем опять разбираться, почему не работает.
-
1
-
-
39 минут назад, Skrill0 сказал:
Доброго Вам вечера.
Может на 443 мешают сервисы самого keenetic?
Причина найдена.
Нормальной работе мешает правило
-A INPUT -p tcp -m tcp --dport 443 -j _NDM_HTTP_INPUT_TLS_Если его удалить, то все работает
iptables -t mangle -D INPUT -p tcp -m tcp --dport 443 -j _NDM_HTTP_INPUT_TLS_Админы, подскажите решение...
-
3
-
-
Если по протоколу ipv4 без https (curl -4v http://ipecho.net/plain) - все работает.
~ # tcpdump -i br0 -vv host 34.160.111.145 tcpdump: listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 17:33:40.554071 IP (tos 0x0, ttl 128, id 1840, offset 0, flags [DF], proto TCP (6), length 48) 192.168.97.123.65203 > 145.111.160.34.bc.googleusercontent.com.http: Flags [S], cksum 0xdcf3 (correct), seq 1370138167, win 64240, options [mss 1460,nop,nop,sackOK], length 0 17:33:40.554503 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 48) 145.111.160.34.bc.googleusercontent.com.http > 192.168.97.123.65203: Flags [S.], cksum 0xb477 (incorrect -> 0xbf73), seq 88121615, ack 1370138168, win 29200, options [mss 1460,nop,nop,sackOK], length 0 17:33:40.556456 IP (tos 0x0, ttl 128, id 1841, offset 0, flags [DF], proto TCP (6), length 40) 192.168.97.123.65203 > 145.111.160.34.bc.googleusercontent.com.http: Flags [.], cksum 0x6357 (correct), seq 1, ack 1, win 64240, length 0 17:33:40.558893 IP (tos 0x0, ttl 128, id 1842, offset 0, flags [DF], proto TCP (6), length 118) 192.168.97.123.65203 > 145.111.160.34.bc.googleusercontent.com.http: Flags [P.], cksum 0x0e68 (correct), seq 1:79, ack 1, win 64240, length 78: HTTP, length: 78 GET /plain HTTP/1.1 Host: ipecho.net User-Agent: curl/8.2.1 Accept: */* 17:33:40.559165 IP (tos 0x0, ttl 64, id 937, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.http > 192.168.97.123.65203: Flags [.], cksum 0xb46f (incorrect -> 0xebe9), seq 1, ack 79, win 29200, length 0 17:33:41.126494 IP (tos 0x0, ttl 64, id 938, offset 0, flags [DF], proto TCP (6), length 346) 145.111.160.34.bc.googleusercontent.com.http > 192.168.97.123.65203: Flags [P.], cksum 0xb5a1 (incorrect -> 0x24ca), seq 1:307, ack 79, win 29200, length 306: HTTP, length: 306 HTTP/1.1 200 OK server: istio-envoy date: Thu, 09 Nov 2023 14:33:50 GMT content-type: text/plain; charset=utf-8 content-length: 22 access-control-allow-origin: * x-envoy-upstream-service-time: 1 strict-transport-security: max-age=2592000; includeSubDomains Via: 1.1 google 2a00:1022::1 [|http] 17:33:41.138142 IP (tos 0x0, ttl 128, id 1843, offset 0, flags [DF], proto TCP (6), length 40) 192.168.97.123.65203 > 145.111.160.34.bc.googleusercontent.com.http: Flags [F.], cksum 0x6308 (correct), seq 79, ack 307, win 63934, length 0 17:33:41.184199 IP (tos 0x0, ttl 64, id 939, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.http > 192.168.97.123.65203: Flags [.], cksum 0xb46f (incorrect -> 0xeab6), seq 307, ack 80, win 29200, length 0 17:33:42.139804 IP (tos 0x0, ttl 64, id 940, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.http > 192.168.97.123.65203: Flags [F.], cksum 0xb46f (incorrect -> 0xeab5), seq 307, ack 80, win 29200, length 0 17:33:42.141353 IP (tos 0x0, ttl 128, id 1844, offset 0, flags [DF], proto TCP (6), length 40) 192.168.97.123.65203 > 145.111.160.34.bc.googleusercontent.com.http: Flags [.], cksum 0x6307 (correct), seq 80, ack 308, win 63934, length 0 -
Трафик на br0. ipv6 - работает, ipv4 - не работает
tcpdump: listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 17:21:10.948006 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 28) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [S], cksum 0xb5a1 (correct), seq 179399871, win 64800, options [mss 1440,nop,nop,sackOK], length 0 17:21:10.948499 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 28) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [S.], cksum 0x58e7 (incorrect -> 0x99c4), seq 3770140596, ack 179399872, win 28800, options [mss 1440,nop,nop,sackOK], length 0 17:21:10.949554 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 20) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [.], cksum 0x39d4 (correct), seq 1, ack 1, win 64800, length 0 17:21:10.970729 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 537) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [P.], cksum 0x2a57 (correct), seq 1:518, ack 1, win 64800, length 517 17:21:10.971071 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 20) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [.], cksum 0x58df (incorrect -> 0xc1c7), seq 1, ack 518, win 29480, length 0 17:21:11.445891 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 4609) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [P.], cksum 0x6acc (incorrect -> 0xf9a9), seq 1:4590, ack 518, win 29480, length 4589 17:21:11.448812 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 20) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [.], cksum 0x25e2 (correct), seq 518, ack 4590, win 64800, length 0 17:21:11.464933 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 100) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [P.], cksum 0x490b (correct), seq 518:598, ack 4590, win 64800, length 80 17:21:11.465092 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 20) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [.], cksum 0x58df (incorrect -> 0xaf8a), seq 4590, ack 598, win 29480, length 0 17:21:11.470381 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 106) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [P.], cksum 0x9269 (correct), seq 598:684, ack 4590, win 64800, length 86 17:21:11.470591 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 20) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [.], cksum 0x58df (incorrect -> 0xaf34), seq 4590, ack 684, win 29480, length 0 17:21:11.474099 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 84) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [P.], cksum 0x5015 (correct), seq 684:748, ack 4590, win 64800, length 64 17:21:11.474286 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 20) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [.], cksum 0x58df (incorrect -> 0xaef4), seq 4590, ack 748, win 29480, length 0 17:21:11.533920 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 638) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [P.], cksum 0x5b49 (incorrect -> 0x33c6), seq 4590:5208, ack 748, win 29480, length 618 17:21:11.537602 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 51) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [P.], cksum 0x58fe (incorrect -> 0x601b), seq 5208:5239, ack 748, win 29480, length 31 17:21:11.538576 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 20) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [.], cksum 0x24fc (correct), seq 748, ack 5239, win 64151, length 0 17:21:11.539558 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 51) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [P.], cksum 0x97f2 (correct), seq 748:779, ack 5239, win 64151, length 31 17:21:11.539668 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 20) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [.], cksum 0x58df (incorrect -> 0xac4c), seq 5239, ack 779, win 29480, length 0 17:21:11.653759 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 311) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [P.], cksum 0x5a02 (incorrect -> 0xb2d7), seq 5239:5530, ack 779, win 29480, length 291 17:21:11.655048 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 59) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [P.], cksum 0x4903 (correct), seq 779:818, ack 5530, win 63860, length 39 17:21:11.655288 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 20) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [.], cksum 0x58df (incorrect -> 0xab02), seq 5530, ack 818, win 29480, length 0 17:21:11.668278 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 20) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [F.], cksum 0x24b5 (correct), seq 818, ack 5530, win 63860, length 0 17:21:11.716190 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 20) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [.], cksum 0x58df (incorrect -> 0xab01), seq 5530, ack 819, win 29480, length 0 17:21:12.669991 IP6 (flowlabel 0x5b2b9, hlim 64, next-header TCP (6) payload length: 20) 2600:1901:0:b2bd::.https > 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152: Flags [F.], cksum 0x58df (incorrect -> 0xab00), seq 5530, ack 819, win 29480, length 0 17:21:12.671138 IP6 (flowlabel 0xf7275, hlim 64, next-header TCP (6) payload length: 20) 2a55:dd80:330b:5566:f565:6e54:852d:528c.65152 > 2600:1901:0:b2bd::.https: Flags [.], cksum 0x24b4 (correct), seq 819, ack 5531, win 63860, length 0 tcpdump: listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 17:22:46.023806 IP (tos 0x0, ttl 128, id 1824, offset 0, flags [DF], proto TCP (6), length 48) 192.168.97.123.65160 > 145.111.160.34.bc.googleusercontent.com.https: Flags [S], cksum 0x42cc (correct), seq 2528311830, win 64240, options [mss 1460,nop,nop,sackOK], length 0 17:22:46.024221 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 48) 145.111.160.34.bc.googleusercontent.com.https > 192.168.97.123.65160: Flags [S.], cksum 0xb477 (incorrect -> 0xaed0), seq 1110301341, ack 2528311831, win 29200, options [mss 1460,nop,nop,sackOK], length 0 17:22:46.025140 IP (tos 0x0, ttl 128, id 1825, offset 0, flags [DF], proto TCP (6), length 40) 192.168.97.123.65160 > 145.111.160.34.bc.googleusercontent.com.https: Flags [.], cksum 0x52b4 (correct), seq 1, ack 1, win 64240, length 0 17:22:46.055902 IP (tos 0x0, ttl 128, id 1826, offset 0, flags [DF], proto TCP (6), length 557) 192.168.97.123.65160 > 145.111.160.34.bc.googleusercontent.com.https: Flags [P.], cksum 0x6918 (correct), seq 1:518, ack 1, win 64240, length 517 17:22:46.362233 IP (tos 0x0, ttl 128, id 1827, offset 0, flags [DF], proto TCP (6), length 557) 192.168.97.123.65160 > 145.111.160.34.bc.googleusercontent.com.https: Flags [P.], cksum 0x6918 (correct), seq 1:518, ack 1, win 64240, length 517 17:22:46.975580 IP (tos 0x0, ttl 128, id 1828, offset 0, flags [DF], proto TCP (6), length 557) 192.168.97.123.65160 > 145.111.160.34.bc.googleusercontent.com.https: Flags [P.], cksum 0x6918 (correct), seq 1:518, ack 1, win 64240, length 517 17:22:48.183102 IP (tos 0x0, ttl 128, id 1829, offset 0, flags [DF], proto TCP (6), length 557) 192.168.97.123.65160 > 145.111.160.34.bc.googleusercontent.com.https: Flags [P.], cksum 0x6918 (correct), seq 1:518, ack 1, win 64240, length 517 17:22:50.582709 IP (tos 0x0, ttl 128, id 1830, offset 0, flags [DF], proto TCP (6), length 557) 192.168.97.123.65160 > 145.111.160.34.bc.googleusercontent.com.https: Flags [P.], cksum 0x6918 (correct), seq 1:518, ack 1, win 64240, length 517 17:22:55.397875 IP (tos 0x0, ttl 128, id 1831, offset 0, flags [DF], proto TCP (6), length 557) 192.168.97.123.65160 > 145.111.160.34.bc.googleusercontent.com.https: Flags [P.], cksum 0x6918 (correct), seq 1:518, ack 1, win 64240, length 517 17:22:57.022852 IP (tos 0x0, ttl 64, id 31512, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.https > 192.168.97.123.65160: Flags [F.], cksum 0xb46f (incorrect -> 0xdb93), seq 1, ack 1, win 29200, length 0 17:22:57.025255 IP (tos 0x0, ttl 128, id 1832, offset 0, flags [DF], proto TCP (6), length 40) 192.168.97.123.65160 > 145.111.160.34.bc.googleusercontent.com.https: Flags [.], cksum 0x50ae (correct), seq 518, ack 2, win 64240, length 0 17:22:57.028114 IP (tos 0x0, ttl 128, id 1833, offset 0, flags [DF], proto TCP (6), length 40) 192.168.97.123.65160 > 145.111.160.34.bc.googleusercontent.com.https: Flags [F.], cksum 0x50ad (correct), seq 518, ack 2, win 64240, length 0 17:22:57.036032 IP (tos 0x0, ttl 128, id 1834, offset 0, flags [DF], proto TCP (6), length 40) 192.168.97.123.65160 > 145.111.160.34.bc.googleusercontent.com.https: Flags [R.], cksum 0x4b9a (correct), seq 519, ack 2, win 0, length 0 17:22:57.228226 IP (tos 0x0, ttl 64, id 31513, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.https > 192.168.97.123.65160: Flags [F.], cksum 0xb46f (incorrect -> 0xdb93), seq 1, ack 1, win 29200, length 0 17:22:57.436229 IP (tos 0x0, ttl 64, id 31514, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.https > 192.168.97.123.65160: Flags [F.], cksum 0xb46f (incorrect -> 0xdb93), seq 1, ack 1, win 29200, length 0 17:22:57.848250 IP (tos 0x0, ttl 64, id 31515, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.https > 192.168.97.123.65160: Flags [F.], cksum 0xb46f (incorrect -> 0xdb93), seq 1, ack 1, win 29200, length 0 17:22:58.680246 IP (tos 0x0, ttl 64, id 31516, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.https > 192.168.97.123.65160: Flags [F.], cksum 0xb46f (incorrect -> 0xdb93), seq 1, ack 1, win 29200, length 0 17:23:00.344196 IP (tos 0x0, ttl 64, id 31517, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.https > 192.168.97.123.65160: Flags [F.], cksum 0xb46f (incorrect -> 0xdb93), seq 1, ack 1, win 29200, length 0 17:23:03.644257 IP (tos 0x0, ttl 64, id 31518, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.https > 192.168.97.123.65160: Flags [F.], cksum 0xb46f (incorrect -> 0xdb93), seq 1, ack 1, win 29200, length 0 17:23:10.296219 IP (tos 0x0, ttl 64, id 31519, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.https > 192.168.97.123.65160: Flags [F.], cksum 0xb46f (incorrect -> 0xdb93), seq 1, ack 1, win 29200, length 0 17:23:23.612229 IP (tos 0x0, ttl 64, id 31520, offset 0, flags [DF], proto TCP (6), length 40) 145.111.160.34.bc.googleusercontent.com.https > 192.168.97.123.65160: Flags [F.], cksum 0xb46f (incorrect -> 0xdb93), seq 1, ack 1, win 29200, length 0 -
37 минут назад, maxsmeller сказал:
Добрый день, подскажите пожалуйста, как используя данную связку, не сломать ее, и добавить свои DNS записи в DNSMASQ? Чтобы и KVAS работал адекватно и обновлял списки, и свои DNS записи использовать, и они не затирались?
Можно в конфиг добавить строку
conf-dir=/opt/etc/dnsmasq.d/,*.dnsmasqи теперь dnsmasq будет вычитывать все файлы *.dnsmasq из директории /opt/etc/dnsmasq.d/
-
Добрый вечер! Пришло время разобраться с TProxy для ipv4.
Беру любой сервис (например v2ray,ss,squid и т.д.), который слушает определенный порт на роутере, например 9172, и пересылает траффик в режиме tproxy на удаленный сервер.
Пишу симметричные скрипты для ipv4 и для ipv6 траффика.
Скрытый текст/opt/etc/ndm/netfilter.d/10m-ss4.sh
#!/bin/sh [ "$type" != "iptables" ] && exit 0 [ "$table" != "mangle" ] && exit 0 ip4t() { if ! iptables -C "$@" &>/dev/null; then iptables -A "$@" || exit 0 fi } # V2Ray ip -4 route add local default dev lo table 233 2>/dev/null ip -4 route show table main |grep -Ev ^default |while read ROUTE; do ip -4 route add table 233 $ROUTE 2>/dev/null; done ip -4 rule add fwmark 0x2333 table 233 priority 233 2>/dev/null iptables -N SSREDIR -t mangle 2>/dev/null #iptables -F SSREDIR -t mangle 2>/dev/null # connection-mark -> packet-mark ip4t SSREDIR -t mangle -m mark --mark 0x2334 -j RETURN ip4t SSREDIR -t mangle -j CONNMARK --restore-mark ip4t SSREDIR -t mangle -m mark --mark 0x2333 -j RETURN ip4t SSREDIR -t mangle -d 0.0.0.0/8 -j RETURN ip4t SSREDIR -t mangle -d 10.0.0.0/8 -j RETURN ip4t SSREDIR -t mangle -d 100.64.0.0/10 -j RETURN ip4t SSREDIR -t mangle -d 127.0.0.0/8 -j RETURN ip4t SSREDIR -t mangle -d 169.254.0.0/16 -j RETURN ip4t SSREDIR -t mangle -d 172.16.0.0/12 -j RETURN ip4t SSREDIR -t mangle -d 192.0.0.0/24 -j RETURN ip4t SSREDIR -t mangle -d 192.0.2.0/24 -j RETURN ip4t SSREDIR -t mangle -d 192.168.0.0/16 -j RETURN ip4t SSREDIR -t mangle -d 198.18.0.0/15 -j RETURN ip4t SSREDIR -t mangle -d 198.51.100.0/24 -j RETURN ip4t SSREDIR -t mangle -d 203.0.113.0/24 -j RETURN ip4t SSREDIR -t mangle -d 224.0.0.0/3 -j RETURN ip4t SSREDIR -t mangle -p tcp --syn -j MARK --set-mark 0x2333 ip4t SSREDIR -t mangle -p udp -m conntrack --ctstate NEW -j MARK --set-mark 0x2333 ip4t SSREDIR -t mangle -j CONNMARK --save-mark ip4t PREROUTING -t mangle -i br0 -p tcp -d 34.160.111.145 -j SSREDIR ip4t PREROUTING -t mangle -i br0 -p tcp -m mark --mark 0x2333 -j TPROXY --on-port 9172 ip4t PREROUTING -t mangle -i br0 -p udp -d 34.160.111.145 -j SSREDIR ip4t PREROUTING -t mangle -i br0 -p udp -m mark --mark 0x2333 -j TPROXY --on-port 9172 exit 0/opt/etc/ndm/netfilter.d/10m-ss6.sh
#!/bin/sh [ "$type" != "ip6tables" ] && exit 0 [ "$table" != "mangle" ] && exit 0 ip6t() { if ! ip6tables -C "$@" &>/dev/null; then ip6tables -A "$@" || exit 0 fi } # V2Ray ip -6 route add local default dev lo table 233 2>/dev/null ip -6 route show table main |grep -Ev ^default |while read ROUTE; do ip -6 route add table 233 $ROUTE 2>/dev/null; done ip -6 rule add fwmark 0x2333 table 233 priority 233 2>/dev/null ip6tables -N SSREDIR -t mangle 2>/dev/null #ip6tables -F SSREDIR -t mangle 2>/dev/null # connection-mark -> packet-mark ip6t SSREDIR -t mangle -m mark --mark 0x2334 -j RETURN ip6t SSREDIR -t mangle -j CONNMARK --restore-mark ip6t SSREDIR -t mangle -m mark --mark 0x2333 -j RETURN ip6t SSREDIR -t mangle -d 0000::/8 -j RETURN ip6t SSREDIR -t mangle -d 0100::/64 -j RETURN ip6t SSREDIR -t mangle -d 0200::/7 -j RETURN ip6t SSREDIR -t mangle -d 2001:0002::/48 -j RETURN ip6t SSREDIR -t mangle -d 2001:0010::/28 -j RETURN ip6t SSREDIR -t mangle -d 2001:0db8::/32 -j RETURN ip6t SSREDIR -t mangle -d 2002::/16 -j RETURN ip6t SSREDIR -t mangle -d 3ffe::/16 -j RETURN ip6t SSREDIR -t mangle -d fc00::/7 -j RETURN ip6t SSREDIR -t mangle -d fe80::/10 -j RETURN ip6t SSREDIR -t mangle -d fec0::/10 -j RETURN ip6t SSREDIR -t mangle -d ff00::/8 -j RETURN ip6t SSREDIR -t mangle -p tcp --syn -j MARK --set-mark 0x2333 ip6t SSREDIR -t mangle -p udp -m conntrack --ctstate NEW -j MARK --set-mark 0x2333 ip6t SSREDIR -t mangle -j CONNMARK --save-mark ip6t PREROUTING -t mangle -i br0 -p tcp -d 2600:1901:0:b2bd:: -j SSREDIR ip6t PREROUTING -t mangle -i br0 -p tcp -m mark --mark 0x2333 -j TPROXY --on-port 9172 ip6t PREROUTING -t mangle -i br0 -p udp -d 2600:1901:0:b2bd:: -j SSREDIR ip6t PREROUTING -t mangle -i br0 -p udp -m mark --mark 0x2333 -j TPROXY --on-port 9172 exit 0Так же сделаны настройки роутера
system set net.ipv4.ip_forward 1 set net.ipv6.conf.all.forwarding 1 set net.ipv4.tcp_fwmark_accept 1 !Тесты:
curl -4v https://ipecho.net/plain -- не работает
curl -6v https://ipecho.net/plain -- работает
Что не так для ipv4? Уже все ядро перелопатил, все должно работать.
-
4
-
-
2 часа назад, Sergey Grebnev сказал:
Исходные данные:
1. есть кинетик в Финляндии
2. есть свой впн
2.1 Один VPN на основе другого кинетика в РФ
2.1. Другой VPN на основе Outline Server на виртуальном сервере в РФ
Задача: Хочу определенные url в Финляндии открывать через российский IP, в частности ресурсы госорганов, а в последнее время еще и youtube (в общем, редактируемый список). Для этого было бы удобно использовать или outline server или свою сетку на кинетик в РФ. То есть, чтобы VPN этот был всегда включен, но использовался только при заходе на определенные URL.
Как этого сделать на кинетике в Финляндии?
Все очень просто. Ставите dnsmasq, dns-ipset или adguard home. Делаете в них настройку списков доменов, которые нужно перенаправить на сторонний интерфейс или службу. Dns-server после настройки будет резолвить имена для этих доменов в ipset.
Далее настраиваете маршрутизацию для ipset. Все профит!
-
29 минут назад, Roman Balaev сказал:
если один сервис использует 443 порт то другой уже просто не стартует с ошибкой
port 443 is already in useNпginx может проксировать все что угодно и куда угодно. Во первых можно настроить для xray транспорт ws или grpc. Во вторых можно развести потоки по доменному имени.
У меня на одном порту сейчас сидят сервисы WireGuard, SSH, Web, xray и nginx успешно это проксирует. А web вообще бесконечно разводится на сторонние сервисы Transmission, TorrServer, mtproxy и т.д.
Скрытый текстlocation /930aaabbb { if ( $content_type !~ "application/grpc" ) { return 404; } grpc_pass grpc://unix:/dev/shm/xray-vless-grpc.socket; grpc_set_header X-Real-IP $remote_addr; grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for; grpc_set_header X-Forwarded-Proto $scheme; }"network": "grpc", "grpcSettings": { "serviceName": "930aaabbb", "multiMode": true, "idle_timeout": 60, "health_check_timeout": 20, "initial_windows_size": 65536, "permit_without_stream": true, "connectionReuse": true },stream { map_hash_bucket_size 128; map_hash_max_size 16384; upstream vless_grpc_reality_sock { server unix:/dev/shm/xray-vless-grpc-reality.socket; # xray-vless-grpc-reality } upstream web_sock { server unix:/dev/shm/nginx-ssl-web.socket; # nginx-ssl-web } upstream wireguard { server 172.16.97.90:993; # WireGuard } map $ssl_preread_server_name $upstream { "tube.com" vless_grpc_reality_sock; default web_sock; } log_format log_stream '$remote_addr [$time_local] $protocol $ssl_preread_server_name $upstream $status $bytes_sent $bytes_received $session_time'; access_log /var/log/nginx/stream.log log_stream; server { listen 443 reuseport so_keepalive=on backlog=131072 fastopen=256; listen [::]:443; proxy_protocol on; proxy_pass $upstream; ssl_preread on; } server { listen 80 udp reuseport; listen [::]:80 udp; proxy_pass wireguard; proxy_socket_keepalive on; } }Можно еще применять лайфхак для сервисов, которые не поддерживают proxyprotocol, например ssh
Скрытый текстupstream ssh { server 127.0.0.1:22; # SSH } upstream ssh_sock { server unix:/var/run/nginx-ssh.sock; # SSH-Sock } map $ssl_preread_protocol $upstream { "" ssh_sock; default web_sock; } server { listen unix:/var/run/nginx-ssh.sock proxy_protocol; access_log off; proxy_pass ssh; } server { listen 443 reuseport; listen [::]:443; proxy_protocol on; proxy_pass $upstream; ssl_preread on; }-
1
-
-
31 минуту назад, Roman Balaev сказал:
Подскажите, а можно использовать отличный от 443 порт, так как он уже занят у меня на сервере под обратный прокси? в конфиге написано настоятельно рекмендуется, чем обернется использование другого порта?
А что мешает на одном порту держать несколько разных сервисов? Вообще ничего.
-
4 минуты назад, Роберт Зарипов сказал:
а почему redirect при ручном перезапуске xray долго срабатывает 25 минут аж
Правила либо есть, либо их нету в текущем состоянии iptables. Вам надо разбираться, что происходит. Проблем с redirect не наблюдаю еще со времен shadowsocks.
4.1.3 Перестал приходить шлюз ipv6
in Тестирование Dev-сборок
Posted
@Le ecureuil думаю проблема в том, что мне ra анонсируют два маршрутизатора. Хотелось бы иметь возможность firewall ipv6/4 еще и по mac
access-list _WEBADMIN_ISP
deny icmp6 src mac 00:34:56:78