2.#FREEWWW
Если разобрались с протоколами , дальше можем перейти к транспортам. Они могут работать, разным образом:
- Самый простой вариант - обычный TCP-транспорт. VMess+TCP в данном случае очень похож на Shadowsocks, а VLESS+TCP не имеет смысла (из-за отсутствия шифрования).
- Более интересный вариант - TLS-транспорт, когда устанавливается обычное TLS-подключение (как и в случае с любыми HTTPS-сайтами), а уже внутри этого зашифрованного соединения работает протокол. V2Ray и XRay умеют также работать поверх mKCP (о нем будет в следущих главах),
- QUIC (aka HTTP/3, правда в России его массово блокируют и смысла в нем мало),
- gRPC,
- Через Websockets.
Вариант с Websockets очень ценен тем, что:
- Позволяет легко поставить V2Ray/XRay не перед, а за Nginx/Caddy/любымдругим веб-сервером;
- Позволяет пролезать через строгие корпоративные фаерволы;
- Добавляет дополнительный уровень защиты (не зная URI невозможно достучаться до прокси-сервера);
- И самое интересное - позволяет работать через CDN (upd.: gRPC тоже позволяет).
На последнем пункте остановимся чуть подробнее. Некоторые CDN, в том числе и имеющие бесплатные тарифы, такие как Cloudflare и GCore, разрешают проксирование веб-сокетов даже на бесплатных тарифах. Таким образом, это может быть хорошим подспорьем - если по какой-то причине IP-адрес вашего сервера попал в бан, вы все равно можете подключиться к нему через CDN, а полный бан всей CDN гораздо менее вероятен, чем какого-то одного VPS. А еще Cloudflare (возможно и GCore тоже, не уточнял) умеет проксировать IPv4 запросы на IPv6 адрес, то есть свой прокси-сервер вы можете поднять даже на копеечном (можно найти варианты за 60 центов в месяц!) IPv6-only или NAT VPS без IPv4 адреса, и наплодить таких серверов чуть ли не десяток в разных локациях :)
Недостатком транспорта через веб-сокеты является более долгий хендшейк (установление каждого соединения) чем напрямую через TLS. Но и здесь есть решение.
Сервера XRay и Sing-Box (возможно и V2Ray тоже, не проверял) позволяют задавать также механизм fallaback’ов для разных протоколов. Например, при подключении пользователя первым делом сервер пытается обработать входящее подключение как VLESS-over-TCP. Если хендшейк оказался успешным, пользователь опознан - работаем, если нет - передаем следущему обработчику. Следущий обработчик, может, например, попытаться воспринять это новое подключение как VMess-over-Websocket. Если сработало - отлично, если нет - то передаем подключение следущему inbound’у. А тот, в свою очередь, не разбираясь, перенаправляет подключение на локальный веб-сервер с котиками. Таким образом у нас есть возможность одновременно принимать подключения и через VLESS-TCP, и через VLESS-Websockets или VMess-Websockets на одном порту, а если не сработал ни один из вариантов, прикидываться безобидным веб-сайтом. Еще одна фича V2Ray и XRay - мультиплексирование соединений (mux или mux.cool). В этом случае на каждое новое подключение к какому-либо сайту не будет устанавливаться новое подключение к прокси, а будут переиспользованы существующие. Что в теории может ускорить хендшейк и привлекать меньше внимания со стороны цензоров (меньше параллельных подключений к одному хосту), с другой стороны снижает скорость передачи данных из-за оверхеда на дополнительные заголовки пакетов.
XUDP и Packet - расширения VLESS для более эффективной передчи UDP-пакетов и реализации Full Cone NAT. Packet - версия подревнее, XUDP по-новее. Без их использования многие NAT-тесты будут жаловаться на кривой NAT ("endpoint address not changed), а с XUDP вы получаете нормальный честный Full Cone. Это может быть полезно для онлайн-игр, месседжеров и разного софта с передачей аудио и видео. XUDP и Packet нельзя использовать одновременно с MUX из прошлого параграфа из-за особенностей реализации (авторы старались впихать все в рамки существующего протокола и сохранить обратную совместимость, поэтому были вынуждены переиспользовать некоторые механизмы). А теперь про самые интересные фичи:
uTLS предназначена для обмана механизма детектирования на основе TLS fingerprint, о котором я рассказывал в прошлой статье. Почитать про TLS fingerprint можно на посвященном ему сайте. В Китае и Иране цензоры активно используют этот механизм для детектирования прокси-клиентов - если мы обращаемся к какому-нибудь прокси, замаскированному под HTTPS-сайт, но при этом TLS fingerprint клиента отличается от популярных браузеров (особенно если клиент написан на Go, у которого очень специфичный фингерпринт), то соединение блокируется. uTLS - это специально пропатченный вариант стандартной TLS-библиотеки Go, позволяющий маскироваться под другие приложения. Некоторые клиенты дают выбор из нескольких вариантов (например chrome, firefox, safari), некоторые позволяют выбирать желаемый fingerprint вплоть до версии конкретного браузера.
В нынешних реалиях uTLS является очень крутой и почти что жизненно необходимой штукой (РКН пока что по фингепринтам не блочит, но как показывает опыт других стран, может начать в любой момент), поэтому рекомендуется его использовать во всех случаях, если он поддерживается клиентом (а если не поддерживается - лучше выбрать клиент, который поддерживает).
XTLS, фирменная фишка XRay
Сегодня почти что все веб-сайты работают не через голый HTTP, а через HTTPS (TLS). Используя прокси с TLS мы, по сути дела, еще раз шифруем уже зашифрованные данные. Во-первых это неэффективно, а во-вторых, что гораздо хуже - китайские цензоры научились определять TLS-inside-TLS (возможно с помощью нейросетей). Авторы XRay посмотрели на это, и решили: зачем шифровать то, что уже зашифровано? И придумали XTLS.
Суть проста: прокси-сервер подслушивает передаваемый трафик, и если видит, что если между клиентом (например, браузером) и удаленным хостом (например веб-сервером) устанавливается TLS-соединение, то дожидается окончания хендшейка, и после чего перестает шифровать трафик, начиная передавать пакеты данных “как есть”. В итоге существенно снижается нагрузка на прокси-сервер и клиент, и что важнее - со стороны трафик выглядит гораздо менее подозрительно (у нас подключение по TLS, поэтому до сервера бегают простые TLS-пакеты без аномалий, никакого двойного шифрования).
XTLS-Reality
Это самое новое изобретение от авторов XRay. Он уже поддерживается в master-ветке xray и даже в некоторых клиентах, но про него все еще мало что известно. В отличие от всех остальных вариантов, определение “свой/чужой” здесь происходит еще на этапе TLS-хендшейка в момент чтения ClientHello. Если клиент опознан как “свой”, сервер работает как прокси, а если нет - вжух! - и TLS подключение передается на какой-нибудь другой абсолютно реальный хост с TLS (например, google.com или gosuslugi.ru), и таким образом клиент (или цензор, желающий методом active probing проверить, а что же прячется на том конце) получит настоящий TLS-сертификат от google.com или gosuslugi.ru и настоящие данные с этого сервера. Полное соответствие. Определение "свой-чужой" происходит по значения некоторых полей пакетов TLS-хендшейшка, которые формально должны быть рандомные, а по факту генерируются специальным образом, но не зная исходного "секрета", который использовался при их генерации, невозможно определить, действительно ли это рандом или нет - соответственно для прокси этот механизм позволяет достоверно определить подлинность клиента, но вместе с тем не вызывать подозрения у цензоров и быть устойчивым к replay-атакам. Вероятно за этим будущее :) Хозяйке на заметку: в отличие от предыдущих версий, при настройке клиентов для xtls-rprx-vision нужно выбирать тип транспорта не “XTLS”, а просто “TLS”. Нелогично, видимо связано с особенностями реализации, но такова жизнь.
«Bleeding-edge обход блокировок: настраиваем сервер и клиент XRay с XTLS-Reality быстро и просто».
Разработчики XRay подготовили скрипт, который автоматически скачивает XRay под используемую систему и создает systemd-юнит: https://github.com/XTLS/Xray-install
Устанавливается одной длинной командой:
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ installЕдинственное различие от описанного в статье при конфигурации будет в том, что конфиги XRay будут лежать не в /opt/xray, а в /usr/local/etc/xray/.
Вариант для самых ленивых (Websockets-only):
apt install docker.io docker-composeПререходим в нужный каталог и создаем доп. каталог:
mkdir /etc/xray/Создаем конфигурационные файлы:
nano /etc/xray/config.json:
{
"log": {
"loglevel": "info"
},
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "block"
}
]
},
"inbounds": [
{
"listen": "0.0.0.0",
"port": 5000,
"tag": "vless_ws",
"protocol": "vless",
"settings": {
"clients": [
{
"id": "7957c33c-d9ca-11ed-afa1-0242ac120002",
"email": "test@test.com"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "ws",
"security": "none"
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}
nano /etc/xray/Caddyfile
example.com {
handle_path /myverysecretpath {
reverse_proxy http://xray:5000
}
reverse_proxy lib.ru:80 {
}
}
или, если не нужна переадресация, а хватит просто 401 Unauthrized:
example.com {
handle_path /myverysecretpath {
reverse_proxy http://xray:5000
}
basicauth / {
bob JDJhJDE0JElab2ZPM25zdU40bE5SSURlTHd3OHVBeVJvYTlMN3dMOEFMdFVCRzNYS1l5ODl6TlVyQllH
}
}
nano docker-compose.yml:
version: '2'
volumes:
caddy_data:
caddy_config:
services:
xray:
image: teddysun/xray
volumes:
- /etc/xray:/etc/xray
ports:
- 23:23
caddy:
image: caddy
volumes:
- caddy_data:/data
- caddy_config:/config
- /etc/xray/Caddyfile:/etc/caddy/Caddyfile
depends_on:
- xray
links:
- xray:xray
ports:
- 443:443
- 80:80
$ docker-compose up -dТут в качестве веб-сервера используется Caddy, он же сам запрашивает и обновляет TLS-сертификаты (certbot не нужен). IPv6 не будет, но все остальное в принципе работает - опять же, только WS, и никакого XTLS. Lazydocker вам в помощь.
Источник: