
beubasser
-
Постов
10 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Сообщения, опубликованные beubasser
-
-
24 minutes ago, VT-i said:
Обновился до версии 1.8.7.
Со стороны клиента теперь посыпались ошибки вида:
[Warning] [2476795358] app/proxyman/outbound: failed to process outbound traffic > proxy/vless/outbound: failed to find an available destination > common/retry: [tls: first record does not look like a TLS handshake] > common/retry: all retry attempts failed [Info] [2476795358] app/proxyman/inbound: connection ends > proxy/dokodemo: connection ends > proxy/dokodemo: failed to transport response > io: read/write on closed pipe
Со стороны сервера:
[Info] transport/internet/tcp: REALITY: processed invalid connection REALITY remoteAddr: X.X.X.X:49606 hs.c.handshakeStatus: false
На сервере и клиенте версии одинаковые. Никак не хотят взлетать😔
Проверьте чтобы настройки в конфиге клиента и сервера совпадали, в частности encryption, flow, id, publicKey, fingerprint, serverName, shortId и spiderX.
Мой outbounds на клиенте:Spoiler{ "outbounds": [ { "domainStrategy": "UseIPv4", "protocol": "vless", "settings": { "vnext": [ { "address": "X.X.X.X", "port": 443, "users": [ { "encryption": "none", "flow": "xtls-rprx-vision", "id": "29917268-09b0-46f8-834b-a60ff6925734" } ] } ] }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "publicKey": "nMKOFMQDf6Ut74eEpuRyxq40ivemWEt4oLe8K8XbL18", "fingerprint": "firefox", "serverName": "google.com", "shortId": "5171500c", "spiderX": "/" } }, "tag": "proxy" } ] }
На сервере:
-
1 hour ago, VT-i said:
Добрый вечер!
Действительно, установлена старая версия: Xray 1.7.5.
Вероятно новая не ставится из-за отсутствия достаточного места на внутренней памяти в процессе распаковки.
Можете поделиться ссылкой на репозиторий откуда xkeen скачивает последние версии?
Я положу вручную свежую версию без переустановки. Архитектура mips32.
-
1
-
-
7 minutes ago, Alexey77 said:
Добрый день. Для tproxy в конфиге должно быть
"streamSettings": {
"sockopt": {
"tproxy": "tproxy"Хм. У меня ничего не поменялось, так же всё нормально работает. Но тоже как вариант, спасибо.
-
20 hours ago, iandrew said:
Добрый день! Не получается настроить по инструкции на raspberry pi. Устанавливаю адрес шлюза в настройках роутера, включаю ip forwaring на малине, переподключаю соединение на клиенте - все ок, трафик через через указанный шлюз. Но после применения правил iptables (и для redirect, и для tproxy) соединение ломается, только пинги приходят. В скрипте меняю адрес 192.168.1.127 на адрес raspberry в моей сети. Может быть я что-то не учел, забыл? Или может быть в каких-то логах можно найти ответ?
-
Для теста, попробуйте не менять DHCP настройки на роутере и настроить статический IP на одном клиенте.
Spoiler
- Посмотрите выключен ли сервис DHCP на малине и вместо этого стоят статические настройки (не через графический интерфейс, а прямо в командной строке выключить сервис dhcp и поставить статику). Роутер будет выдавать один и тот же шлюз ВСЕМ, в том числе малине. Малина будет ссылаться сама на себя и достучаться до неё не получится. Скорее всего не Ваш случай, но проверить стоит.
-
Попробуйте логи Xray. Так можно посмотреть, доходят ли запросы до Xray в принципе.
Spoiler
В конфиге Xray:
{ "log": { "access": "/home/pi/xray/access.log", "error": "/home/pi/xray/error.log", "logLevel": "debug" } }
Путь можно поставить любой. Главное чтобы файлы существовали и у Xray были права записи в них.
-
На клиенте попробуйте curl по IP адресу. Если получится так, но не получается по домену myip.wtf, есть проблемы в DNS.
curl 65.108.75.112/json # myip.wtf/json
-
Запустите packet capture в разделе Диагностика на кинетике (поставьте компонент).
Spoiler
-
Запросы от клиентов должны идти на MAC-адрес Вашей малины.
Где Ethernet Source и IP Src - мой телефон, Ethernet Destination - моя малина, а IP Dst 65.108.75.112 - myip.wtf
-
Потом от MAC-адреса малины на MAC-адрес роутера, который уже отправляет запрос на мою VPS по адресу 77.*.74.
Где Ethernet Source и IP Src - моя малина, Ethernet Destination - мой кинетик, а IP Dst 77.*.74 - моя VPS.
Малина получила ответ от myip.wtf и готова отправлять его моему телефону. -
Под конец, малина отправляет от своего MAC-адреса ответ MAC-адресу моего телефона.
Где Ethernet Source - моя малина, Ethernet Destination и IP Dst - мой телефон, а IP Src 65.108.75.112 - myip.wtf
-
Запросы от клиентов должны идти на MAC-адрес Вашей малины.
-
Проверьте конфиг, чтобы dokodemo-door работал на тех портах, которые указаны в правилах iptables. У меня такой конфиг:
Spoiler
{ "inbounds": [ { "listen": "192.168.1.127", "port": 10810, "protocol": "dokodemo-door", "settings": { "network": "tcp,udp", "followRedirect": true }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls" ] }, "tag": "doko-in" } ] }
-
Посмотрите все существующие правила в iptables. Может, какие-то уже существующие правила перебивают. Посмотрите увеличивается ли количество байтов и пакетов на правилах Xray.
iptables -t mangle -L --line-numbers -n -v # для TPROXY iptables -t nat -L --line-numbers -n -v # для REDIRECT
Я, конечно, ответил как типичный поверхностный гайд или чатгпт, но без диагностики не смогу помочь конкретно.
-
1
-
Для теста, попробуйте не менять DHCP настройки на роутере и настроить статический IP на одном клиенте.
-
21 hours ago, LDude said:
ХЗ, что у него не так, но у меня на том же проце (KN-1910) и с меньшей оперативой около 300 мбит в среднем, зависит от доступа до VPS. Бывает и до 500 доходит.
Да, ещё у меня Wireguard и OVPN подняты для других устройств на этом роутере.
И MESH ещё, ХЗ, влияет ли на проц.
А тесты точно идут через xray? Или идут только порты 80 и 443? Какая конфигурация?
-
On 1/1/2024 at 11:35 PM, madsen said:
а вам удалось продвинуться в этом вопросе? Конечно расстроен, что скорость сильно режется(
Вообще, костыльно получилось, но не работают интернет-звонки. Всё ещё не понимаю почему.
SpoilerВ Gateway IP пишется IP другого локального сервака типа распберри. На нём не нужно подрубать DHCP сервер, он останется на роутере, просто роутер будет давать всем клиентам другой IP шлюза вместо 192.168.1.1. Потом клиенты переподключаются или можно перезагрузить роутер.
Важно на этом локальном серваке отключить DHCP клиент и назначить IP шлюза вручную, т.е. 192.168.1.1, а то при перезапуске он будет ссылаться на самого себя и подключиться к нему не получится, а у других не будет интернета.
На этом сервере включается IP forwarding:Spoilernet.ipv4.ip_forward=1
И выполняются команды из xkeen:
Spoileriptables -t nat -N "XRAY_IPV4" iptables -t nat -A "XRAY_IPV4" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -t nat -A XRAY_IPV4 -d 0.0.0.0/8 -j ACCEPT iptables -t nat -A XRAY_IPV4 -d 10.0.0.0/8 -j ACCEPT iptables -t nat -A XRAY_IPV4 -d 127.0.0.0/8 -j ACCEPT iptables -t nat -A XRAY_IPV4 -d 169.254.0.0/16 -j ACCEPT iptables -t nat -A XRAY_IPV4 -d 172.16.0.0/12 -j ACCEPT iptables -t nat -A XRAY_IPV4 -d 192.168.0.0/16 -j ACCEPT iptables -t nat -A XRAY_IPV4 -d 224.0.0.0/4 -j ACCEPT iptables -t nat -A XRAY_IPV4 -d 240.0.0.0/4 -j ACCEPT iptables -t nat -A XRAY_IPV4 -d 255.255.255.255/32 -j ACCEPT iptables -t nat -A XRAY_IPV4 -p tcp -j REDIRECT --to-port 10810 iptables -t nat -A XRAY_IPV4 -p udp -j REDIRECT --to-port 10810 iptables -t nat -A PREROUTING -i eth0 -j "XRAY_IPV4"
Можно сделать iptables-persistent или добавлять правила скриптом при запуске.
Правила буквально перенаправляют любой трафик, приходящий на сервер с интерфейса eth0 и не адресованый самому серверу на порт 10810. На этом порту запущен xray с режимом dokodemo-door.
Spoiler{ "inbounds": [ { "listen": "192.168.1.127", "port": 10810, "protocol": "dokodemo-door", "settings": { "network": "tcp,udp", "followRedirect": true }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls" ] }, "tag": "doko-in" } ] }
Скорость нормальная, распберри загружена на 2/4, 3/4 при тесте скорости.
Но, опять же, звонки в том же дискорде не работают. Я не знаю почему. Поэтому ищу другие варианты, типа попробовать поднять другой tun2socks клиент на роутере. "По-простому" пока не получается. Стоковый SOCKS5 прокси на кинетике использует badvpn-tun2socks. Он медленный и даже не полностью нагружает роутер при тесте скорости. -
4 hours ago, Skrill0 said:
Доброго Вам дня!
Поддержки TProxy пока что нет в релизной версии Xkeen. В настоящий момент ведется работа над обновлением.
Для увеличения скорости рекомендую использовать метод Redirect + bbr на сервере.
Или можно выполнить полную оптимизацию именно сервераecho "tcp_bbr" > /etc/modules-load.d/modules.conf echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf echo "net.core.rmem_max = 67108864" >> /etc/sysctl.conf echo "net.core.wmem_max = 67108864" >> /etc/sysctl.conf echo "net.core.netdev_max_backlog = 10000" >> /etc/sysctl.conf echo "net.core.somaxconn = 4096" >> /etc/sysctl.conf echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf echo "net.ipv4.tcp_fin_timeout = 30" >> /etc/sysctl.conf echo "net.ipv4.tcp_keepalive_time = 1200" >> /etc/sysctl.conf echo "net.ipv4.tcp_keepalive_probes = 5" >> /etc/sysctl.conf echo "net.ipv4.tcp_keepalive_intvl = 30" >> /etc/sysctl.conf echo "net.ipv4.tcp_max_syn_backlog = 8192" >> /etc/sysctl.conf echo "net.ipv4.tcp_max_tw_buckets = 5000" >> /etc/sysctl.conf echo "net.ipv4.tcp_fastopen = 3" >> /etc/sysctl.conf echo "net.ipv4.tcp_mem = 25600 51200 102400" >> /etc/sysctl.conf echo "net.ipv4.udp_mem = 25600 51200 102400" >> /etc/sysctl.conf echo "net.ipv4.tcp_rmem = 4096 87380 67108864" >> /etc/sysctl.conf echo "net.ipv4.tcp_wmem = 4096 65536 67108864" >> /etc/sysctl.conf echo "net.ipv4.tcp_mtu_probing = 1" >> /etc/sysctl.conf echo "net.ipv4.tcp_slow_start_after_idle=0" >> /etc/sysctl.conf
Так же с самим конфигом тоже много проблем.
Используйте просто ленивый конфиг для Redirect, наполнив своими данными от сервера.
Он как раз сделан для Reality.Добрый день. Спасибо за советы, но к сожалению, это не помогает. Всё снова упирается в слабый процессор роутера, который еле тянет работу xray.
Конфиг на роутере:-
07_inbounds.json:
Spoiler
{ "inbounds": [ { "listen": "192.168.1.1", "port": 54836, "protocol": "dokodemo-door", "settings": { "network": "tcp,udp", "followRedirect": true }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls" ] }, "tag": "socks-in" } ] }
-
08_outbounds.json:
Spoiler
{ "outbounds": [ { "domainStrategy": "UseIPv4", "protocol": "vless", "settings": { "vnext": [ { "address": "***", "port": 443, "users": [ { "encryption": "none", "flow": "xtls-rprx-vision", "id": "***" } ] } ] }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "publicKey": "***", "fingerprint": "firefox", "serverName": "google.com", "shortId": "***", "spiderX": "/" } }, "tag": "proxy" }, { "protocol": "freedom", "tag": "direct" }, { "protocol": "blackhole", "tag": "block" } ] }
Конфиг на VPS:
- Inbound:
-
Клиент - роутер:
Spoiler
Твики на VPS:
Spoilerroot@inexpensive-pen:~# cat /etc/sysctl.conf ... net.ipv4.tcp_syncookies = 0 net.ipv4.tcp_congestion_control = bbr net.core.default_qdisc=fq net.ipv4.tcp_congestion_control=bbr net.core.rmem_max = 67108864 net.core.wmem_max = 67108864 net.core.netdev_max_backlog = 10000 net.core.somaxconn = 4096 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_keepalive_time = 1200 net.ipv4.tcp_keepalive_probes = 5 net.ipv4.tcp_keepalive_intvl = 30 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_max_tw_buckets = 5000 net.ipv4.tcp_fastopen = 3 net.ipv4.tcp_mem = 25600 51200 102400 net.ipv4.udp_mem = 25600 51200 102400 net.ipv4.tcp_rmem = 4096 87380 67108864 net.ipv4.tcp_wmem = 4096 65536 67108864 net.ipv4.tcp_mtu_probing = 1 net.ipv4.tcp_slow_start_after_idle=0
Neofetch на VPS:
SpoilerЛог запуска/остановки xkeen:
Spoiler
Со всем этим, результаты получились такие (все тесты с xray без правил маршрутизации, весь трафик идёт через VPS без исключений):- Htop во время бездействия:
- Прямой тест без xray, скорость провайдера:
- Тест с xray через NekoBox Android, прямое подключение к VPS по его IP:
- Тест с xray через NekoBox Android, подключение к raspberry pi в локальной сети по SOCKS, на которой стоит xray клиент с outbound на мою VPS:
- Тест с xray через NekoBox Android, подключение к raspberry pi в локальной сети по WireGuard inbound (MTU 1400), на которой стоит xray клиент с outbound на мою VPS:
- Тест с xkeen на роутере, REDIRECT, политика "xkeen" есть, клиент в неё занесён:
-
Тест с xray на raspberry, роутер подключается к raspberry по стоковому SOCKS5 из веб-интерфейса, предварительно выполнена команда
interface Proxy0 proxy socks5-udp
, создана политика "VPN" с приоритетом подключения к прокси, клиент в неё занесён: - Тест с xray на raspberry, роутер подключается к raspberry по стоковому WireGuard из веб-интерфейса, создана политика "VPN" с приоритетом подключения к WG-туннелю, клиент в неё занесён:
В общем, выглядит печально. Но в документации v2fly я увидел какую-то конфигурацию, когда IP raspberry ставится как основной шлюз на клиентах. В нашем случае можно перевести кинетик в режим Relay и вписать туда IP raspberry, которая и будет заниматься маршрутизацией. Пока буду копать в эту сторону.
Spoiler-
2
-
07_inbounds.json:
-
Товарищи, кто-то настраивал xray клиент на другой машине и перенаправлял трафик на неё с минимальными потерями в скорости?
У меня есть KN-1011, прошивка 4.1 Beta 2- Ставил xkeen на роутер и проц долбится в сотку уже на ~30 мбит/с, как с использованием встроенного SOCKS в вебе, так и через REDIRECT правила (dokodemo-door в конфиге). Судя по htop, скорость упирается в сам xray клиент.
- Поставил xray клиент на 4-ую Raspberry, перенаправлял трафик с помощью встроенных клиентов SOCKS и WireGuard. На SOCKS получилось максимум 40 мбит/с, а через WireGuard, на удивление, максимум 70 мбит/с.
-
Выполнял команду
interface Proxy0 proxy socks5-udp
Скорость так же режется.
Такие скорости меня не устраивают, тариф-то у меня 300 мбит/с, и прямое подключение к моему VPS через NekoBox тоже даёт 300 мбит/с. Скорость теряется даже если в правилах xray трафик идёт напрямую, не через VPS. Проблема исключительно в перенаправлении трафика с роутера на Raspberry. И это перенаправление ест много скорости.
Я ознакомился с TPROXY, но так и не понял, как правильно перенаправить. Получилось лишь полностью грохнуть интернет и доступ к роутеру, когда попробовал правила отсюда.
Мои вопросы таковы:- Как перенаправить трафик с помощью TPROXY на Raspberry? Есть ли примеры команд?
- Обрежет ли TPROXY скорости так же, как делают встроенные SOCKS и WireGuard клиенты на кинетике?
-
Как использовать TPROXY вместе с политиками подключений? Имею в виду эти:
Spoiler
- Есть какие-то альтернативные варианты перенаправления? Какие-нибудь сторонние прокси клиенты на кинетик, которые так не обрезают скорость?
Вот мой xray конфиг на Raspberry для референса:
Spoiler{ "dns": { "disableFallback": true, "servers": [ { "address": "https://8.8.8.8/dns-query", "domains": [], "queryStrategy": "" }, { "address": "localhost", "domains": [], "queryStrategy": "" } ], "tag": "dns" }, "inbounds": [ { "listen": "0.0.0.0", "port": 2080, "protocol": "socks", "settings": { "udp": true }, "sniffing": { "destOverride": [ "http", "tls", "quic" ], "enabled": true, "metadataOnly": false, "routeOnly": true }, "tag": "socks-in" }, { "listen": "0.0.0.0", "port": 2081, "protocol": "http", "sniffing": { "destOverride": [ "http", "tls", "quic" ], "enabled": true, "metadataOnly": false, "routeOnly": true }, "tag": "http-in" }, { "tag": "dokodemo-door", "port": 2082, "listen": "0.0.0.0", "protocol": "dokodemo-door", "settings": { "network": "tcp,udp", "followRedirect": true }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls" ] }, "streamSettings": { "sockopt": { "tproxy": "tproxy" } } }, { "tag": "wgserver", "listen": "0.0.0.0", "port": 8888, "protocol": "wireguard", "settings": { "secretKey": "***", "peers": [ { "publicKey": "***", "allowedIPs": [ "192.168.6.0/24" ] } ], "kernelMode": false, "mtu": 1400 } } ], "log": { "access": "/home/pi/Documents/xray/log/access.log", "error": "/home/pi/Documents/xray/log/error.log", "loglevel": "debug" }, "outbounds": [ { "tag": "proxy", "protocol": "vless", "domainStrategy": "AsIs", "flow": null, "settings": { "vnext": [ { "address": "***", "port": 443, "users": [ { "encryption": "none", "flow": "", "id": "***" } ] } ] }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "fingerprint": "firefox", "publicKey": "***", "serverName": "google.com", "shortId": "***", "spiderX": "/" }, "sockopt": { "mark": 2 } } }, { "tag": "direct", "protocol": "freedom", "domainStrategy": "", "streamSettings": { "sockopt": { "mark": 2 } } }, { "tag": "block", "protocol": "blackhole", "streamSettings": { "sockopt": { "mark": 2 } } }, { "tag": "dns-out", "protocol": "dns", "proxySettings": { "tag": "proxy", "transportLayer": true }, "settings": { "address": "8.8.8.8", "network": "tcp", "port": 53, "userLevel": 1 }, "streamSettings": { "sockopt": { "mark": 2 } } } ], "policy": { "levels": { "1": { "connIdle": 30 } }, "system": { "statsOutboundDownlink": true, "statsOutboundUplink": true } }, "routing": { "domainStrategy": "AsIs", "rules": [ { "inboundTag": [ "socks-in", "http-in" ], "outboundTag": "dns-out", "port": "53", "type": "field" }, { "outboundTag": "proxy", "port": "0-65535", "type": "field" } ] }, "stats": {} }
-
1
Xkeen
в Каталог готовых решений Opkg
Опубликовано · Изменено пользователем beubasser
И ещё тут, в логах буквально говорится "XTLS пока поддерживает только TCP, mKCP и DomainSocket". Значит, Вы на клиенте указали что-то другое вместо TCP, mKCP или DomainSocket. Используйте TCP.
Неправильно:
Правильно:
Опять же, должно соответствовать с сервером. На нём тоже надо поменять на TCP.