Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Спасибо за классную статью с качественным разъясняловом для новичков!
Есть несколько вопросов касательно VLESS:
VLESS + xHTTP в РФ, по сути, нереализуем за адекватную сумму денег, как мне кажется. Вся прелесть xHTTP в работе через CDN, когда клиент (и цензор) не видят конечный сервер с ядром XRay. В России, в СНГ, да и в мире никакой толковой замены Cloudflare нет, только платные CDN с KYC. Cloudflare тупо не подходит при игре в долгую - завтра цензор встанет не с той ноги, и CF даже по API отвечать не будет. Prove me wrong, как говорится;
По сути, "народные SNI" и в принципе маскировка под что-то не своё - двумя шагами в бане для российских реалий. Есть бесплатные (суб)домены, есть копеечные без KYC, сертификаты бесплатны (LE), DNS-хостинги тоже халявные и даже халяльные, а их API при получении сертов через DNS-01 challenge пока ещё не в бане у РКН, веб-сервер поднимается одним docker-compose и может быть вообще без конфига (динамически генерируемый) - поэтому я считаю самовороство единственным надёжным способом налюбить фильтрацию;
Хотелось бы, чтобы в статье было больше теории по "белым спискам": знаю, что они делятся технически на "CIDR" и "не-CIDR", и вот вторые более-менее обходят неким образом кое-какие товарищи. Я смутно себе представляю, что это такое, но это, видимо, фильтрации на разных уровнях OSI;
"Роутить домашний регион (внутренний периметр страны) в direct на клиенте во многих случаях это довольно полезно" - но не всегда возможно. Да, многие панели имеют разные конфиги для указания маршрутов клиентам, но это зоопарк с чехардой и голландским штурвалом (где ты как разраб "первый в паровозике"), который клиентские приложения породили своими реализациями кто во что горазд. Но, надеюсь, с предложением от RPRX передавать клиентам параметры подключения когда-нибудь будет возможно единым стандартным путём...
Вся прелесть xHTTP в том что он может и как stream-one работать. в случае сэлфстила это апгрейд по сравнению с reality все равно т.к. у вас просто tls на нгинксе, а за /path vpn.
и да и нет. вы не поверите что порой работает у людей. фильтрация идет как я понял по сетям + сколько трафика. у людей порой в европу с sni типа yandex.ru работает на каком-нить 2000 порту. Но в целом я сам сразу же был на сэлфстиле потому как простое включение валидации серта (условно простое) ломает впн + меня так то выгрузить можно банально из логов.
Правильный белый список это как раз когда cidr+не cidr. т.е. не просто "можно на yandex.ru", а "можно на yandex.ru + acl_yandex._networks". такой белый список вы не обойдете прикидываясь яндексом и соответственно все что люди обходят это кривое применение таких белых списков или тот кто хочет в бс не может нормально выдавать списки своих сетей почему-то. в просто диапазоне нет никакой проблемы. гугл вон вроде даже в json выдает свои сети, наверняка и vk.com с яндексом тоже так смогут если их попросить. Ну и банально можно вбить просто ASN компании. у жирных сервисов обычно все выдается из своего диапазона, и даже если нет прям информации о том где именно какой сабдомен, то то что сервис хотя бы в сети ВК, например, проверить можно вон так https://bgp.he.net/AS47541#_prefixes
Я вот как раз про это и писал про модели OSI, что например для фильтрации по SNI вам не надо быть на l7, хотя это по сути l7 протокол (что там в сертификате). так же и приложения. фильтр сканит первые 5 пакетов и дальше вы себе висите на l4.
Одно дело сканить "у каждого соединения первые 5 пакетов" и другое дело "сканить миллиарды пакетов у каждого же соединения". И фильтрация по l7 параметрам возможна все равно даже если не включено сканить прям все. домены по маске, фингерпринты клиентов\серверов, геолокация (страна источника\назначения) это все может быть прописано просто в правиле. не глядя в правила ТСПУ я вам не расскажу как они работают, но вот как я описал работают довольно "простые" вещи типа Cisco FTD. А это даже не провайдерский. И довольно многие моменты становятся чуть более важны, чем они кажутся. Например Xray на Go. И чем чаще ядро обновляется, тем чаще у вас меняется фингерпринт вашего веб-сервера (если иксрей снаружи слушает или за tcp прокси) и фингерпринт клиента (тот самый хром из настроек).Не знаю. Я сделал именно "РФ прямо" довольно быстро.
Принцип "вот это прямо, остальное в прокси". Иксрей роутит по доменам (прямо domain:ru, domain:рф и т.п. плюс по ip из geoip.dat.
https://github.com/korn3r/marzban-things/tree/main/ru-node/sub_templates
вот я там нагородил. но там с правилами и для днса тоже + 3 разных типа шаблонов. но в целом "ру прямо" это довольно несложный набор правил именно роутинга.
Спасибо. Удивлен, что кому-то понравилось, я запостил в надежде что как черновик сохранится, когда на линукс переезжал. Форматирование на двоечку, да и не все внятно получилось.
Даже заскриншотил, спасибо, необходимая информация для текущего времени..
подскажите пожалуйста, спецы по XRAY / vless, может ли он маршрутизироваться ? Недавно пытался решить простую с виду задачу , сделать каскад . Клиент vless c определенным ID (взят емэйл) коннектится к VPS с поднятым сервером , в зависимости от ID сервер роутит коннект с помощью ikev2/ipsec к другому серверу , задача получить видимость IP сети другого сервера у клиента . Механика вся проходит на ура , для этого в XRAY все инструменты есть , но на уровне маршрутизации - затык.
XRay умеет TCP и UDP. Все что сверху не умеет. Если вы хотите делать впн поверх xray это можно, если вы хотите чтобы прямо в иксрее можно было правилом роутить, то это вам проще всего (имхо) сделать на сервере коннект до ipsec сервера на сервере иксрей, и на сервере иксрей правилами роутить трафик в туннель (в outbound freedom с прописанным в sendthrough ip тоннеля.
Альтернативно можно попробовать через dokodemo-door, но я не уверен что с IPsec сработает. Коннект на локальный порт, а локальный порт через dokodemo прокидывается на сервер и оттуда идет прямо.
спасиб, на сервере XRay так и сделано по коннекту клиента с определенным ид поднимается туннель до другого ipsec сервера и тут все ок , правила перенаправления трафика то ж работают , вопрос в том что ipsec тунель получает от сервера адрес , скажем 192.168.1.98 , но клиенту vless его никак не передать. Т.е. пришедший vless не может стать 192.168.1.98.
dokodemo-door, не видел , гляну , протокол то я любой почти могу поднять .
может. вы делаете отдельный outbound с тегом direct-ipsec1 (например) и типом freedom, прописываете ему sendthrough 192.168.1.98 и нужный трафик пускать через данный аутбаунд.
бонус влесс тут еще в том что вам не нужен включенный forwarding на линуксе. т.е. это приложение (прокси), то исходящий трафик ваш в любом случае будет иметь srcip сервера. и ничто не мешает указать инбаунду src ip туннеля.
обратите внимание что дефолтный роутинг (если вообще нет правил, например) идет в самый первый аутбаунд. так что вам нужно ставить "туннельный" аутбаунд не первым.
Не раскрыта тема VLESS Reverse Proxy...
да, надо было и про это написать, виноват.
дабы несколько загладить вину, оставлю тут схему работы, которую можно организовать через исрей.
Client A -> Vless сервер -> Client B
Клиент B находится внутри закрытой сети без белого IP адреса. На нем настроен клиент xray таким образом чтобы быть выходом для реверс прокси на сервере https://domain1.com. При этом клиент B сам инициирует подключение к https://domain1.com (клиент vless)
Таким образом клиент A из интернета подключаясь к тому же самому https://domain1.com может иметь доступ (в зависимости от настроек) к сетевым портам на устройстве Client B. К которому при этом нет ни то что входящих подключений, но даже ната (дната) как такового. И все что клиент B при этом делает это подключается на https://domain1.com браузером хром (или какой фингерпринт поставите).
Т.е. это проброс портов через исходящее соединение.
В целом довольно специализированно нужное. Военным такое наверно могло бы пригодиться, а любителям инстаграмчик поглядеть пока запрещают такой функционал не особо полезен.
https://xtls.github.io/ru/config/reverse.html
И в целом рекомендую всем https://xtls.github.io/ru/document/ и прочие разделы официальной доки.
Она довольно подробная.
Я вам про VLESS reverse proxy (https://github.com/XTLS/Xray-core/pull/5101), а вы мне про reverse proxy. Обычный реверс давно использую, о нем вопросов нет.
Мне вот еще вопрос интересно. Допустим часть ресурсов надо директ, часть через xray/sing-box а часть - через xray/singbox а затем - через socks5/https proxy обычные. задача вообще решается без настройки чего то вроде Proxifier на клиенте чтобы использовать прокси?
такое решается обычно tun-интерфейсом. tun2socks или tun2proxy. singbox в стоке умеет тун поднимать. клиентские приложения все тоже умеют.
В таком варианте у вас все кроме RFC Private и 224.0.0.0/4 роутятся в тун, а остальное идет в прокси и дальше на этапе маршрутизации (еще на клиенте) ядро может решить по правилам что вот такой трафик все равно прямо. Клиенты на винде делает это сами, просто надо включить режим VPN (или TUN, могут по-разному называть в клиентах)
Делать по-другому не выйдет - у вас таблица маршрутизации будет раздута настолько что клиентскому месту может быть нехорошо банально от размера таблицы маршрутизации. Плюс в таблицу маршрутизации вы не впишете правило вида "*.ru в директ", придется айпи адреса забивать (сетями, но сетей тоже море)
А мне иногда хочется объединять эти xray-прокси в цепочки (типа как в tor). Интересно, есть ли готовые решения для этого? (наверное можно запустить два разных клиента, один поставить в TUN режим, другой в обычный прокси, но это как-то костыльно)
да, можно. у вас аутбаундом может быть инбаунд другого сервера. у вас клиент так работает - инбаунд ядра на клиенте -> маршрутизация -> нужный аутбаунд. на сервере (даже у панели) в конфиге иксрей может быть прописан вышестоящий сервер для определенного типа трафика. просто аутбаунд выбираете какй нужно. вместо freedom у вас vless (или другой поддерживаемый) аутбаунд на другой сервер.
Freedom – директ
я возможно не так понял, но по-моему тут нужно поправить:
Freedom - прокси, а не директ.
Директ, он же bypass - это наоборот "не пускать через сервер, а пускать напрямую"
ну либо мне такие реализации попадались)
вы не на том уровне его рассматриваете.
с точки зрения самого ядра freedom это тип аутбаунда, при котором ядро посылает трафик прямо через устройство на котором оно запущено. Вы можете аутбаунду типа фридом задать кучу параметров, но это все равно "прямо". Оно работает по-разному в зависимости от того где это "прямо" прописано и какие параметры (например можно задать интерфейс и адрес, через который идти)
Любой инстанс иксрей работает по принципу "Инбаунд->маршрутизация->аутбаунд".
Соответственно фридом на клиенте это директ на клиенте. Идти прямо с клиента. Логически оно все равно прошло через прокси (завернуто каким-то образом в инбаунд ядра), но при этом выходит из ядра все равно прямо, а не через инбаунд где прописан ваш vless на vps.
Это нужно и чтобы трафика до сервера впс было меньше, и чтобы локальные ресурсы (банк клиенты и даже корпоративная почта, если прописаны правильно правила) шли прямо с клиента и работали так же как без впн. И самое главное - для скрытности. Как я писал ранее - если у вас трафик только до 443 на одном единственном сервере, то очевидно что у вас включен впн (с точки зрения оператора).
Сколько сил, времени, творческой энергии образованных и высоко квалифицированных людей тратится не на то, чтобы делать мир лучше и производить что-то действительно новое и полезное, а лишь для того, чтобы исправить то, что один полоумный м...к товарищ гадит и гадит.
исправить то, что один
полоумный м...ктоварищ гадит и гадит
Один? Смеётесь что ли? Сейчас практически все государства хотят всё контролировать, что-то запретить, сделать сквозное шифрование вне закона (Chat Control). А не только Китай и Россия. Авторитаризм в интернете - это общемировая тенденция, и давление будет продолжаться и усиливаться.
Я, наверное, не соглашусь с определённой частью.
Например, последние 10 лет сетовал, что при наличии технологий у нас всё ещё существуют живые очереди как явление. Особенно в инфекционных отделениях. Казалось бы, возьмите да внедрите. Но лень-матушка и отговорка «ну посидишь, чё, все так делают, никто ещё не умер от этого». А потом пришел ковид и ценой тысяч смертей и неоценимого горя до людей дошло, что нужно бы в оффлайн перенести то, что и так давно просилось.
Также я сетовал, что почти все шлют документы/шаблоны и требуют документы в проприетарном формате. Скажем, это не нормально, что единственный публичный шаблон конференции/издательства/мвд/… в формате, правильная работа с которым требует договора с конкретным частным лицом (скажем, MS), который не связан ни со мной, ни с конференцией/… Мне говорили «ну что ты выделывашься, делай как все». А потом наступили санкции и те же(!) люди начали вопить о желании перейти на открытые форматы. СПАСИБО, наконец-то. Гром не грянет — мужик не перекрестится.
А вот перед нами проблема информационной безопасности. Нужна приватность, потому что, по слову поэта, «я не люблю открытого цинизма, в восторженность не верю, и ещё, когда чужой мои читает письма, заглядывая мне через плечо». В другой жизни я бы посвятил себя криптографии и сетевым технологиям, задача-то важная. И хорошо бы её решить в любом случае, безотносительно политической и экономической ситуации.
А Вы говорите о тех, кто занят решением этой насущной (безотносительно тех, кто конкретно сейчас гадит) проблемы, так, будто они тратят силы «не на то, чтобы делать мир лучше и производить что-то действительно новое и полезное». Может быть, затем и нужны «полоумные м…ки», чтобы было сделано то, что должно было быть сделано давно и заранее? Потому что иначе с таким-то отношением оно будет сделано не скоро.
Не то, чтобы между очередями и ковидом была бы какая-то прямая причинно-следственная связь, но принцип «делай хорошо, а плохо само получится» не следует игнорировать.
Спасибо большое. Реально полезно. Хотел разобраться сам, времени не было))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в Xray