Перейти к содержанию

Рекомендуемые сообщения

Опубликовано

Привет, у кого-нибудь есть проблемы с подключением к голосовым каналам в Discord? Мой конфиг работает через redirect, и добавление ext:geosite_v2fly.dat:discord не помогает.

P.S С серверами CS 2 тоже самое.

  • Ответов 2,5 тыс
  • Создана
  • Последний ответ

Топ авторов темы

Опубликовано

добры день почему у меня выдают вот такие ошибки вроде написано что shadowsocks и trojan тоже поддерживает 2023/10/01 05:48:47 [Warning] [4242030925] app/proxyman/outbound: failed to process outbound traffic > proxy/shadowsocks: failed to find an available destination > common/retry: [dial tcp 51.178.87.37:804: operation was canceled] > common/retry: all retry attempts failed
2023/10/01 05:48:47 [Warning] [2777104519] app/proxyman/outbound: failed to process outbound traffic > proxy/shadowsocks: failed to find an available destination > common/retry: [dial tcp 51.178.87.37:804: operation was canceled] > common/retry: all retry attempts failed
2023/10/01 05:48:47 [Warning] [547778611] app/proxyman/outbound: failed to process outbound traffic > proxy/shadowsocks: failed to find an available destination > common/retry: [dial tcp 51.178.87.37:804: i/o timeout dial tcp 51.178.87.37:804: operation was canceled] > common/retry: all retry attempts failed

Опубликовано
16 часов назад, Arch4Arts сказал:

у кого-нибудь есть проблемы с подключением к голосовым каналам в Discord?

у меня была проблема с совершением голосового звонка в Воцап, в режиме redirect, тупо звонок замирал на стадии "подключение". Как и выше отписавшийся человек, я тоже вернулся на режим socks.

Опубликовано (изменено)
3 часа назад, Роберт Зарипов сказал:

добры день почему у меня выдают вот такие ошибки вроде написано что shadowsocks и trojan тоже поддерживает 2023/10/01 05:48:47 [Warning] [4242030925] app/proxyman/outbound: failed to process outbound traffic > proxy/shadowsocks: failed to find an available destination > common/retry: [dial tcp 51.178.87.37:804: operation was canceled] > common/retry: all retry attempts failed
2023/10/01 05:48:47 [Warning] [2777104519] app/proxyman/outbound: failed to process outbound traffic > proxy/shadowsocks: failed to find an available destination > common/retry: [dial tcp 51.178.87.37:804: operation was canceled] > common/retry: all retry attempts failed
2023/10/01 05:48:47 [Warning] [547778611] app/proxyman/outbound: failed to process outbound traffic > proxy/shadowsocks: failed to find an available destination > common/retry: [dial tcp 51.178.87.37:804: i/o timeout dial tcp 51.178.87.37:804: operation was canceled] > common/retry: all retry attempts failed

Либо провайдер блокирует, либо Вы что-то делаете не так.
Я бы на Вашем месте сбросил VPS и настроил 3X-UI заново, после чего уже настроил бы с нуля Xkeen. Делов на 20 минут максимум.

Изменено пользователем adk
Опубликовано

Добрый день, подскажите пожалуйста или ткните в ответ если уже было.

Использую подключение через 10_d_routing.json

И заметил что если девайс находится в политике xray то скорость интренета режется протоколом VPN все равно не смотря на то, что я удалил из списка speedtest. Когда удаляю из политики скорость становится заявленной провайдером.

Значит ли это, что даже при хождении в директ подключение все равно идет какимто образом через сокс?

Опубликовано
12 минуты назад, Roman Balaev сказал:

Добрый день, подскажите пожалуйста или ткните в ответ если уже было.

Использую подключение через 10_d_routing.json

И заметил что если девайс находится в политике xray то скорость интренета режется протоколом VPN все равно не смотря на то, что я удалил из списка speedtest. Когда удаляю из политики скорость становится заявленной провайдером.

Значит ли это, что даже при хождении в директ подключение все равно идет какимто образом через сокс?

Все коннекты идут через xray. А он уже принимает решение, как дальше маршрутизировать, отсюда и падение скорости.

Опубликовано (изменено)

Самым производительным решением оказалась связка xkeen + kvas. При этом список доменов, которые должны идти через vpn, обрабатывает не xray, а kvas, остальные идут напрямую, минуя socks и redirect. В этом решении есть некоторые минусы, например kvas не работает с файлами geoip и geosite, поддерживается только список вручную указанных доменов, ну и автоматизации установки xkeen + kvas тоже нет, нужно поставить kvas с поддержкой shadowsocks, затем xkeen и вместо shadowsocks запустить xray на том-же порту по протоколу dokodemo-door (не используя режим redirect xkeen). Надеюсь авторы проектов скооперируются и выпустят совместимые между собой версии xkeen и kvas 💪 🙂

Изменено пользователем jameszero
Опубликовано
6 минут назад, jameszero сказал:

связка xkeen + kvas

Главный вопрос скорее, сколько такая связка сожрет оперативки, по сравнению с чистым xkeen. Ну и опять же, на данный момент такая связка скорее балаган на ровном месте.

Опубликовано (изменено)

добрый день почему когда я перезагружаю роутер xray сразу срабатывает а когда я вручную перезапускаю он только через 24 минуты срабатывает у меня подключение через redirect tproxy

Изменено пользователем Роберт Зарипов
Опубликовано
1 час назад, jameszero сказал:

Самым производительным решением оказалась связка xkeen + kvas. При этом список доменов, которые должны идти через vpn, обрабатывает не xray, а kvas, остальные идут напрямую, минуя socks и redirect. В этом решении есть некоторые минусы, например kvas не работает с файлами geoip и geosite, поддерживается только список вручную указанных доменов, ну и автоматизации установки xkeen + kvas тоже нет, нужно поставить kvas с поддержкой shadowsocks, затем xkeen и вместо shadowsocks запустить xray на том-же порту по протоколу dokodemo-door (не используя режим redirect xkeen). Надеюсь авторы проектов скооперируются и выпустят совместимые между собой версии xkeen и kvas 💪 🙂

Доброго Вам дня!
В одном из следующих обновлений могу сделать аналогичный мод для Xkeen, по спискам)

Чтобы Xray открывал только указанные в Вашем личном списке домены. Но, как Вы заметили, без GeoIP/GeoSite)

Опубликовано
28 минут назад, Роберт Зарипов сказал:

добрый день почему когда я перезагружаю роутер xray сразу срабатывает а когда я вручную перезапускаю он только через 24 минуты срабатывает у меня подключение через redirect tproxy

Здравствуйте!

За внесение правил в таблицу отвечает netfilter.
Он срабатывает автоматически, раз в промежуток времени.

Вы отредактировали init.d под tproxy?
Так как Xkeen пока что не поддерживает Tproxy полноценно, только в ближайшие несколько дней будет обновление для него.

Опубликовано
6 минут назад, Skrill0 сказал:

Здравствуйте!

За внесение правил в таблицу отвечает netfilter.
Он срабатывает автоматически, раз в промежуток времени.

Вы отредактировали init.d под tproxy?
Так как Xkeen пока что не поддерживает Tproxy полноценно, только в ближайшие несколько дней будет обновление для него.

я настроил его под ваши ленивые конфиги через dokodemo-door

Опубликовано
1 минуту назад, Роберт Зарипов сказал:

я настроил его под ваши ленивые конфиги через dokodemo-door

Tproxy требует дополнительной настройки в iptables с поднятием самого модуля Tproxy.
Без них Tproxy не поднимется

Опубликовано

но у меня он работает через интерфейсы без прокси

7 минут назад, Skrill0 сказал:

Tproxy требует дополнительной настройки в iptables с поднятием самого модуля Tproxy.
Без них Tproxy не поднимется

 

Опубликовано

 

22 минуты назад, Skrill0 сказал:

Здравствуйте!

За внесение правил в таблицу отвечает netfilter.
Он срабатывает автоматически, раз в промежуток времени.

Вы отредактировали init.d под tproxy?
Так как Xkeen пока что не поддерживает Tproxy полноценно, только в ближайшие несколько дней будет обновление для него.

Скажу по поводу tproxy - все мои эксперименты окончились фиаско. Длинные цепочки на keenetic работают очень плохо за счет постоянного их пересоздания и очистки. Думаю про tproxy можно забыть в длинных цепочках. А redirect работает и с udp. С ним проблем не наблюдаю.

Опубликовано
3 минуты назад, avn сказал:

 

Скажу по поводу tproxy - все мои эксперименты окончились фиаско. Длинные цепочки на keenetic работают очень плохо за счет постоянного их пересоздания и очистки. Думаю про tproxy можно забыть в длинных цепочках. А redirect работает и с udp. С ним проблем не наблюдаю.

а почему redirect при ручном перезапуске xray долго срабатывает 25 минут аж

Опубликовано
4 минуты назад, Роберт Зарипов сказал:

а почему redirect при ручном перезапуске xray долго срабатывает 25 минут аж

Правила либо есть, либо их нету в текущем состоянии iptables. Вам надо разбираться, что происходит. Проблем с redirect не наблюдаю еще со времен shadowsocks.

Опубликовано
11 минуту назад, Роберт Зарипов сказал:

а почему redirect при ручном перезапуске xray долго срабатывает 25 минут аж

На данном этапе не инициируется ручной перезапуск netfilter скрипта.
Используется автоматический запуск средствами ndm.

Можете попробовать инициировать его вручную

