Эта статья - сборник разных вопросов и ответов на них, которые звучали в комментариях к моим предыдущим статьям (Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria, Cloak и все-все-все, Bleeding-edge обход блокировок с полной маскировкой: настраиваем сервер и клиент XRay с XTLS-Reality быстро и просто и других из той же серии) и в личных сообщениях.
Традиционная нейрокартинка для отвлечения внимания
1) разница между часовыми поясами у клиента в браузере и в локации IP-адреса с которого он подключается (например, в браузере московский часовой пояс, а сервер в Лондоне и там пояс другой) - обойти элементарно;
2) выявление по MTU - ненадежно, актуально для OpenVPN/L2TP/Wireguard/SSTP, для XRay и подобных прокси не актуально, т.к. они работают на другом уровне;
3) сканирование IP клиента на предмет открытых стандартных портов (например, 443) - можно обойти цепочкой из двух серверов с туннелем между ними;
Если вы используете мобильное устройство, то банковское (или любое другое приложение) может смотреть, активен ли в системе VPN-интерфейс, либо сравнивать геолокацию устройства и локацию по IP-адресу. Некоторые особо тупые российские сервисы по умолчанию считают что "любой доступ из-за рубежа - значит включен VPN". И еще некоторые сервисы (типа Open AI) по умолчанию запрещают доступ с non-residental IP-адресов (то есть 99.9% VPS-хостеров).
Либо ещё вариант: вы подключаетесь к сервису, сервис в ответ сканирует популярные порты IP-адреса с которого вы пришли, и видит там открытый 443 порт - тоже очень подозрительно, весьма вероятно что прокси, можно банить. Поэтому варианта два: или делать цепочку из двух прокси-серверов или один сервер с двумя разными адресами (сопоставить будет многократно сложнее), или создавать правила чтобы трафик от клиента до местных сайтов шел напрямую, а на прокси-сервере для надёжности резался.
Ну или мобильное приложение у вас на телефоне (имеющее доступ к геолокация или имени активной сотовой сети) видит что вы вроде внутри страны, но при этом подключение к их серверу происходит с какого-то иностранного адреса - тоже опачки
Под Windows, macOS, Linux и Android появился многообещающий клиент Hiddify-Next, написанный на Flutter и основанный на Sing-box - у него очень простой интерфейс, работает хорошо, умеет автоматически пропускать напрямую трафик до ресурсов выбранной страны (Россия в списке тоже есть), не требуя дополнительной настройки маршрутов, поддерживает и прокси- и TUN-режимы, а ещё при получении списка серверов под подписке может пинговать их всех и автоматически использовать тот, который отвечает лучше всего. Название у него совпадает с названием известной панели, но по факту он может работать с любыми совместимыми серверами.
Под iOS появился новый клиент Streisand - я не пробовал, кто уже пользовался, расскажите, как оно.
Сделать настройки Routing в конфиге, и в зависимости от ID пользователя, если destination IP совпадает с адресом разрешенной ему сети, то отправлять на соответствующий outbound'ы для этой сети, а все остальные запросы отправлять в block.
и в outbound'ах можно задать опцию sendthrough (https://xtls.github.io/en/config/outbound.html#outboundobject), чтобы трафик шел через правильный интерфейс.
Вот и считайте: когда вы запускаете тест, сначала устанавливается TCP-соединение с прокси-сервером (уже как минимум один, а то и два round-trip). Потом поверх него происходит TLS-хендшейк (ещё один round-trip), и в процессе него прокси-сервер ещё устанавливает TCP-соединение с reality-dest сервером и запрашивает у него сертификат. Потом прокси посылает запрос на установление TCP-соединения с тем сервером, который используется для теста. Потом, если URL указан как HTTPS, происходит ещё TLS-хендшейк с ним. Потом клиент делает HTTP-запрос и ждёт получения ответа. И только после ответа вы видите результат теста, и "задержка" - это суммарное время всего вышеописанного процесса.
Совет от@quakin:
Есть способ существенно уменьшить задержки для VLESS-Reality: маскироваться под сайт, пинг до которого от VPS минимальный.
Более продвинутый способ: использовать утилиту от авторов XTLS для выбора маскировочного сайта из той же подсети: RealiTLScanner.
В Sing-box, например, можно для каждого outbound'а задать "detour" (другой прокси), и таким образом достучаться до своего VLESS или Shadowsocks-сервера через корпоративный HTTP/SOCKS прокси. Если вы используете Nekobox, то нужно создать в Nekobox одно подключение типа HTTP или SOCKS (для корпоративного прокси с его адресом). Потом создать отдельно ещё одно подключение, VLESS для вашего сервера.
И потом создать третье подключение типа Proxy Chain, и в него добавить первые два в нужном порядке.
Если корпоративный прокси суровый (перешифровывает TLS с подменой сертификатов), то чистый VLESS скорее всего не пропустит, но вполне может работать вариант с websocket-транспортом.
Сделать это можно с помощью iptables DNAT:
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j DNAT --to-destination :555
ip6tables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j DNAT --to-destination :555
В этом примере сервер слушает порт 555, но клиент может подключиться к любому порту в диапазоне 20000–50000.
Ну либо перемещать себя в юрисдикцию, где нет блокировок по протоколам.
На главном экране в пункте Global routing выбираем Config:
Далее идем на вкладку Config, там идем в General:
Скроллим ниже к Skip Proxy, и добавляем туда новый пункт "*.ru":
Сохраняем. Всё, готово.
Если нужен еще GeoIP, то чуть сложнее.
Идем на MaxMind Geolite2 и регистрируемся там: https://dev.maxmind.com/geoip/geolite2-free-geolocation-data
Как зарегались и залогинились - нажимаем Manage License Keys -> Create License Key. Он сгенерит новую лицензию - важно сразу сохранить Account ID и License Key, ключ целиком показывается в интерфейсе только один раз, потом еще раз посмотреть уже нельзя будет!
В Shadowrocket идем в Settings, там ищем Geolite2, и заполняем наши данные:
Нажимаем Update - он должен подтянуть актуальную базу.
Потом как и в прошлом пункте, на главном экране выбираем Global Routing - Config, идем в Config, и там не в General, а в Rules:
Жмем плюсик, и создаем новое правило с типом geoip, policy = direct, и country/area пишем "RU" (обязательно большим буквами, иначе не сработает):
Сохраняем, пользуемся.
Nekobox на Windows/Linux/MacOS
GeoIP активируется стандартным образом в Nekobox (не забудьте поставить sniffing mode в "used for routing!"):
Правила по суффиксам Nekobox не умеет, но их умеет sing-box в его основе, поэтому жмем "Custom" и прописываем
вот такое
{
"rules": [
{
"domain_suffix": [
".ru"
],
"outbound": "direct"
}
]
}
После этого весь трафик до .ru-доменов и российских IP-адресов будет идти напрямую.
Если нужно заблокировать полностью - то в первом окне вместо Direct вставить в Block, а в JSON-коде исправить direct на block.
Nekobox Android
В Nekobox Android достаточно всего пару правил (раздельных, не два условия в одном правиле!), одного для доменов, другого для group.
И не забыть проверить, что в настройках включен sniffing:
Wings X / FoxRay iOS
Можно использовать только category-ru-gov , либол наоборот, не использовать ее, а прописать правила для всех .ru-доменов и российских IP как ниже
v2rayN Android
и в Custom rules вписать вот такое:
возможно вариант с доменом может привести к ложным срабатываниям для адресов типа www.rust.org, тогда можно оставить только geoip, для большинства случаев этого будет достаточно.
И подсовываете их в ваш клиент. После этого настраиваете маршрутизацию как обычно, например, в качестве дефолтного маршрута выбираете bypass (direct), а через прокси пускаете IP-адреса по тегу geoip:antizapret и домены по тегуgeosites:antizapret
Также есть очень интересные списки на https://github.com/v2fly/domain-list-community
В режиме system proxy устанавливается системный параметр, а вот использовать его или нет, зависит уже от самого приложения — браузеры его используют, а некоторые программы вообще не умеют и не хотят.
В режиме TUN заворачивается весь системный трафик, можно попробовать с ним, должно помочь.
Ну и правила применяются сверху вниз, то есть первое правило которое полностью совпало, оно и будет использоваться
Это не проблема конкретно V2Ray/Xray/SS, это будет для любых прокси/VPN, работающих через TUN. Решение: включить IPv6 в клиенте (даже если сервер не поддерживает), либо отключить IPv6 на сетевом устройстве (LAN или WiFi).
https://github.com/aaaamirabbas/nekoray-macos/releases
Как сделать, чтобы оно работало:
Если у вас и клиент и сервер на базе XRay свежих версий (1.8.3 и новее), то все должно работать автоматически.
Если у вас клиент на базе Sing-box (например, Nekobox), то надо явно в настройках подключения выбрать XUDP в параметре "Packet encoding".
Если у вас клиент на базе XRay, а сервер на базе Sing-box, то есть риск что ничего работать не будет, нужно менять клиент или сервер.
У XRay совершенно точно трафик не прогоняется через какие-либо сервера ни в Иране, ни где-либо еще - это не то чтобы даже невозможно, но точно бессмысленно технически. В коде XRay ничего подобного нет.
Было подозрение что автор панели добавил в XRay какую-то отсебятину - проверили, в docker-образе оно собирается из исходников с гита, там никаких подозрительных патчей нет, и потом еще кто-то в комментариях к одной из старых статей пожаловался на такое же, только не про Иран, а про Китай
Для уверенности мы довольно долго смотрели в netstat и wireshark, вердикт - никаких левых подключений не делается.
Была теория, что возможно где-то в коде или конфигах захардкожены какие-нибудь региональные DNS-сервера (региональный сервер, резовля условный гугл и ютуб, может отдать его же адреса региональных зеркал и гугл с ютубом подумают, что вы оттуда) - опять же, в коде и конфигах ничего такого не нашлось.
Но есть еще одна теория. Nekobox (возможно другие клиенты тоже, не проверял) в качестве "внутреннего" IPv6 адреса использует адрес из такого зарезервированного диапазона (ULA), где они должны генерироваться рандомно, и вероятность совпадения двух рандомных адресов ничтожна. То есть такой адрес должен быть уникальным, но в Nekobox он наоборот захардкожен один для всех случаев, и в итоге некоторые сервисы, которые могут каким-то образом получать и анализировать локальные адреса клиентов (например, Google с его телеметрией в Chrome и в Android), считают всех клиентов с таким внутренним адресом... одним и тем же клиентом, после чего сопоставляют их то ли с геолокацией, то ли с другими внутренними адресами, то ли и с тем и с тем, и в итоге в ряде случаев все пользователи Nekobox (и возможно других клиентов) для Гугла выглядят как пользователи откуда-то из Ирана, Китая или Азербайджана, вплоть до того, что со временем Гугл начинает считать публичный адрес прокси-сервера тоже иранским/китайским/etc, и это приводит к довольно забавным эффектам.
Варианты решения: не использовать TUN-режим (он же VPN mode), либо в правилах маршрутизации клиента или сервера запретить доступ до Google по IPv6, либо пропатчить клиент чтобы он использовал какой-нибудь другой внутренний адрес.
Последняя такая версия — 3.17, файл называется "nekoray-3.17-2023-08-17-windows7-x64.zip".
Начать расследование можно с команды "netstat -nlp", которая покажет, действительно ли ваш прокси-сервер слушает входящие подключения, на каком именно IP и на каком порту.
Плюс проверьте конфигурацию фаервола согласно инструкциям для вашего дистрибутива, у некоторых дистрибутивов/хостеров по умолчанию есть правила, закрывающие все порты кроме явно разрешенных.
Также убедитесь, что вам не мешает локальный антивирус и его фаервол (например, некоторые жаловались на проблемы при наличии Касперского на клиентской машине).
Похоже на протухшие системные корневые сертификаты из-за очень старой ОС без обновлений. Как вариант - попробовать поменять remote DNS в клиенте с https://8.8.8.8 на просто 8.8.8.8 или 1.1.1.1 (без https).
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p
либо более полный вариант тюнинга
На некоторых системах модуль bbr может быть не загружен по умолчанию, если
# sysctl net.ipv4.tcp_available_congestion_control
не выдает в списке bbr:
net.ipv4.tcp_available_congestion_control = reno cubic hybla vegas yeah
необходимо добавить и ребутнуться:
echo “tcp_bbr” > /etc/modules‑load.d/modules.conf
Готово. При этом тут в докер файле настройки и так хранятся в отдельном volume, поэтому ничего не сотрется.
habr.com
Традиционная нейрокартинка для отвлечения внимания
Разное
Классических способов выявить прокси/VPN не так много, самые известные:
1) разница между часовыми поясами у клиента в браузере и в локации IP-адреса с которого он подключается (например, в браузере московский часовой пояс, а сервер в Лондоне и там пояс другой) - обойти элементарно;
2) выявление по MTU - ненадежно, актуально для OpenVPN/L2TP/Wireguard/SSTP, для XRay и подобных прокси не актуально, т.к. они работают на другом уровне;
3) сканирование IP клиента на предмет открытых стандартных портов (например, 443) - можно обойти цепочкой из двух серверов с туннелем между ними;
Если вы используете мобильное устройство, то банковское (или любое другое приложение) может смотреть, активен ли в системе VPN-интерфейс, либо сравнивать геолокацию устройства и локацию по IP-адресу. Некоторые особо тупые российские сервисы по умолчанию считают что "любой доступ из-за рубежа - значит включен VPN". И еще некоторые сервисы (типа Open AI) по умолчанию запрещают доступ с non-residental IP-адресов (то есть 99.9% VPS-хостеров).
Суть Reality в маскировке под какой-либо популярный сайт, поэтому когда вы решаете это делать, вам нужно добиться того, чтобы ваш IP (IP вашего VPS) вел себя полностью идентично настоящему серверу, которым вы прикидываетесь. Если тот "настоящий" сервер слушает на 80-м порту (plain HTTP), то вам тоже нужно настроить nginx или правило фаервола, чтобы переадресовывать HTTP-запросы на оригинальный сервер. Если "настоящий" сервер не слушает SSH-подключения на стандартном 22-м порту, то ваш тоже не должен. Если ваш хостер предоставляет reverse-DNS записи для IP-адреса, убедитесь, что там не осталось значение по умолчанию (обычно с доменом хостера), а лучше задайте такой reverse-DNS, какой виден у IP-адреса ресурса, под который вы маскируетесь.
По закону Яровой у нас давно уже пишутся все метаданные интернет-активности (куда, когда, откуда были подключения, какие объемы данных передавались, и т.д.). В теории (но судя по тому, насколько часто встречается эти совет на китайских сайтах, у них это уже не в теории) возможно следующее: вы случайно (даже просто зайдя на какой-нибудь обычный сайт, который подгрушит скрипту или контент с другого сервера) через свой прокси делаете запрос на условный Яндекс/Мейл/ВК/Госуслуги. В логах метаданных видно: подключение от вас на какой-то внешний IP, и точно в тот же самый момент подключение с этого IP к сервису внутри страны (который, понятное дело, тоже подконтрольный), объемы переданных данных одинаковы (с учётом оверхеда протокола) - и после ряда таких совпадений можно однозначно сказать что на этом адресе работает прокси.
Либо ещё вариант: вы подключаетесь к сервису, сервис в ответ сканирует популярные порты IP-адреса с которого вы пришли, и видит там открытый 443 порт - тоже очень подозрительно, весьма вероятно что прокси, можно банить. Поэтому варианта два: или делать цепочку из двух прокси-серверов или один сервер с двумя разными адресами (сопоставить будет многократно сложнее), или создавать правила чтобы трафик от клиента до местных сайтов шел напрямую, а на прокси-сервере для надёжности резался.
Ну или мобильное приложение у вас на телефоне (имеющее доступ к геолокация или имени активной сотовой сети) видит что вы вроде внутри страны, но при этом подключение к их серверу происходит с какого-то иностранного адреса - тоже опачки
У Nekobox появилась русская локализация, а также в качестве ядра, помимо sing-box, там теперь можно использовать xray вместо безнадежно устаревшего v2ray.
Под Windows, macOS, Linux и Android появился многообещающий клиент Hiddify-Next, написанный на Flutter и основанный на Sing-box - у него очень простой интерфейс, работает хорошо, умеет автоматически пропускать напрямую трафик до ресурсов выбранной страны (Россия в списке тоже есть), не требуя дополнительной настройки маршрутов, поддерживает и прокси- и TUN-режимы, а ещё при получении списка серверов под подписке может пинговать их всех и автоматически использовать тот, который отвечает лучше всего. Название у него совпадает с названием известной панели, но по факту он может работать с любыми совместимыми серверами.
Под iOS появился новый клиент Streisand - я не пробовал, кто уже пользовался, расскажите, как оно.
3X-UI такое вроде не умеет, а голый XRay кажется настроить можно.
Сделать настройки Routing в конфиге, и в зависимости от ID пользователя, если destination IP совпадает с адресом разрешенной ему сети, то отправлять на соответствующий outbound'ы для этой сети, а все остальные запросы отправлять в block.
и в outbound'ах можно задать опцию sendthrough (https://xtls.github.io/en/config/outbound.html#outboundobject), чтобы трафик шел через правильный интерфейс.
Да, норм. Два важных отличия от других технологий: 1) в отличие от VPN, где подключение к VPN-серверу устанавливается один раз и все, в случае с прокси, на каждое исходящее подключение из клиентского софта устанавливается новое подключение к прокси-серверу (если только не используется мультиплексирование) 2) поскольку через прокси невозможно послать ICMP-пинг, большинство клиентов меряют задержку не пингом, а выполнением HTTP-запроса.
Вот и считайте: когда вы запускаете тест, сначала устанавливается TCP-соединение с прокси-сервером (уже как минимум один, а то и два round-trip). Потом поверх него происходит TLS-хендшейк (ещё один round-trip), и в процессе него прокси-сервер ещё устанавливает TCP-соединение с reality-dest сервером и запрашивает у него сертификат. Потом прокси посылает запрос на установление TCP-соединения с тем сервером, который используется для теста. Потом, если URL указан как HTTPS, происходит ещё TLS-хендшейк с ним. Потом клиент делает HTTP-запрос и ждёт получения ответа. И только после ответа вы видите результат теста, и "задержка" - это суммарное время всего вышеописанного процесса.
Совет от@quakin:
Есть способ существенно уменьшить задержки для VLESS-Reality: маскироваться под сайт, пинг до которого от VPS минимальный.
Более продвинутый способ: использовать утилиту от авторов XTLS для выбора маскировочного сайта из той же подсети: RealiTLScanner.
XRay и Sing-box умеют делать цепочки прокси.
В Sing-box, например, можно для каждого outbound'а задать "detour" (другой прокси), и таким образом достучаться до своего VLESS или Shadowsocks-сервера через корпоративный HTTP/SOCKS прокси. Если вы используете Nekobox, то нужно создать в Nekobox одно подключение типа HTTP или SOCKS (для корпоративного прокси с его адресом). Потом создать отдельно ещё одно подключение, VLESS для вашего сервера.
И потом создать третье подключение типа Proxy Chain, и в него добавить первые два в нужном порядке.
Если корпоративный прокси суровый (перешифровывает TLS с подменой сертификатов), то чистый VLESS скорее всего не пропустит, но вполне может работать вариант с websocket-транспортом.
Пользователи из Китая писали, что когда GFW банит подключения к их прокси-серверу, ограничения часто применяются только к конкретному используемому порту. В качестве обходного пути в этой ситуации можно использовать port hopping, когда прокси-сервер слушает сразу на сотнях портов, и подключаться можно к любому - это может быть очень полезно при использовании Shadowsocks.
Сделать это можно с помощью iptables DNAT:
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j DNAT --to-destination :555
ip6tables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j DNAT --to-destination :555
В этом примере сервер слушает порт 555, но клиент может подключиться к любому порту в диапазоне 20000–50000.
В конфигурации клиента и сервера нужно использовать method который начинается с "2022-", например 2022-blake3-aes-128-gcm и 2022-blake3-aes-256-gcm (это стандартные), или 2022-blake3-chacha20-poly1305, 2022-blake3-chacha12-poly1305, 2022-blake3-chacha8-poly1305 (это extra).
Если все это слишком сложно - то советую Amnezia VPN, он устанавливается на любой сервер двумя кликами в понятном интерфейсе, есть клиенты под все платформы, и они тоже активно работают над защитой от выявления и блокирования.
Ну либо перемещать себя в юрисдикцию, где нет блокировок по протоколам.
Настройка маршрутизации и клиентов
Shadowrocket на iOS
На главном экране в пункте Global routing выбираем Config:
Далее идем на вкладку Config, там идем в General:
Скроллим ниже к Skip Proxy, и добавляем туда новый пункт "*.ru":
Сохраняем. Всё, готово.
Если нужен еще GeoIP, то чуть сложнее.
Идем на MaxMind Geolite2 и регистрируемся там: https://dev.maxmind.com/geoip/geolite2-free-geolocation-data
Как зарегались и залогинились - нажимаем Manage License Keys -> Create License Key. Он сгенерит новую лицензию - важно сразу сохранить Account ID и License Key, ключ целиком показывается в интерфейсе только один раз, потом еще раз посмотреть уже нельзя будет!
В Shadowrocket идем в Settings, там ищем Geolite2, и заполняем наши данные:
Нажимаем Update - он должен подтянуть актуальную базу.
Потом как и в прошлом пункте, на главном экране выбираем Global Routing - Config, идем в Config, и там не в General, а в Rules:
Жмем плюсик, и создаем новое правило с типом geoip, policy = direct, и country/area пишем "RU" (обязательно большим буквами, иначе не сработает):
Сохраняем, пользуемся.
Nekobox на Windows/Linux/MacOS
GeoIP активируется стандартным образом в Nekobox (не забудьте поставить sniffing mode в "used for routing!"):
Правила по суффиксам Nekobox не умеет, но их умеет sing-box в его основе, поэтому жмем "Custom" и прописываем
вот такое
{
"rules": [
{
"domain_suffix": [
".ru"
],
"outbound": "direct"
}
]
}
После этого весь трафик до .ru-доменов и российских IP-адресов будет идти напрямую.
Если нужно заблокировать полностью - то в первом окне вместо Direct вставить в Block, а в JSON-коде исправить direct на block.
Nekobox Android
В Nekobox Android достаточно всего пару правил (раздельных, не два условия в одном правиле!), одного для доменов, другого для group.
И не забыть проверить, что в настройках включен sniffing:
Можно использовать только category-ru-gov , либол наоборот, не использовать ее, а прописать правила для всех .ru-доменов и российских IP как ниже
и в Custom rules вписать вот такое:
возможно вариант с доменом может привести к ложным срабатываниям для адресов типа www.rust.org, тогда можно оставить только geoip, для большинства случаев этого будет достаточно.
Можно, ага. Качаете geoip.db и geosite.db вот отсюда: https://github.com/L11R/antizapret-sing-box-geo
И подсовываете их в ваш клиент. После этого настраиваете маршрутизацию как обычно, например, в качестве дефолтного маршрута выбираете bypass (direct), а через прокси пускаете IP-адреса по тегу geoip:antizapret и домены по тегуgeosites:antizapret
Также есть очень интересные списки на https://github.com/v2fly/domain-list-community
Это зависит от режима работы клиента.
В режиме system proxy устанавливается системный параметр, а вот использовать его или нет, зависит уже от самого приложения — браузеры его используют, а некоторые программы вообще не умеют и не хотят.
В режиме TUN заворачивается весь системный трафик, можно попробовать с ним, должно помочь.
Надо смотреть настройки сниффинга в клиенте — во-первых он должен быть включен, и не AsIs, а что-то типа "Sniff for routing" или "Resolve Destination" (в зависимости от клиента):
У XRay есть специфика, там если заданы условия, по которым будет применять тот или иной роут (например, айпи назначения из такой-то подсети, inbound такой-то, протокол такой-то), то он применит этот роут только если все условия будут выполнены.
Ну и правила применяются сверху вниз, то есть первое правило которое полностью совпало, оно и будет использоваться
Если используется TUN-режим, в клиенте не включен IPv6 (на сервере - не важно), и при этом IPv6 предоставляется вашим провайдером - есть вероятность, что трафик до IPv4-ресурсов будет идти через прокси, а до IPv6-ресурсов - напрямую.
Это не проблема конкретно V2Ray/Xray/SS, это будет для любых прокси/VPN, работающих через TUN. Решение: включить IPv6 в клиенте (даже если сервер не поддерживает), либо отключить IPv6 на сетевом устройстве (LAN или WiFi).
Есть неофициальные билды под мак:На Гитхабе больше нет билдов Nekoray под MacOS
https://github.com/aaaamirabbas/nekoray-macos/releases
Большинство что консольных, что GUI клиентов Shadowsocks/Trojan/VLESS не требуют установки (достаточно кинуть файлы в папочку и запустить) и не требуют административного доступа. Но есть один нюанс: не получится работать через TUN-интерфейс (для установки драйвера и настройки сети нужны админские права), только через локальный прокси. Настройки прокси в винде, насколько я помню, может менять даже непривелигированный пользователь, и даже если админы запретили это делать, можно использовать браузер который не завязывается на системные настройки (например, Firefox точно так умеет).
Проблемы, ошибки, диагностика
Аудио- и видео- звонки, как и большинство игр, обычно используют передачу данных по UDP. VLESS/VMess/Shadowsocks поддерживают UDP, но у них есть проблемы с сохранением номера порта при реализации NAT, в результате чего могут быть проблемы. Для решения этих проблем разрабочики XRay придумали XUDP - специальное расширение протоколо, которое даст вам полноценный Full Cone NAT.
Как сделать, чтобы оно работало:
Если у вас и клиент и сервер на базе XRay свежих версий (1.8.3 и новее), то все должно работать автоматически.
Если у вас клиент на базе Sing-box (например, Nekobox), то надо явно в настройках подключения выбрать XUDP в параметре "Packet encoding".
Если у вас клиент на базе XRay, а сервер на базе Sing-box, то есть риск что ничего работать не будет, нужно менять клиент или сервер.
В настройках FoxRay в меню Toolbox есть опция "reduce memory usage", возможно поможет.
Это загадка черной дыры, над которой мы долго ломали голову и так полностью и не разгадали.
У XRay совершенно точно трафик не прогоняется через какие-либо сервера ни в Иране, ни где-либо еще - это не то чтобы даже невозможно, но точно бессмысленно технически. В коде XRay ничего подобного нет.
Было подозрение что автор панели добавил в XRay какую-то отсебятину - проверили, в docker-образе оно собирается из исходников с гита, там никаких подозрительных патчей нет, и потом еще кто-то в комментариях к одной из старых статей пожаловался на такое же, только не про Иран, а про Китай
Для уверенности мы довольно долго смотрели в netstat и wireshark, вердикт - никаких левых подключений не делается.
Была теория, что возможно где-то в коде или конфигах захардкожены какие-нибудь региональные DNS-сервера (региональный сервер, резовля условный гугл и ютуб, может отдать его же адреса региональных зеркал и гугл с ютубом подумают, что вы оттуда) - опять же, в коде и конфигах ничего такого не нашлось.
Но есть еще одна теория. Nekobox (возможно другие клиенты тоже, не проверял) в качестве "внутреннего" IPv6 адреса использует адрес из такого зарезервированного диапазона (ULA), где они должны генерироваться рандомно, и вероятность совпадения двух рандомных адресов ничтожна. То есть такой адрес должен быть уникальным, но в Nekobox он наоборот захардкожен один для всех случаев, и в итоге некоторые сервисы, которые могут каким-то образом получать и анализировать локальные адреса клиентов (например, Google с его телеметрией в Chrome и в Android), считают всех клиентов с таким внутренним адресом... одним и тем же клиентом, после чего сопоставляют их то ли с геолокацией, то ли с другими внутренними адресами, то ли и с тем и с тем, и в итоге в ряде случаев все пользователи Nekobox (и возможно других клиентов) для Гугла выглядят как пользователи откуда-то из Ирана, Китая или Азербайджана, вплоть до того, что со временем Гугл начинает считать публичный адрес прокси-сервера тоже иранским/китайским/etc, и это приводит к довольно забавным эффектам.
Варианты решения: не использовать TUN-режим (он же VPN mode), либо в правилах маршрутизации клиента или сервера запретить доступ до Google по IPv6, либо пропатчить клиент чтобы он использовал какой-нибудь другой внутренний адрес.
Если пытаетесь сканировать QR из X-UI панели — можно попробовать сначала добавить подключение оттуда по ссылке в локальный Nekoray, а уже оттуда пошарить QR. Ну и проверить, что в названии конфига и параметрах нет никаких лишних символов (кириллицы, амперсантов, вопросов, точек, лишних слешей, и т.д.)
Проверьте, что у вас в /etc/resolv.conf
Что-то не то с ключом. Можно еще раз перегенерировать в панели (если используете панель), или с 'openssl rand -base64 16' или 'openssl rand -base64 32' (в зависимости от длины используемого шифра).
Ну ошибка говорит сама за себя: "address already in use" = на сервере на 443 порту запущен уже какой-то другой процесс. Можно посмотреть командой 'netstat -nlp' от рута, она покажет, какой процесс слушает какой порт.
В линуксе выхлоп нетстата типа "tcp6 :::2323" обычно означает что сокет доступен и по IPv6, и по IPv4.
Если у вас старая версия Windows, то нужно использовать старые версии Nekoray — в новых уже нет поддержки Windows 7 (и Windows 8 кажется тоже).
Последняя такая версия — 3.17, файл называется "nekoray-3.17-2023-08-17-windows7-x64.zip".
Увы, никак. В 99% случаев когда что-то не контачится, это будет какое-то несоответствие конфигурации между клиентом и сервером. Сам протокол сделан так, чтобы быть максимально недетектируемым, поэтому если серверу что-то не нравится (например, не совпал ключ пользователя, или еще что), то в ответ он не пришлет никаких ошибок чтобы не демаскировать себя, а будет молчать или рвать соединение - и остается только угадывать по логам.
Ну собственно клиент говорит как есть — он не может подключиться к серверу. Либо на сервере не запущен процесс, либо фаервол на сервере блокирует подключения, либо фаервол на клиенте блокирует подключения, либо что-то не то с настройками.
Начать расследование можно с команды "netstat -nlp", которая покажет, действительно ли ваш прокси-сервер слушает входящие подключения, на каком именно IP и на каком порту.
Плюс проверьте конфигурацию фаервола согласно инструкциям для вашего дистрибутива, у некоторых дистрибутивов/хостеров по умолчанию есть правила, закрывающие все порты кроме явно разрешенных.
Также убедитесь, что вам не мешает локальный антивирус и его фаервол (например, некоторые жаловались на проблемы при наличии Касперского на клиентской машине).
Похоже на протухшие системные корневые сертификаты из-за очень старой ОС без обновлений. Как вариант - попробовать поменять remote DNS в клиенте с https://8.8.8.8 на просто 8.8.8.8 или 1.1.1.1 (без https).
https://github.com/abbasnaqdi/nekoray-macos/issues/36 -> 'sudo /Applications/nekoray_arm64.app/Contents/MacOS/nekoray'
Без SSL-сертфиката и https-ссылки на подписку ничего не будет работать на iOS.
Проверьте настройки uTLS. Почему-то у многих клиентов при установке uTLS как "android" подключение фейлится, при установке uTLS как "chrome" - все работает. Не совсем понятно, это баг на стороне клиента или сервера, но баг интересный.
Настройте BBR на сервере, станет гораздо веселее:
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p
либо более полный вариант тюнинга
На некоторых системах модуль bbr может быть не загружен по умолчанию, если
# sysctl net.ipv4.tcp_available_congestion_control
не выдает в списке bbr:
net.ipv4.tcp_available_congestion_control = reno cubic hybla vegas yeah
необходимо добавить и ребутнуться:
echo “tcp_bbr” > /etc/modules‑load.d/modules.conf
Это известная проблема со стороны Гугла при доступе с некоторых VPS по IPv6. Стоит попробовать отключить IPv6 в клиенте, если включен (обычно в настройках TUN-режима, если используете его), также в настройках DNS/роутинга выбрать PreferIPv4 если есть такая опция. Если ничего не помогает, то последний метод - если используете TUN-режим, то попробовать обычный прокси-режим, и наоборот.
Панели
Если подключен телеграм бот, то можно сделать бэкап конфига и бд, открываем .db файл блокнотом и ищем возможные части комбинаций пароля или логина.
A: 1) Зайти в папку cd x-ui; 2) Потом остановить контейнер: 'docker-compose down' 3) Обновить, 'docker-compose pull xui'; 4) И запустить обратно docker-compose up -d
Готово. При этом тут в докер файле настройки и так хранятся в отдельном volume, поэтому ничего не сотрется.
FAQ по Shadowsocks/XRay/XTLS/Reality/Nekobox/etc. для обхода блокировок
Эта статья - сборник разных вопросов и ответов на них, которые звучали в комментариях к моим предыдущим статьям ( Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria, Cloak и...
habr.com