Skrill0
-
Постов
277 -
Зарегистрирован
-
Посещение
-
Победитель дней
38
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Skrill0
-
Тогда до выхода обновления можете руками обновить init скрипт по пути /opt/etc/init.d/S24xray. Это должно решить Вашу проблему)
-
Доброго Вам вечера! ndm не отрабатывает сразу после внесения автоматом. Нужно немного подождать) Попробуйте запустить руками: /opt/etc/ndm/netfilter.d/xray.sh В ближайшем обновлении будет исправлено)
-
Все будет работать, но провайдер | цензор может счесть трафик подозрительным. Так как классическое соединение для https запросов устанавливается через 443 порт. А цель связки сделать соединение максимально приближенное к обычному интернет-серфингу, где-нибудь на rutube | amd | google и т.п. Соответственно, Ваше соединение будет выглядеть [Устанавливает соединение по https > порт отличный от 443 = модифицированное соединение] В outbounds на keenetic рекомендуется использовать 443 порт, а на reverse proxy в inbounds — также может быть 443 порт. Все должно работать.
-
Скажите, пожалуйста, а нет ли у Вас проблем с серверами игр Steam / WhatsApp? У некоторых пользователей они возникают в работе с Redirect, при том, что UDP включен. Т.е. redirect UDP есть и в inbounds по dokodemo-door udp влючен.
-
На данном этапе не инициируется ручной перезапуск netfilter скрипта. Используется автоматический запуск средствами ndm. Можете попробовать инициировать его вручную /opt/etc/ndm/netfilter.d/xray.sh В следующем обновлении будет также и инициация.
-
Tproxy требует дополнительной настройки в iptables с поднятием самого модуля Tproxy. Без них Tproxy не поднимется
-
Здравствуйте! За внесение правил в таблицу отвечает netfilter. Он срабатывает автоматически, раз в промежуток времени. Вы отредактировали init.d под tproxy? Так как Xkeen пока что не поддерживает Tproxy полноценно, только в ближайшие несколько дней будет обновление для него.
-
Доброго Вам дня! В одном из следующих обновлений могу сделать аналогичный мод для Xkeen, по спискам) Чтобы Xray открывал только указанные в Вашем личном списке домены. Но, как Вы заметили, без GeoIP/GeoSite)
-
Всем доброго утра! Xkeen сейчас поддерживает работу в 2-х режимах Socks Redirect Socks — режим, который был изначально. Использовать можно через встроенный прокси-клиент Keenetic или через Proxy интерфейсы windows/браузера. Redirect — новый режим, перенаправляет вообще все соединение на Xray. Могут возникнуть проблемы с сервисами / играми, которые не любят работать с Proxy. Эта проблема должна быть решена с выходом Transparent proxy режима. Режимы включаются автоматически, в зависимости от содержимого Inbounds. Если у Вас соединение через Dokodemo-door, то будет использовать Redirect. Если через Socks — будет использоваться Socks. Выход режима Transparent proxy откладывается приблизительно на неделю, так как я немного заболела.
-
Сожалею, что так вышло. Попробуйте следующее решение. Будем направлять не все соединение, а только с портов 443 и 80 на xray, то есть тех, которые используются для интернет-серфинга. Обновите init.d файл S24xray до следующего содержимого Потом xkeen -stop xkeen -start
-
В таком случае Вам нужно оставить в routing только соединение «proxy». Использовать файл автоматического старта Xray из предыдущих версий Xkeen Соединение оставить также, через dokodemo-door и проложить маршрут до порта на котором слушает Xray. Теоретически, должно заработать
-
Тут можно посмотреть в 2 направлениях. 1. Попробуйте добавить в routing в direct подключение ext:geosite_v2fly.dat:steam 2. Попробуйте сменить поток на клиентской стороне на xtls-rprx-vision-udp443
-
На данном XTLS (не путать с ядром Xray) поддерживает транспорт TCP, mKCP и DomainSocket. Quic не очень подходит для проксирования. Внутри него есть механизмы, аналогичные функциональности TCP, такие как управление потоками, адаптация к изменяющимся условиям сети и некоторые другие. Когда он передается как UDP-трафик через протокол VLess, основным протоколом является TCP, что эквивалентно двум слоям TCP. Что касается mux, в контексте Quicи других протоколов, он может улучшить производительность и снизить задержки, объединяя несколько потоков в одном соединении без создания множества отдельных соединений.
-
Да, на стороне сервера можно оставить только xtls-rprx-vision Это значит, что на сервер Вы можете отправлять запросы http.3 | Quic, а с сервера получать классические ответы, что считается более надежным. Схематично выглядит так Mux должен быть включен только на стороне клиента. Для просмотра видео, загрузки и тестирования скоростей имеет негативные последствия. Позволяет объединить несколько запросов к серверу в 1. К примеру, мы отправляем 16 TCP запросов, Mux собирает их в 1 и отправляет на сервер.
-
Согласно китайским товарищам в чате Telegram, немного меняет логику обработки UDP в режиме мультиплексирования на 443 порту сервера и допускает обработку Quic | http.3. Для mux нужно будет также сменить "xudpProxyUDP443": "reject" на "xudpProxyUDP443": "allow". Flow также можно менять только на стороне клиента. На стороне сервера следует менять только в редких случаях. Пример секции mux в клиентской части Более детального описания, к сожалению, нет. Тесты также еще в пути. В общем, можно попробовать)
-
Благодарю) В дополнение ко всему на данном этапе можно попробовать сменить на сервере и в outbounds параметр flow xtls-rprx-vision на xtls-rprx-vision-udp443
-
Рада, что ситуация со скоростью теперь выглядит более оптимистично)
-
Если Вы из России, то для более точных замеров лучше использовать сервис от Yandex. Они проводят замеры на своих серверах. Speedtest работает скорее в роли Proxy. Если при замере заглянуть в журнал доступа, то сервер, который может выдать Speedtest, иногда оказывается в соединении proxy, когда он сам откроется через direct. В таком случае замер будет некачественным. Также, стоит помнить про разницу из-за шифрования. Правильно ли я поняла, что через встроенный прокси-клиент Ваше соединение достигало ~50мб/сек, а через redirect ~180?
-
Да, на данном этапе скорость упирается в оборудование. Пока что решения не найдено. Tproxy должен исправить проблему в локальных сетях с отображением, к примеру, других устройств в приложении. На ultra 1811 с redirect скорость с шифрованием всего соединения через Proxy упирается в download 300 и upload 550. * Шифрование применяется не часто, так как большая часть соединений уже шифрованы. Это для примера. На деле скорость будет выше. Видимо, на viva скорость упирается в 180. Скажите, пожалуйста, каким методом проводили замер скорости?
-
Всем доброго дня! Вышла версия 0.9.2 | Благодарю @adk за тестирование Журнал Обновиться можно командой xkeen -uk
-
Доброго Вам дня! Судя по команде iptables -t nat -L PREROUTING -n -v Правила redirect добавлены успешно. Сохраняется ли у Вас доступ к интернету? Попробуйте добавить в proxy-соединение speedtest или 2ip. Какой будет IP, сервера или Ваш? Также, попробуйте, пожалуйста, переустановить xkeen. Вижу некоторые проблемы с accept таблицей. xkeen -stop xkeen -k
-
В итоге все-таки все работает, включая redirect, правильно ли я поняла?
-
А Вы обновились на версию 0.9.1? Попробуйте xkeen -v
-
Рада, что все получилось) В логе роутера должна появиться следующая запись при запуске redirect-mode.
-
Видимо, не установился iptables. Вашу проблему решит opkg install iptables xkeen -stop xkeen -start Дополнительно проверю установщик необходимых пакетов. Благодарю за информацию!