/opt/etc/ndm/netfilter.d/xray.sh


В следующем обновлении будет также и инициация.

Опубликовано
21 минуту назад, avn сказал:

Скажу по поводу tproxy - все мои эксперименты окончились фиаско. Длинные цепочки на keenetic работают очень плохо за счет постоянного их пересоздания и очистки. Думаю про tproxy можно забыть в длинных цепочках. А redirect работает и с udp. С ним проблем не наблюдаю.

Скажите, пожалуйста, а нет ли у Вас проблем с серверами игр Steam / WhatsApp?
У некоторых пользователей они возникают в работе с Redirect, при том, что UDP включен.

Т.е. redirect UDP есть и в inbounds по dokodemo-door udp влючен.

Опубликовано
7 минут назад, Skrill0 сказал:

На данном этапе не инициируется ручной перезапуск netfilter скрипта.
Используется автоматический запуск средствами ndm.

Можете попробовать инициировать его вручную

/opt/etc/ndm/netfilter.d/xray.sh


В следующем обновлении будет также и инициация.

спасибо помогло

Опубликовано

Подскажите, а можно использовать отличный от 443 порт, так как он уже занят у меня на сервере под обратный прокси? в конфиге написано настоятельно рекмендуется, чем обернется использование другого порта?

Опубликовано
16 минут назад, Skrill0 сказал:

Скажите, пожалуйста, а нет ли у Вас проблем с серверами игр Steam / WhatsApp?
У некоторых пользователей они возникают в работе с Redirect, при том, что UDP включен.

Т.е. redirect UDP есть и в inbounds по dokodemo-door udp влючен.

Добрый вечер, несколько раз пробовал redirect режим. Проблема возникает с играми в Steam, Ubisoft connect, с приложением Synology Active Backup (агент на ПК не может соединиться с устройством Synology ни по доменному имени, ни по IP адресу). Это из того, с чем лично столкнулся.

Опубликовано (изменено)
16 минут назад, Roman Balaev сказал:

Подскажите, а можно использовать отличный от 443 порт, так как он уже занят у меня на сервере под обратный прокси? в конфиге написано настоятельно рекмендуется, чем обернется использование другого порта?

Все будет работать, но провайдер | цензор может счесть трафик подозрительным. Так как классическое соединение для https запросов устанавливается через 443 порт.

А цель связки сделать соединение максимально приближенное к обычному интернет-серфингу, где-нибудь на rutube | amd | google и т.п.

Соответственно, Ваше соединение будет выглядеть [Устанавливает соединение по https > порт отличный от 443 = модифицированное соединение]

В outbounds на keenetic рекомендуется использовать 443 порт, а на reverse proxy в inbounds — также может быть 443 порт. Все должно работать.

Изменено пользователем Skrill0
Опубликовано
1 час назад, Skrill0 сказал:

В одном из следующих обновлений могу сделать аналогичный мод для Xkeen, по спискам)

Чтобы Xray открывал только указанные в Вашем личном списке домены.

Если при этом остальные домены будут идти прямым маршрутом, а не через xray  >> freedom, то это будет предел мечтаний)

Опубликовано
31 минуту назад, Roman Balaev сказал:

Подскажите, а можно использовать отличный от 443 порт, так как он уже занят у меня на сервере под обратный прокси? в конфиге написано настоятельно рекмендуется, чем обернется использование другого порта?

А что мешает на одном порту держать несколько разных сервисов? Вообще ничего.

Опубликовано
17 минут назад, avn сказал:

А что мешает на одном порту держать несколько разных сервисов? Вообще ничего.

если один сервис использует 443 порт то другой уже просто не стартует с ошибкой

port 443 is already in use

 

Опубликовано (изменено)
29 минут назад, Roman Balaev сказал:

если один сервис использует 443 порт то другой уже просто не стартует с ошибкой

port 443 is already in use

 

Nп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;
	}

 

 

Изменено пользователем avn
Опубликовано

Добрый вечер. Прежде всего большое спасибо автору за такой своевременный и масштабный проект.

У меня, к сожалению, пока не получается запустить систему. Прошу по возможности помощи.

Прежде всего, мне чертовски важен UDP, так что вариант с встроенным прокси не рассматриваю. Так же не могу использовать сторонние прокси в клиентах - роутер должен всё переварить сам). Мне не нужна фильтрация и гео-роутинг - я хочу всё завернуть в туннель.

Версия xkeen у меня актуальная. В режиме socks-прокси работает через внешний прокси-клиент (firefox), на стороне сервера подключение вижу (vless reality). Через встроенный прокси - не работает (не идёт трафик), ну да мне он и не нужен, я с ним особо не разбирался. А вот в режиме redirect весь трафик всегда идёт через провайдера, а не в туннель. В логах всё чисто, в системном логе xkeen рапортует о запуске в redirect режиме. Возможно подскажете, куда копать, спасибо! Далее прилагаю свои основные конфиги/диагностики. За основу брал "ленивый" пример из документации.

08_outbounds.json заполнен по рыбе и работает, думаю не нужен.

07_inbounds.json:

Скрытый текст

// Настройка исходящих соединений

{
    "inbounds": [
        {
            "listen": "192.168.99.1",    // Адрес Вашего шлюза
            "port": 54836,    // Порт на котором будет слушать Xray. Рекомендуется выбрать порт от 49152 до 65535
            "protocol": "dokodemo-door",
            "settings": {
                "network": "tcp,udp",
                "followRedirect": true
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls"
                ]
            },
            "tag": "socks-in"
        }
    ]
}

10_inbounds.json:

Скрытый текст

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "inboundTag": ["socks-in"],
        "outboundTag": "proxy",
        "type": "field"
      }
    ]
  }
}

iptables -t nat -L PREROUTING -n -v

на скриншоте

Спасибо!

image.png

Опубликовано
52 минуты назад, Sercha сказал:

Добрый вечер. Прежде всего большое спасибо автору за такой своевременный и масштабный проект.

У меня, к сожалению, пока не получается запустить систему. Прошу по возможности помощи.

Прежде всего, мне чертовски важен UDP, так что вариант с встроенным прокси не рассматриваю. Так же не могу использовать сторонние прокси в клиентах - роутер должен всё переварить сам). Мне не нужна фильтрация и гео-роутинг - я хочу всё завернуть в туннель.

Версия xkeen у меня актуальная. В режиме socks-прокси работает через внешний прокси-клиент (firefox), на стороне сервера подключение вижу (vless reality). Через встроенный прокси - не работает (не идёт трафик), ну да мне он и не нужен, я с ним особо не разбирался. А вот в режиме redirect весь трафик всегда идёт через провайдера, а не в туннель. В логах всё чисто, в системном логе xkeen рапортует о запуске в redirect режиме. Возможно подскажете, куда копать, спасибо! Далее прилагаю свои основные конфиги/диагностики. За основу брал "ленивый" пример из документации.

08_outbounds.json заполнен по рыбе и работает, думаю не нужен.

07_inbounds.json:

  Показать содержимое

// Настройка исходящих соединений

{
    "inbounds": [
        {
            "listen": "192.168.99.1",    // Адрес Вашего шлюза
            "port": 54836,    // Порт на котором будет слушать Xray. Рекомендуется выбрать порт от 49152 до 65535
            "protocol": "dokodemo-door",
            "settings": {
                "network": "tcp,udp",
                "followRedirect": true
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls"
                ]
            },
            "tag": "socks-in"
        }
    ]
}

10_inbounds.json:

  Показать содержимое

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "inboundTag": ["socks-in"],
        "outboundTag": "proxy",
        "type": "field"
      }
    ]
  }
}

iptables -t nat -L PREROUTING -n -v

на скриншоте

Спасибо!

image.png

Доброго Вам вечера!

ndm не отрабатывает сразу после внесения автоматом. Нужно немного подождать)
Попробуйте запустить руками:

/opt/etc/ndm/netfilter.d/xray.sh


В ближайшем обновлении будет исправлено)

Опубликовано
23 минуты назад, Skrill0 сказал:

Доброго Вам вечера!

ndm не отрабатывает сразу после внесения автоматом. Нужно немного подождать)
Попробуйте запустить руками:

/opt/etc/ndm/netfilter.d/xray.sh


В ближайшем обновлении будет исправлено)

Спасибо за поддержку!

Долгое ожидание ничего не даёт, увы, трафик  

На попытку запустить данный скрипт я получаю краткое "Permission denied"  (поискал поиском - вроде один такой)). Однако принудительный sh вроде исполняет этот скрипт.

Еще нюанс, что не применив эти правила - трафик идёт "не туда", что, в целом, тоже не комильфо в моём случае. В идеале было бы поведение "kill-switch", чтобы нет ножек-нет печенья... Боюсь подписку потерять на утечке).

Что касается подождать - это конечно, правда жду как на иголках т.к. в понедельник нужно будет надолго уехать и возможности (мм желания? "настраивать роутер удалённо - к долгой дороге/назад/!") настроить уже не будет. Я, конечно, прочёл, что ожидается прозрачный режим работы, и это прекрасно! Готов быть альфа-тестером )).

Но пока готов побороться за результат и с нынешней версией.. Возможно попробую вариант с tproxy, хотя боюсь это оверкилл для моих скиллов. Плюс вижу что добавили UDP функционал в штатный прокси - возможно стоит поэкспериментировать в сторону дев-версии прошивки?

image.png.c9f473a026378673d3ab8532497ba6a7.png

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.