Pull to refresh

Comments 208

А где тег "реклама"? Раз уж рекламируете аезу - указывайте это.

Бездарная настройка vless, которая на 100% уязвима для active probing.

А) Никакие яху, никакие гуглы НИКОГДА не будут хостится на aeza.

Б) Сервер с открытым случайным портом на котором висит веб-сервер. Вообще не подозрительно. Зачем использовать ssh порт-форвардинг

В) Ссш по ключам? Не, не слышали. С первого дня стать частью ботнета - любовь

Г) Стать прокси до CDN яху - тоже любовь. Любой человек может использовать ваш сервер как прокси

Д) Настройка фаерволла? Зачем она нужна, правда?

Е) Любой человек в теме, понимает что reality у такого хостера как аеза - смерть. Вам что-нибудь говорит steal-from-yourself?

Суть Reality в маскировке под какой-либо популярный сайт, поэтому когда вы решаете это делать, вам нужно добиться того, чтобы ваш IP (IP вашего VPS) вел себя полностью идентично настоящему серверу, которым вы прикидываетесь. Если тот "настоящий" сервер слушает на 80-м порту (plain HTTP), то вам тоже нужно настроить nginx или правило фаервола, чтобы переадресовывать HTTP-запросы на оригинальный сервер. Если "настоящий" сервер не слушает SSH-подключения на стандартном 22-м порту, то ваш тоже не должен.— Если ваш хостер предоставляет reverse-DNS записи для IP-адреса, убедитесь, что там не осталось значение по умолчанию (обычно с доменом хостера), а лучше задайте такой reverse-DNS, какой виден у IP-адреса ресурса, под который вы маскируетесь.

ОЙ, где-то я это уже видел. Ой, и тут.

Ссш по ключам на сервак за 200р, на котором крутится только морда, настраиваемая за 5 минут. Юморной вы дядька.

Отключите доступ по рут и на этом достаточно. Ну фейл2бан можно еще вкорячить, чтобы иногда глазеть в терминале на тщетность попыток китайских ботов.

Тут дело вот в чем, в нормальном состоянии у тебя на ключи переводятся вообще все соединения, это просто проще и удобнее, плюс хранишь ты ключи в определенном защищенном месте.
Но по таким гуидам обычно люди настраивают свою первую в жизни виртуалку и они вообще может быть даже не знают, что существует такой способ аутентификации по ssh, неплохо было бы чтобы такие мануалы приучали сразу к хорошему.
Но таки учитывая мутный хостинг плюс кривую настройку влесса, то этот материал подойдет только в качестве тренировки за 200р совсем юным админам, все равно сервак не будет дальше чем месяц проплачиваться, потому что такой прокси долго не проживет :)

Все говорят что лучше сделать но никто не говорит как... Мануалы "как правильно" в студию!

От лица "совсем юных админов" - поддерживаю. Дайте, пожалуйста, ссылку, как сделать лучше.

Этот мануал, конечно, рекламный, но он работает.

Я не должна давать таких советов, всё-таки за это могут оштрафовать. Но если вы живёте не в России, или ваш телефон из-за ошибки маршрутизации 😏 определяется как иностранный, вы можете поискать прямо на этом сайте статьи с тегом VLESS, там всё очень хорошо расписано как настраивать, осталось выбрать иностранный сервер для впс.

Можно ещё прокрутить вниз, вдруг какой-то добрый человек выложил прямые ссылки на эти статьи. Но я вам ничего не говорила, мой аккаунт взломали и вообще у меня справка от врача.

Дай бог вам и вашему врачу всего самого лучшего

Всем им! Ну хоть онко пока отложили на потом.

+1, всë что знаю - это рандомные мануалы и гайды в инете, где поначалу 80-90% терминов вообще не понимал, ставить сначала пробовал вообще вручную и без всякой фигни по типу 3x и подобного

Однако некоторые вещи всë ещë непонятны, адекватно собрать воедино информацию сложновато. Так что какую-нибудь грамотную литературу с удовольствием бы приветствовал

BTW, ключи также лучше всего хранить на носителях с которых их нельзя извлечь

Помимо аргументов выше, хотелось бы дополнить что вход по ssh на aeza - это нужно. Их подсети регулярно сканят китайцы ради таких прокси, а пароль выдаваемый родным биллингом очень короткий. Чтобы китайцы/иранцы не превратили сервер в часть ботнета/прокси для себя - следует защищать сервер "по-взрослому"

Хорошо, именно чтобы "сделать как положено", в качестве хорошего тона и науки на будущее - можно делать по ключам.

Я сейчас вспомнил про одну свою впску, в которой из безопасности сделано ровно два действия - отключен вход по логину root, заходим под другим юзером и приличным паролем, и поставлен fail2ban со стандартными настройками.

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

Для таких машинок делаю 2 вещи.

  1. Перенести SSH на другой порт. Это не с целью спрятать от чего-то, но это сразу отсекает три четверти всех ботов, чтобы не забивали сетевой интерфейс и логи.

  2. Поставить UFW, в нём включить limit на порт SSH. После этого, я считаю, fail2ban будет лишний.

Насколько я заметил, перенос сервиса на другой порт минут на пять-десять только замедляет его нахождение. Всё равно находят. И даже если это только четверть ботов, то всё равно их там много.

  1. Уже слабо помогает. Я проводил сравнения. Если раньше это сильно уменьшало количество попыток (примерно на порядок, с тысяч, до сотен), то теперь это только отсрочивает начало атак. Похоже, используют общие базы данных открытых портов и как только туда попадает информация об открытом порте с SSH, массово начинают приходить ботнеты.

  2. fail2ban и ufw limit тоже стали гораздо менее эффективны. Имея ботнет в сотни тысяч или миллионы хостов, могут себе позволить приходить с одного IP раз в десятки минут. При этом интенсивность подбора не снижается.

P.S. Какой ужасный редактор на Хабре. На мобильном сделал кашу и не дает исправить. Курсор постоянно попадает на список. Извините.

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

Неоднократно слышал, что ssh соединение на отличном от 22 порта тспу дропает

Проверено много раз - нет. Иногда начинаются массовые блокировки, но тогда дропают любые длительные TCP-соединенияю

Есть же порт кнокинг, можно "постучаться" например пингом определённой длинны, и никакого софта на клиенте не нужно будет. Закрыл ssh и открывай только на время логина.

Мне кажется проще запретить авторизацию по паролю и всё.

UFW, в нём включить limit

А если вы попадёте на период спама ботов, то и сами же зайти не сможете... ?

UFO landed and left these words here

Не нашёл на сайте aeza.net цен по 200 руб., зато нашёл нашёл по 5 евро за самый простой сервер. Плюс, гемор с установкой, настройкой, обновлением, поддержкой, мониторингом и так далее. Альтернатива - купить готовый vpn за те же или меньшие деньги и вообще забыть про весь гемор. От 100 руб.

  1. Это уже дороже 100 руб.

  2. Весь гемор по установке, настройке, безопасности и сопровождению своего vpn остаётся.

  3. Я за vpn-сервис, если свой сервер нужен только как хост для vpn.

Без иронии, честно. Очень много людей будут вам благодарны, если вы напишите подобную статью, но без перечисленных вами косяков.

Я сам впервые столкнувшись с покупкой и настройкой личного VPS для себя выбрал такую тактику (примерно):
- Завел пользователя с правами sudo и отключил root
- сменил порт ssh
- пробросил свои публичные ssh ключи на сервер и запретил вход по паролю
- поставил Fail2Ban
- настроил firewall по принципу - DROP все, кроме ssh, vpn, 53, http/https, и всяких вебинтерфейсов (и им разрешил работать на своих портах ТОЛЬКО из под vpn - прибил в tun адаптеру)
потом узнал, что эти вебморды можно через SSH у себя открывать, и понял, что в принципе можно OpenVPN до этих морд гасить, в целом)
Но если кто-то напишет статью, как оно правильно по науке делается, и человеческим языком объяснит про настроечки Vless + XTLS Reality - я был бы очень рад)

Я бы может и написал бы статью, но я сам нубас и не уверен, что делаю правильно(
Писать надо, когда уверен в том, что пишешь

Если вам не нужна защита от active probing, то как вариант можно добавить ещё один "слой" защиты, поступить следующим образом:
1. Регистрируетесь на каком-нибудь массовом ddns сервисе, у которого миллионы пользователей и вы затеряеетесь в их массе. И ставите себе их клиент (или сторонний) на хост и/или роутер. Допустим запись для вас будет Okeu.superddns.moc
2. На VPS в cron добавляете скрипт, который (например раз в 5 мин) резолвит Okeu.superddns.moc и добавляет в netfilter (используя iptables, firewalld или что-то иное, что вам привычно) временное правило для нужного протокола и порта где source==ваш зарезолвенный IP, а destination внешний интерфейс VPS. Я сделаю сразу маленький дисклеймер для тех, кто в очередной раз за сегодня попытается рассказать мне, что я дурак: попробуйте например в старой версии firewalld (которая будет ставиться в самоё лёгкое из того, что обычно бывает на впс, а именно Centos7) добавить правило в источнике которого не IP, а dns имя. И опять же да-да-да, вы свежую версию firewalld собирёте из сырцов. Можно, но тогда вы и без меня, сопливого, знаете, что делать. =)
3. Добавляете в крон скрипт (на самом деле команду), который с нужной вам периодичностью дёргает сервис вашего fw managment или как-то иначе очищает временные правила + тут же запускает скрипт из пункта 2. Про периодичность: если например у вас к VPS имеет доступ только только домашний роутер, и вы с телефона два раза в день к нему обращаетесь, то ваши три правила, создаваемые каждый день (пусть у проводного провайдера раз в день меняется Ip и два захода с телефона) как дробина слону. Можете хоть раз в неделю дёргать, хоть раз в месяц. Тут больше вопрос паранои: насколько вы боитесь, что кто-то, "получив" ваш IP у проводного провайдера или ddns (тьфу, сотового т.е.) провайдера, полезет на ваш сервер (спойлер: очевидно, что кроме примерно околонулевой вероятности такого исхода у вас ещё есть авторизация на уровне сервиса, торчащего в интернет).

Ну и об очевидных недостатках: при частоте запуска скрипта из п.2 раз в 5 минут, обновив свой IP в DDNS клиенте вы не получите доступ к серверу в течении в среднем 2.5 минут (очевидно, от 1 сек до 5 мин). При наличии большого числа "клиентов" будет много правил и нужно будет их чистить чаще. Вероятно, в момент сброса правил могут сбросится все активные соединения (зависит от того, что и как вы будете делать в скрипте): т.е. "клиент" вашего "сервиса" должен уметь переустанавливать соединение, если вам нужно, чтобы оно было постоянное, а не по запросу.

Тут больше вопрос паранои: насколько вы боитесь, что кто-то, "получив" ваш IP у проводного провайдера

на самом деле я крайне редко пользуюсь хреем, на роутер не впиливал, делал только для клиентов. Поднимаю - захожу на портал - выключаю. Для всего, где достаточно zapret'a пользуюсь им)
Поэтому не особо переживаю, трафика гоняется мало и редко

У меня немного по-другому.

На веб сервере стоит обработчик 404 который при запросе https://mydomain.xxx/mysecrettotppagerandomstringXXXXXX.html выдаёт обычную 404 страницу, но если XXXXXX совпадает с TOTP кодом, то дополнительно адрес запрашивающего добавляет на пару часов в белый список. После этого можно логиниться по ssh.

Если веб сервера нет, ту же функцию выполняет рандомный UDP пакет где среди мусора закодирован или зашифрован TOTP, на который сервер отвечает как на все пустые порты (port unreachable или молчит)

Да, можно так. Можно и port knocking классический организовать. Просто в моём случае инициатор сам сервер (в интернет для случайного IP адреса открыто ровно 0 портов). Но плата за это (в отличии от вашего варианта) потенциальные 5 мин ожидания.

Ну тихий порт от закрытого слабо отличается. Можно его динамический сделать на основе того же TOTP. На случай DoS.

К чему все эти извращения с кроном и iptables, если проще поднять другую виртуалку, если по какой-то причине она отвалиться ?

Вы про случай, когда её заблокируют? К сожалению, количество доступных хостеров (и возможностей перебора IP) не бесконечно. Часть заблочили сразу ASNами. У других ставишь прямо у хостера виртуальный десктоп, с правильными локалями, таймзонами, TTL, rtd и т.д.. Открытыми изнутри тремя портами для 2 приложений. Т.е. для внешнего наблюдателя по сути ты становишься "физическим" хостом, правда очевидно из IP стоящим в стойке хостера. Заходишь в гугль, а он тебе говорит "مرحباً صديقي!" или как вариант сразу на русском "Привет дорогой друг!" без предложения поставить 10 галочек с согласиями, как это бывает при первом входе с устрйтсва в еврозоне. Ты тыкаешь и говоришь, не-не-не, я же швед ты по IP не видишь? А гугль в ответ: "не, ну если швед, заполни форму по ссылке - мы подумаем". А всё потому, что Вася или Мохмад ходили с телефоном на андроид одновременно с подключенным VPNом и включеной геолокацией.
Ну или второй вариант: меня вчера заблочили на тспу, я снёс хост - а вам сегодня мой IP провайдер отдал. А вы сидите и думаете, а чего это у вас кроме SSH со скоростью в несколько килобит никакие коннекты на этот сервер не поднимаются?

На хабре есть уже достаточно статей на эту тему. Можно было бы написать свой, но никому не нужен правильный и подробный гайд с нуля. Тем кто хочет "чтобы данные от злоумышленников как-то защищались" хватит и косого-кривого реалити под те есурсы, что ещё работают. А тем кто хочет хорошо собрать - те могут читать информацию в интернетах.

а тем, кто по середине?
я вот сколько не глядел, если не брать жирных хостеров, то aeza, vdsina и иже с ними.... я если честно вообще не знаю, чем они выделяются на фоне других хостеров? (кроме того, что они виртуальные)
Каких-то внятных разборов хороший/плохой/злой хостер я тоже особо не видел) Слышал про уважаемые OVH и Digital Ocean - а все остальные названия для меня практически ноунеймы)
Открываю любой топ, рейтинг и так далее, понимаю что он рекламный. Аезу брал по рекомендации коллеги, т.к. они принимают оплату в деревянных.

На хабре есть уже достаточно статей на эту тему.

отчасти это и проблема, из того десятка статей, что я прочел, я сходу не помню, чтоб видел, как в них подробно разбирается метод обхода active probing и иже с ними, везде, где я видел - yahoo/google по дефолту из коробки, так сказать)

"уважаемый OVH" хостил серверы в историческом здании с деревянными перекрытиями.
по-моему достаточно для принятия решения.

ну а у аезы вообще своих нету.
Они доедают из под других виртуальных хостеров.
Например у VDSINA) а у кого покупают уже те - одному богу известно)

А что не так в плане хостинга VPNа? Если дешево - то и хорошо. А если сгорит через N лет к чертям - ну поставлю новый VPN сервер, потрачу 15 минут на это.

Ovh насколько большой , что лучше сразу сказать континент и страну где такое было. Имхо для какой нить Голландии норм. Гугл доказал уже что серваки на улице норм работают.

По хостерам - железо (и его надежность - читать сколько даунтауйм для вас критично), качество техподдержки, дружественность поддержки к новичкам, эффективность поддержки в сложных случаях особенно если эдакое что-то надо, наличие всяких допсервисов вроде лицензий на винду от хостера, дружественность по способам оплаты особенно в странных ситуациях(а из России их большинство будут странными сейчас кроме официально-ру хостеров), репутация в плане сохранения тарифов что обещали(VDSina тут совсем не в лучшую сторону отличилась насколько помню),как именно хостер на сообщения реагирует на сообщение - у вас тут аватара через торрент раздают/у вас тут exit node Tor/у вас тут спамеры-вот пример что от вас пришло/у вас тут хентай раздают/у вас сервер IP телефонии через который мэрию заминировали ану быстро отправили сканы паспортов и данные по оплате тех кто это сделал/вот запрос от суда - данные пожалуйста/вот запрос от суда/...

И так далее...

для кого то и наличие в РКНовском реестре - довод (а для кого то - отсутствие там - довод брать)

Нет единого критерия.

Иногда сервис с кривым вообщем то железом и ну не очень - поддержкой - выигрывает по другим параметрам (например тарифы, или им плевать на часть требований от всяких кто им не платит но чего то хочет)

Вы случайно не ставите перед собой цель - напугать аудиторию и оттолкнуть людей от самостоятельной настройки? Никакой катастрофы и смерти не случится если ещё один ip заблокируют или ещё один vps уведут в ботнет. Тем более что оба события могут случиться, а могут и не случится.

P.S. Все замечания справедливые, но поданы в очень уж пугающей форме.

Никакой катастрофы и смерти не случится если [...] vps уведут в ботнет.

Никто заранее не знает, какие преступления могут совершаться с использованием скомпрометированного VPS в рамках его участия в ботнете. В особо тяжёлом случае может произойти, как с Дмитрием Богатовым, я бы от этого не зарекался. Особенно учитывая, что Aeza входит в РКН'овский реестр хостинг-провайдеров, а значит, от сотрудничества с российскими спецслужбами не отвертится.

С одной стороны я понимаю вашу обеспокоенность, но с другой а какой длинны дефолтные пароли у Aeza? На мой взгляд трагический тон комментария не соответствует фактическому риску. Сначала ваш пароль должны подобрать, а затем ваш впс должны использовать таким образом чтобы вас начали искать органы. На мой взгляд более вероятно что вас подставят любым другим более доступным образом. Но вход по ключам, конечно, лучше поставить.

Ну и если паранойить до конца, то даже если вы полностью отключите ssh, отключите вообще всё что смотрит в интернет, то остаётся сам впн сервер, который тоже может быть подвержен взлому. Поэтому нужно и всё системное ПО регулярно обновлять, и впн клиент, и за уязвимостями следить.

Они утверждают, если vps зарегистрирован в британской юрисдикции, то запросы от росслужб будут игнориться.

А) Никакие яху, никакие гуглы НИКОГДА не будут хостится на aeza.

Е) Любой человек в теме, понимает что reality у такого хостера как аеза - смерть. Вам что-нибудь говорит steal-from-yourself?

Так достаточно сложно найти дешевый VPS у того же хостера, что хостит крупняк уровня яху или гугла.

Совершенно верно, поэтому логичнее прикрываться не гуглом или яху, а каким-нибудь небольшим сайтом, который хостится в сети того же хостера что и вы (для этого есть утилитка reality-scanner, но там надо аккуратно - не попасть на IP-адрес какого-нибудь другого хитреца с XTLS-Reality), либо вообще свой домен с фейковым сайтиком (упомянутый выше подход steal-from-yourself).

А тут другая проблема возникает по поводу трафика. Что это за сайт такой куда человек ходит 24/7 и с огромным количеством трафика и на аплоад и на даунлоад. Это даже, если роутинг настроить нормально, и пускать напрямую весь ру траф итд выглядит дико аномально.

Вопрос сродни тому, что человек делает так долго у себя в туалете. И если туда начнут совать камеры, чтобы он там не задумал недоброе под маскирующий шум воды, то надо задавать вопрос уже не "что он там так долго делает", а "как мы позволили им дотолкать окно Овертона до наших толчков"

Вопрос сродни тому, что есть смысл тогда заморачиваться и указывать какой-то сайт на этом же хостинге или все же просто указать гугл/яху. Что так палевно, что так палевно.

Задетектировать оба этих варианта можно автоматически.

Можно тогда конкретно заморочиться и повесить сайт с маскирующей игрушкой, которая будет генерировать большой поток (например отдавая видеопоток аля сервис с удалённой видяхой, как там их, типа google stadia). Тогда формально будет сложно определить, действительно вы там в игрушку шпилите или "запрещённый" ютуб через хитрый впн смотрите.

Много лет назад думали над этим, но пришли к пониманию, что условный тов. лейтенант не будет заходить и смотреть глазами, что там: заглушка owncloud или редирект на гугль. Что когда до этого дойдёт железка будет будет рубить по паттерну. Всё к тому и пришло в принципе, не до конца, но наверняка тспу докрутят, если будет на то воля.

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

Я не совсем про это: чтобы ваш сервер не использовали как прокси для доступа к тому на что у вас "редирект" будет стоять, наиболее правдоподобным (в случае, если бы что висит на IP смотрел глазами человек) было бы например логин скрин оунклауда или чего-то подобного. Тогда стороннему наблюдателю было бы очевидно и почему коннект целый день, и почему трафик гоняется. Но, очевидно, никто ничего не будет смотреть глазами.

Оригинальное Окно Овертона это совсем не то что вы думаете.

Правда? Ну так потрудитесь просветить публику, что это такое на самом деле

Во-первых, итак все известные прокси, туннели, VPN и остальные инструменты по факту пропускают весь траффик через себя до одного конечного IP-адреса.

Во-вторых, все эти штуки, делающие DPI и active probing - не какие-то сверх-разумные железки, которые могут интеллектуально анализировать, а что же там за сайт на той стороне, может ли юзер на нем проводить много времени и качать с него много трафика - они могут только проверить, есть ли там какой-нибудь валидный сайт и все.

В-третьих, это в любом случае лучше, чем если со стороны внешнего наблюдателя у вас будет какой-нибудь гугл, яху или еще что-то сверхпопулярное в автономной сети, которая никакого отношения к гуглу и яху не имеет, и вот это уже определить довольно просто.

Если есть желание упороться по теме - XRay умеет балансировку исходящих подключений по разным прокси, можно поднять несколько разных прокси-серверов и использовать их одновременно, часть запросов пойдет на один, часть на другой, часть на третий.

Если хочется еще дальше упарываться - можно проксироваться через CDN с использованием вебсокетов или SplitHttp (его там сейчас вроде в XHTTP переименовали). Некоторые CDN до сих пор поддерживают domain fronting в какой-то мере (на Хабре хорошая статья об этом была), так что можно прикрываться разными популярными сайтами и их реальными IP-адресами.

Не нужно бежать быстрее медведя, нужно бежать быстрее геолога.

РКНу нет дела до вас персонально или меня персонально (будем надеяться), они работают по площадям. Если каким-то относительно простым трюком можно вырубить дохрена VPNов - сделают. А вот подбирать крошки, внимательно исследовать каждый сайт - вряд ли до этого вообще дойдет. Если и дойдет - то уж после того, как все действующие сейчас VPN решения перестанут работать, т.к. эти фрукты слаще и висят ниже.

Г) Стать прокси до CDN яху - тоже любовь. Любой человек может использовать ваш сервер как прокси

Проверил, реально может( Подскажите, как этого избежать, не сломав при этом корректную защиту от active probing?

Не быть прокси до CDN, буквально) Китайцы умнички, они вместо айпи клаудфлеера, например, ставят вот айпи такого реалити сервера и пользуются

Маскируйтесь под сайт без CDN или делайте steal-from-yourself

Ясно, там надо было читать, поставив акцент на слово CDN, а не на слово прокси) В принципе да, правильно выбранный сайт это хорошее начало устойчивого конфига. Китайское применение этой багофичи тоже несколько доставляет.

Проверил, реально может( Подскажите, как этого избежать, не сломав при этом корректную защиту от active probing?

Никак. Такое поведение, позволяющее использовать сервер как открытый прокси до фейкового сайта, как раз и необходимо для защиты от active probing.

И в этом нет особой проблемы, проблема начнется, как уже сказали выше, если вы в качестве фейкового домена используете какой-то сайт, который хоститься на CDN, и тогда через вас можно будет бегать до всех сайтов на этой CDN.

Если совсем паника мучает, можно:

  1. поставить перед XRay какой-нибудь HAProxy и фильтровать по SNI, если он совпал - идем на XRay, если не совпал - дроп, то есть ограничимся только одним конкретным доменом. Это не совсем валидное поведение с точки зрения active probing, но скорее всего такой анализ никто делать не будет.

  2. на фаерволле шейпить скорость до фейкового сайта. тогда открываться он через вас будет, но ооооочень медленно, и желающих пользоваться вами как открытым прокси до него резко поубавится.

Спасибо за развернутый ответ. В принципе, у меня уже давно забита в ToDo задача сделать что-то типа первого пункта из вашего антипанического списка, хоть и с другими изначальными целями - средствами Nginx делать форвардинг нескольких разных сервисов на разный backend, некий прокси тоже присутствует в их числе. Надеюсь, руки дойдут уже в ближайшем будущем. Дропать там будет нечего, проще изначально подобрать сайт без CDN. Пошейпить трафик это довольно интересная идея, попробую посмотреть и в этом направлении при случае. Сегодня это кажется избыточным, но кто знает, что там случится завтра...

| ОЙ, где-то я это уже видел. Ой, и тут.

не говоря уже о том, что в базе знаний самого хостера есть аналогичная информация по настройке

Подскажите, пожалуйста, где можно почитать подробно про пункт "г". Не совсем понял, как это происходит в рамках данной статьи.

REALITY по умолчанию перенаправляет все нелегитимные запросы  на dest

И по другому нельзя, это связано с тем, что блокировка определённых SNI для перенаправления сама по себе является характерной особенностью, ведь  мы должны поступать и отвечать  1:1 как сайт под который мы маскируемся.

Теперь подробнее:

curl --connect-to ::www.speedtest.net: https://cloudflare.com

Здесь мы подключаемся к IP-адресу speedtest.net, но отправляет SNI cloudflare.com

В результате что? 

Мы открываем сайт cloudflare.com

REALITY с dest=www.speedtest.net ведёт себя так же - оно станет порт-форвардером для _любого_ сайта Cloudflare, и любое другое поведение само по себе будет являться характерной особенностью.

для использования прокси через cdn, нам нужна «точка входа», обычно, она является cloudflare.com, условно, но в данном случае, узнав для себя это, мы теперь можем использовать _любые_ адреса  которые используют dest за cdn и использовать эти адреса как свою точку входа

Угу, а для сайтов, которые Вы посещаете, еще и желательно чтобы IP выглядит как IP-адрес интернет-провайдера домашнего или мобильного интернета, а не адрес сервера в ДЦ, что тоже здесь не выполняется :(

Резидентские айпи найти за такие деньги - нереально

Все 3 года существования мы поддерживаем инициативных авторов, которые делятся своим опытом, данный пост не является исключением, и не нацелен на рекламу какой-либо платформы.

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

Любая инструкция не может быть универсальной и в нашем случае эта написана в качестве отправной точки для тех, кто ищет информацию и готов по необходимости развить или адаптировать решение под свои задачи. Мы считаем важным поддерживать развитие и распространение подобного контента для российской аудитории, чтобы это помогало другим участникам обмениваться опытом, расти и находить свои пути в любой интересующей их теме.

данный пост не является исключением, и не нацелен на рекламу

Звучит солидно после того как автор убрал реферальную ссылку из статьи. Если не реклама хостинга, так точно желание получить "бонусный баланс" самого автора. Для меня это равносильно рекламе. К тому же автор не привёл альтернативные хостинги..

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

А вы комментарий-то читали? Простите, но мой комментарий не имел ни одного намека, что SNI заблокируют. Да, это возможно, но я критиковал совсем другие аспекты этой статьи. Если вы видите упоминание блокировки SNI - процитируйте.

в нашем случае эта написана в качестве отправной точки для тех, кто ищет информацию и готов по необходимости развить или адаптировать решение под свои задачи. 

Т.е. все-таки статья ваша? Почему бы не опубликовать её с корпоративного блога? Отправные точки, обычно, содержат ссылки документацию и не занимаются плагиатом чужих статей. Тут поверхностный рерайт самой глупой статьи по 3xui.

Не оправдывайтесь аудиторией, ваш CEO регулярно бывает в профильном чате и, вероятно, мог спросить про грамотную настройку.

Суть Reality в маскировке под какой-либо популярный сайт, поэтому когда вы решаете это делать, вам нужно добиться того, чтобы ваш IP (IP вашего VPS) вел себя полностью идентично настоящему серверу, которым вы прикидываетесь.

Поясните, чем это отличается от такой же маскировки в Tor Browser ?

В данном случае маскируется сервер, чтобы цензоры не поняли, что на нем работает прокси.

Webtunnel мосты в Торе так же делают, а трафик маскируется под https

Да, делают.

Только у них там огромная дырень с TLS-фингерпринтом их webtunnel-клиента, каким место они вообще думают по этому вопросу - не понятно. Из-за этого, например, их WebTunnel бриджи почти с самого начала не работают в Иране. А еще у них нет защиты от детектирования TLS-in-TLS.

Реальность в итоге такова, что какие-то анонимные китайцы-энтузиасты с гитхаба в плане обхода блокировок уделывают по полной весь проект Tor, спонсируемымй большими грантами и основывающийся на академических исследованиях (которые в нынешних реалиях устаревают еще до их публикации, потому что цензоры уже научились бороться с тем, что в них наисследовано).

Благодарю, установил за 15 минут, не 10 конечно, но всё летает)

Я мало что понимаю в этих ваших сетевых технологиях и у меня глупый вопрос. Вот есть провайдер который видит, что 95% траффика идёт с одного сайта от конкретного абонента. Живой человек же не будет сидеть только на одном единственном сайте. Может ли он настроить свои фильтры так, что этому абоненту перекрывают канал связи? Или мой вопрос не корректен?

Может, особенно если гнать траффик до ру-сервисов, через этот самый прокси

В статье даже нет упоминания элементарных вещей, таких как синхронизация часовых поясов.

И про то, что ссылка реферальная тоже желательно упоминать. Ну хотя бы не было воплей "переходите в мой телеграм-канал" и на том спасибо.

А почему собственно в данном случае проблема с реферальностью ссылки? Гайда все же полезный (то что есть получше и в деталях - это другое, такие вот упрощенные гайды - тоже весьма полезны когда либо вообще ничего не понимаешь сначала либо когда надо рассказать кому то кто не понимает а понлоценно поддерживать нет

да, есть например серия статей

https://habr.com/ru/articles/727868/
https://habr.com/ru/articles/731608/
https://habr.com/ru/articles/735536/
https://habr.com/ru/articles/728696/
https://habr.com/ru/articles/770400/
https://habr.com/ru/articles/776256/
https://habr.com/ru/articles/761798/
https://habr.com/ru/articles/778134/
https://habr.com/ru/articles/799751/

где сильно подробнее...

Скрытая реферальная ссылка - зло.

может, продвинутые DPI умеют изучать паттерны поведения пользователя и выявлять аномалии относительно "среднего по больнице". к счастью, пока что это достаточно дорого для поголовного применения. к несчастью - это не очень надолго.

Можно не весь трафик гнать через VLESS-Reality. Это логичнее. Либо настроить роутинг отдельных IP, либо через BGP

Либо настроить роутинг отдельных IP

XRay и Sing-box из коробки умеют роутинг по GeoIP и спискам Geosite, и есть большие хорошие базы от сообщества для них.

Можно, но например на айфонах впн клиенты принципиально не могут разделять трафик. Типа не безопасно. Либо ты целиком сидишь через впн, либо не сидишь. На андроиде с этим проще, там практически все впн клиенты могут пускать через впн только отдельные приложения, такие клиенты не должны вызывать подозрений. Особенно если масаироваться пол какой-нибудь Microsoft

Часть трафика можно (и нужно) пускать мимо VLESS. Особенно внутрирегиональный. В таком случае уже далеко не 100% запросов будут к одному и тому же сайту. А ещё можно сделать себе несколько конфигураций на разные домены и менять их периодически.

Проблема детекта кроется в том, что придётся 100% абонентов подозревать, и трекать каждый их запрос, чтобы понять динамику. Это очень тяжёлая задача.

Часть трафика можно (и нужно) пускать мимо VLESS.

Можно даже немного генерировать фейкового траффика. Можно даже много. Пусть анализируют.

ПО на устройствах-клиентах настраивается таким образом, чтобы проксировать (пускать через VPS) только конкретный список доменов. Например ютуб, рутрекер и тд. Всё остальное, не указанное в списках, не проксируется и идет напрямую.

Это не гарантия того, что мы не попадем под какой-то фильтр ТСПУ, но здорово повышает шансы на выживаемость коннекта с VPS длительное время.

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

Учитывая блокировку ECH и желание РКН заблочить большинство крупных иностранных хостингов, скоро придётся наоборот, составлять списки того, что гонять напрямую.

Ну если дойдет до того, что и за такое будут блокировать - будет несложно написать автоматизированный рутуб-вк-мелйру-клиент, который просто будет качать тонны всякого видео оттуда (минуя VPN), просто чтобы имитировать настоящего пользователя.

Не лучше ли все же grpc и прочие websocket? По ощущением сильно быстрее получается.

Личный опыт: aeza стабильно, несколько раз в неделю, ложиться отдохнуть. Не надолго, но факт есть. Иногда совсем ложится, а иногда толи канал забивается то ли ещё что (скорость падает и пинг подскакивает). Это на обычном тарифе за 4.94

Промо тариф пробовал, на нём вообще нормально не завёлся конфиг (делал не по этой статье и не на гуях)

Всё так, у аезы проблемы с пингами, иногда скоростью, иногда с чем-то еще. Пользуюсь почти год, знаю о чем говорю. Местами ложится отдохнуть хорошо и полностью, вместе с собственным билингом и прочим. Из интересного, выдаваемые ими зарубежные IP бывают очень спорные по GEO, некоторые из них по определенным базам определяются как РФ, а по определенным как те, о которых они заявляют - зарубежные. И неважно какая это локация сервера, сталкивался не один раз уже. Не знаю как это работает на самом деле, но стоит это учитывать.

Я вам примерно то же самое могу рассказать про любого "долларового" (всмысле 1-2USD/мес) провайдера VPS, например про ruvds. Последние нечасто тотально недоступны (и обычно предупреждают о работах), но со скоростью там тоже всё очень грустно при том, что я совершенно не злоупотребляю - пользуюсь VPS сильно не каждый день и только для того, чтобы зайти на нужные web ресурсы (в том смысле, что без музыки и видео - только "текст"). Но тут за что заплатили, то и получил. Там где платится 5-10$ скорость вполне упирается в ширину канла локации, откуда я к хостингу обращаюсь, и/или загруженности внешних магистральных каналов.

У меня на роутере:

{
    "routing": {
        "rules": [
            {
                "inboundTag": [
                    "redirect",
                    "tproxy"
                ],
                "outboundTag": "block",
                "type": "field",
                "domain": [
                    "ext:geosite_v2fly.dat:adblock",
                    "ext:geosite_v2fly.dat:adblockplus",
                    "ext:geosite_v2fly.dat:adcolony-ads",
                    "ext:geosite_v2fly.dat:adguard",
                    "cdn.freekassa.com"
                ]
            },
            {
                "inboundTag": [
                    "redirect",
                    "tproxy"
                ],
                "outboundTag": "vless-reality",
                "type": "field",
                // "ip": [
                //     "173.194.0.0/16",
                //     "74.125.0.0/16"
                // ],
                "domain": [
                    "ext:geosite_v2fly.dat:facebook",
                    "ext:geosite_v2fly.dat:instagram",
                    "ext:geosite_v2fly.dat:tmdb",

                    "domain:habr.com",
                    "domain:gateway.facebook.com",
                    "domain:jetbrains.com",
                    "domain:ghcr.io",

                    "ext:geosite_v2fly.dat:youtube",
                    "full:ggpht.com",
                    "full:googlevideo.com",
                    "full:gstatic.com",
                    "full:youtu.be",
                    "full:youtube-nocookie.com",
                    "full:youtube.com",
                    "full:youtubekids.com",
                    "full:ytimg.com",
                    "jnn-pa.googleapis.com",
                    "wide-youtube.l.google.com",
                    "youtube-ui.l.google.com",
                    "youtubeembeddedplayer.googleapis.com",
                    "youtubei.googleapis.com",
                    "yt-video-upload.l.google.com",
                    "ytimg.l.google.com",

                    "play.google.com",

                    "ext:geosite_v2fly.dat:twitter",
                    "domain:abs-0.twimg.com",
                    "domain:abs.twimg.com",
                    "domain:video.twimg.com",
                    "domain:pbs.twimg.com",
                    "domain:x.com",
                    "domain:twitter.com",
                    "domain:api.x.com",
                    "full:x.com",
                    "full:t.co"
                ]
            },
            {
                "inboundTag": [
                    "redirect",
                    "tproxy"
                ],
                "outboundTag": "direct",
                "type": "field"
            }
        ]
    }
}

Добрый день. А подскажите, пожалуйста, как этот код применить на раутере? Какая ОС нужна?

А то я до сих пор на клиентах с помощью PAC распределяю по проксям, потому что не осилил на Keenetic маршрутизацию по доменам, а не айпи адресам.

Насколько я понимаю, я должна сначала получить оффер в Дойче Банк, релоцироваться и только потом отвечать на Ваш комментарий.

Кейворды для поисковиков: vless + keenetic

я должна сначала получить оффер в Дойче Банк, релоцироваться и только потом отвечать на Ваш комментарий.

Нескромный вопрос: почему?..

1) вы пишите про преимущества "Преимуществ XTLS-Reality два", но при этом в настройке клиента вы выбираете xtls-rprx-vision. Это как? И что вообще будет если FLOW выбрать none, если всё остальное настроится, неужели все эти настройки игнорируются если этот пункт не выбран?

2) интересные настройки о которых даже в мануале не написано что они делают как "Proxy Protocol" что дает? у вас выключена.

3) Route Only - в мануале написано что подменяет IP -> DOMAIN в выходной пакет. Но я читаю документацию TCP\IP и не вижу ниодного пункта где в пакете может быть domain. Как так?

4) Sniffer с опцией по умолчанию "ipv4_only" , очень странно работает, по логике при такой настройки домен при Routing не должен работать, а только работать по IP, но роутинг работает по домену.

Надеюсь знающие люди прояснят всю эту магию...

sing-box, xray - ужаснейшая документация с множеством тайн.

Вам нужно почитать статьи на хабре из цикла miracleptr

И что вообще будет если FLOW выбрать none

Тогда после попытки подключения вам ТСПУ даст бан, проходить с вашего IP на целевой будет только ping. Работать такая конструкция, конечно, не будет.

Я не про ваше РФ устройства или баны. Прочитал вашу ссылку, так и не получил ответа.

Я про смысл работы. FLOW:NONE. Это же не просто подключение к серверу, это идет подключение к VLESS через TCP с security: Reality.

Может это просто подсказка для старых клиентов которые не понимали какой там vless, других предположений у меня нету.

Я про смысл работы. FLOW:NONE. Это же не просто подключение к серверу, это идет подключение к VLESS через TCP с security: Reality.

Просто подключение к серверу с TLS:

Currently, there are the following flow control modes available in the outbound protocol:

  • No flow or empty string: Use regular TLS proxy.

  • xtls-rprx-vision: using the new XTLS mode includes inner handshake random padding supports uTLS client fingerprint simulation

  • xtls-rprx-vision-udp443: same as xtls-rprx-vision, but allows UDP traffic with a destination of port 443

Поэтому none обнаруживается потому, что не похоже на обычный HTTPS. Остальные варианты пытаются маскироваться под легитимный HTTPS.

xtls-rprx-vision нужен, чтобы заработала одна из главных фишек — удаление tls-in-tls, то есть когда шифрование при подключении к сайту накладывается на шифрование, создаваемое при подключении к проки-серверу. XTLS как раз убирает этот дополнительный слой. Это увеличивает скорость и снижает обнаруживаемость.

Раньше, судя по документации, существовало несколько версий XTLS. И во поле flow, видимо, можно было их указывать. Однако сейчас поддерживается только современная версия — xtls-rprx-vision.

Про Proxy Protocol в документации указано, что это штука для продвинутых пользователей. Никогда не видел, чтобы её кто-то трогал при настройке.

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

ы пишите про преимущества "Преимуществ XTLS-Reality два", но при этом в настройке клиента вы выбираете xtls-rprx-vision. Это как?

А что не так? Reality и Vision - это разные технологии, и они могут использоваться совместно (и более того, должны использоваться совместно).

И что вообще будет если FLOW выбрать none

Тогда у вас не будет работать XTLS-Vision, и повышается риск детектирования TLS-in-TLS.

"Proxy Protocol" что дает

Тогда сервер будет ожидать подключения на этот порт с proxy protocol (смотрите документацию HAProxy про него) то ли первой, то ли второй версии. Обычному пользователю это не надо, только если вы решили перед XRay поставить тот же HAProxy или что-то подобное.

Я не думаю, что в данном топике Вы получите адекватную обратную связь.
Давайте по порядку

Вообще, основная наша логика заключается в использовании TLS для маскировки прокси-трафика среди самого обычного интернет-трафика.
Для обычного TLS прокси-протокола, клиент прокси пользователя устанавливает настоящее TLS-соединение с прокси-сервером, и через этот зашифрованный туннель приложение (например, браузер) устанавливает еще одно TLS-соединение с целевым сервером (например, Google). В этот момент браузер и сервер Google обеспечивают end-to-end шифрование, и никто (включая наш прокси) не может расшифровать или подделать отправляемую информацию.

Вот краткая схема:

Браузер ---- Прокси-клиент ==== Прокси-сервер ---- Google

И тут мы понимаем, что когда прокси-данные проходят через цензора, они фактически шифруются дважды. Однако, в этом процессе, 99% трафика на самом деле не требует дополнительного шифрования. Поскольку данные, зашифрованные с помощью TLS 1.3 (а мы с вами помним, что REALITY = TLS 1.3), внешне выглядят абсолютно одинаково, цензор не может их различить.

Таким образом, логика идеального прокси должна быть следующей:

  1. Устанавливаем TLS-соединение.

  2. Внутри зашифрованного туннеля отслеживаем коммуникацию между браузером и сайтом, определяя, является ли текущее соединение TLS 1.3.

  3. Если нет, то используем обычный метод TLS-прокси, продолжая использовать зашифрованный туннель.

  4. Если да, то дожидаемся начала передачи зашифрованных данных обеими сторонами, а клиент прокси вставляет UUID в первый внутренний зашифрованный пакет, сигнализируя серверу прокси: мы готовы к "голому" соединению!

  5. Начиная со второго внутреннего зашифрованного пакета, мы больше не выполняем никаких операций с данными, а просто копируем их.

Поздравляю! Мы изобрели xtls-rprx-vision.

Мы можем заметить, что:

  1. Внешний TLS, инициированный прокси, является настоящим, поэтому цензор не может его взломать.

  2. "Голый" трафик на стороне прокси просто копируется без изменений. Если цензор попытается вмешаться, он получит стандартный ответ от браузера и сервера Google, который не будет отличаться от обычного доступа.

  3. Сигналом для "голого" соединения служит UUID, который является приватной информацией прокси, чтобы избежать уязвимостей, подобных тем, что были в Go, связанных с использованием кодовых характеристик.

Одним из важных недостатков обычного TLS-прокси является "шифрование в шифровании". Как обсуждалось выше, хотя внешний вид зашифрованных пакетов неотличим для цензора, неизбежным является увеличение заголовка каждого пакета с каждым уровнем шифрования. Это увеличение может быть незначительным, но для маленьких данных (например, пакетов ответов) оно может быть более заметным, и некоторые пакеты могут превышать ограничения MTU сетевого уровня. Самое важное - каждый пакет увеличивается на одинаковую длину, что создает определенные статистические характеристики.

Можно сказать, что когда передаются данные TLS 1.3, 99% наших пакетов имеют почти идеальные характеристики трафика, потому что это оригинальные данные, не обработанные прокси.

Наверное, у вас возник вопрос: почему мы говорим, что 99% пакетов являются оригинальными данными? Что представляют собой оставшиеся 1%? Нам нужно исследовать, что происходит в типичном прокси при встрече с трафиком TLS 1.3 в первых нескольких пакетах.

Наглядно, после установления зашифрованного канала:

  1. Первый пакет: Прокси-клиент -> Прокси-сервер: "Привет, цель этого прокси-сессии - Google, вот мой UUID."

  2. Второй пакет: Прокси-клиент -> Прокси-сервер: "Привет, получил твой запрос на прокси, начинай отправлять данные."

  3. Третий пакет: Браузер -> Прокси-клиент -> Прокси-сервер ->Google: "Привет, Google, я собираюсь начать с тобой зашифрованное общение, вот мои поддерживаемые методы шифрования..." (Этот пакет также называется TLS Client Hello).

  4. Четвертый пакет: Браузер <- Прокси-клиент <- Прокси-сервер <- Google: "Привет, пользователь, вот сертификат Google, мы будем использовать шифрование TLS_AES_128_GCM_SHA256, давай начнем зашифрованное общение!" (Этот пакет также называется TLS Server Hello).

  5. Пятый пакет: Браузер -> Прокси-клиент -> Прокси-сервер -> Google: "Понял, давай начнем зашифрованное общение!"

Как вы знаете, протоколы прокси разнообразны, но основа одна и та же: если пользователь использует любое TLS-соединение, необходимо выполнить вышеупомянутый процесс рукопожатия. Как упоминалось ранее, внешнее TLS-шифрование можно считать абсолютно безопасным, но для цензора, помимо взлома информации, есть возможность использовать некоторые дополнительные данные для идентификации этих пяти пакетов.

Самой очевидной характеристикой этих пяти пакетов является их длина. В частности:

  1. Первый пакет: очень короткий, единственная переменная - целевой адрес.

  2. Второй пакет: очень короткий, почти фиксированный.

  3. Третий пакет: короткий, с небольшими изменениями, почти единственная переменная - целевой SNI.

  4. Четвертый пакет: длинный, с большими изменениями.

  5. Пятый пакет: очень короткий, с небольшими изменениями.

Можно интуитивно почувствовать, что характеристики длины этих пакетов довольно очевидны. В Vision подход к решению этой проблемы также прост: мы увеличиваем длину каждого короткого пакета до диапазона от 900 до 1400. Обратите внимание, что этот метод отличается от традиционного случайного заполнения; мы не просто добавляем заполнение ко всем пакетам, а основываясь на нашем анализе внутреннего трафика, целенаправленно заполняем характерные пакеты TLS-рукопожатия.

а потому что во время масштабных блокировок под нож может пойти всё, что не HTTPS.

Я вас расстрою - под нож уже идет и HTTPS, при малейших подозрениях РКН банит хостеров целыми подсетями для "проштрафишихся" IP клиентов. См. тему про блокировку доступа к Hetzner и CDN77 на форуме NTC, узнаете много интересного.

Я хочу настроить сервер с XTLS-Reality, как это сделать максимально правильно?

Эту главу вы практически слово-в-слово скопипастили из других публикаций тут на Хабре, совсем офигели, да? Не надо так.

Настройка VLESS с XTLS-Reality

И при этом вы под все эти разговоры о "правильной настройке" оставили панель смотреть голой задницей наружу в интернет. Аплодирую стоя.

на хетзнере не хостятся? а на AWS или digital ocean?

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

Теперь нужно открыть командную строку. Можно найти ее через поиск или нажать Win+R, ввести в поле «cmd» и Enter. В этом случае процесс подключения по SSH в Windows и Linux будет идентичен.

Лучше всегда использовать powershell.exe

А еще лучше открывать его из Windows Terminal, потому что старый conhost не поддерживает все ANSI-последовательности и можно напороться на косяки с отображением tui-приложух

Да какой ему Терминал, когда он пишет до сих пор, что, чтобы открыть cmd, надо нажать Win +, R? Он до сих пор в 2005 году, не зная, что появился PowerShell и поиск в меню Пуск, не говор уже о Терминале. Сомнительная контора: мало того, что площадка для ботов, согласно расследованию, сломанная панель на корню, в которой не работает даже сброс пароля к root, так ещё, везде реферальные ссылки пихают, так просто копипасту пишут везде.

В этом году РКН приобрел китайские DPI железки, которые хорошо умеют определять TLS-based VPN, накатывать вроде как планируется с 25 года. Каждый раз когда я вижу идиотские статьи про "РКН плачет", мне хочется автора немного повозить лицом о статьи "Да что нам РКН, сейчас мы накатим OpenVPN, Wireguard, TOR, VPS в Hetzner..."

Кстати да, у меня как раз Hetzner и ютюб не сказать что бы плавно работает.

Лично у меня в Китае даже Outline работал, не то что reality

Эмм, outline как раз таки проще блокировать чем reality, ввиду того что это чистый shadowsocks.

О том и речь. Хоть его и проще блокировать, тем не менее оно работало. Не везде, но работало. Так что бояться китайского DPI не стоит.

Проблема китайского DPI в том, что он непредсказуем - например, блокировки значительно усиливают во время определенных событий (типа съездов партии).

Поэтому как раз опасно его недооценивать. Когда что-то работает в обычное время, но не работает в те моменты, когда оно нужнее всего - это гораздо хуже.

Про остальное написали, напишу про InvisibleMan-XRay.

Плохая идея - советовать использовать ПО годовалой давности, когда есть v2rayN, Hiddify, или тот же Nekoray под Windows.

"Суть Reality в маскировке под какой-либо популярный сайт, поэтому когда вы решаете это делать, вам нужно добиться того, чтобы ваш IP (IP вашего VPS) вел себя полностью идентично настоящему серверу, которым вы прикидываетесь. " - ни одно из действий, чтобы "добиться того, чтобы ваш IP (IP вашего VPS) вел себя полностью идентично настоящему серверу" в статье не описано.

А потом хостер внезапно поменяет ip адрес, как он это делает регулярно

Ни разу не встречал, за ~10 лет веб разработки. Арендовал VPS примерно у 12-15 хостеров. У некоторых арендовал несколько VPS одновременно.

Да, Aeza на этой неделе принудительно заменила IPv4, и сообщила письмом уже после замены.

Ни один нормальный хостер не будет без согласования с вами менять IP-адрес вашего сервера.

Если только это не какой-то специальный аккаунт с динамической виртуалкой без выделенного IP.

У меня за полтора десятка лет у десятка хостеров ни разу не случалось. Если у вас с кем-то случилось - бегите оттуда.

Иногда у хостеров отзывают сданные в аренду IP. Иногда не соглашаются продлить аренду, адреса не всегда в «собственности». Так что ситуация не невозможна. Но сообщать об этом «постфактум» - это проблема.

может можете посоветовать каких-то, чтоб если не рублями, то хотя бы криптой заплатить можно было?

А есть среди них такие, диапазоны которых определяются как Residential?
Если нет - то где такие есть?

Бывает иногда нужно, для преодоления самых упертых банов с той стороны (нежелезной пока) занавески.

Практически нигде. Это настолько большая редкость, что мне не попадались ни разу.

Иногда упертые баны можно обойти заворачиванием трафика до нужных ресурсов на сервере на Cloudflare Warp.

Ну или найти друзей в другой стране, дать им маленький карманный роутер с openwrt, настроив там reverse tunnel (XRay такое умеет) до своего VPS и выходить в интернет до нужных сайтов через них.

lyrahosting.com
Пользуюсь 2-3 года. Изначально оплачивал эфиром, но после POS начал оплачивать казахстанской картой.
Радует, что cloudflare почти не триггерится нигде.

Месяц назад на аезе сервер отвалился, оказалось сменили IP. В техподержке написали:

В связи с дефицитом IPv4 на рынке, оператор-собственник сети, на которой размещен ваш VPS сервер, потребовал освободить сеть в течение ближайшего времени.
В связи с этим, мы вынуждены заменить ваш IPv4-адрес на другой.

Приносим извинения за доставленные неудобства, мы боролись за сеть до последнего, но оператор настоятельно потребовал ее освободить.

ну аезу я бы и не относил к нормальным хостерам ;)

Вот про обсуждаемого как раз (через полгода), но правда это промо со всеми вытекающимим

Большое спасибо! А лохнекомпетпозор ага, такие слова и не слышал никогда! Короче лет пять-десять суверенного интернета без полиции мыслей есть у нас

UFO landed and left these words here

Подскажите гайды по haproxy? Чтобы можно было делить 443 и на X-UI, не ломая XTLS-Reality, и на свои проекты на том же сервере. Я попробую подружить это с Ansible.

Полтора года ищу, но инфы про эту тему... Заранее спасибо!

https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension

https://gist.github.com/mbentley/0e887c2af7863a562146ee23b121fb33

Но я бы посоветовал вместо этого сделать steal-from-yourself, и в качестве dest взять 127.0.0.1 вашего веб-сервера с вашими проектами, так будет и проще, и надёжнее.

берутся HTTPS-пакеты, и пускаются через наш заранее подготовленный зарубежный сервер (VPS), как через прокси. Однако, стоит учесть, что обращаться к нему мы будем как к какому-нибудь www.google.com ...

РКН попытается обратиться к нашему «‎сайту» без авторизации (атака именуемая как Active Probing) то в ответ лишь получит копию www.google.com со всеми необходимыми сертификатами.

Я ничего не понимаю. Что значит фраза "что обращаться к нему мы будем как к какому-нибудь www.google.com"? Как это мы так сделаем, что наш левый сервер будет со стороны считаться как www.google.com?

Если бы такое было возможно, вся сеть Интернет не могла бы существовать.

Резолвинг адреса google.com, конечно, даст другой IP-адрес. Но поскольку у него много адресов, которые выдаются клиентам, с целью минимизации времени отклика, то это не страшно.

Само обращение к нашему серверу от нас будет идти по IP. Со стороны сессия будет выглядеть как HTTPS. Если кто-то ещё попробует по HTTPS обратиться на IP нашего сервера, в ответ получит страницу google.com. Вроде так.

 Как это мы так сделаем, что наш левый сервер будет со стороны считаться как www.google.com?

Наш левый сервер будет вести себя абсолютно так же как www.google.com, подключения к нему будут выполняться с SNI www.google.com, и даже TLS-сертификат он будет отдавать точно такой же, как настоящий www.google.com, до единого байта.

Но это же настоящий фишинг. Вас сам Гугол не забанит за такое?

Сдается мне, вы неправильно понимаете, что такое фишинг.

В данном случае во-первых нет никакого обмана конечного юзера, т.к. на HTTP-запросы (если клиент не прошел проверку "свой-чужой" для прокси) отвечает настоящий сервер Гугла, и во-вторых промежуточный сервер никак не может перехватить или как-то изменить передаваемую информацию, поэтому нет никакой угрозы безопасности. Плюс этот адрес исключительно для личного пользования с согласия самого юзера (юзер должен его специально и осознанно прописать себе в клиент), широкой публике он неизвестен и о нем вообще кроме самого юзера никому знать не следует. Поэтому фишинг здесь вообще не к месту упомянут.

Понятно, что это инструкция для сверхбыстрой настройки, за полдня с перекуром.

Но для чего-то более стационарного... мне кажется, копия гуглосайта не на IP адресах из AS гугла - будет сама по себе подозрительной.

А вот сайт содержания "я и моя собака", но с HTTPS, и URL для поднятия HTTP connect в виде /oi4uwefdhaskjghlsdklerdfjg98wy54ugsr.txt (которое угадать нельзя и которое можно легко менять), будет эффективнее в расчёте на месяцы и годы. Авторизация, конечно, нужна, но при обязательном HTTPS можно её делать даже Basic.

ерунда - в Китае DPI на ура блокирует работу VPN и делается это не по анализу каких то заголовков а выявлением характерных пакетов которые появляются в результате двойного шифрования передаваемых данных 🤷‍♂️

XTLS как раз и избавляет от двойного шифрования

VLESS работает в Китае, проверил лично)

А кто нибудь сталкивался с тем что связка 3x-UI и nekoray перестает работать при росте количества соединений(до 500)? С Амнезией такая же ситуация. Приходится bittorent в директ выносить, тогда более менее барахтается.

Причем первым складывается DNS служба, резолвинг просто наглухо умирает через пару минут после открытия торрент клиента.

UFO landed and left these words here

VLESS и подобные работают только поверх TCP, то есть даже для работы через UDP для каждой пары адрес+порт создается новое TCP-подключение.
А если там не UDP, а TCP, то умножаем еще количество подключений на два, потому что на каждое входящее подключение от клиента прокси должен установить соответствующее исходящее подключение к серверу назначения.

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

Bittorrent в direct выносить можно и нужно. Если вы в РФ, то можно проксировать только запросы к торрент-трекерам, а к клиентам ходить напрямую. Если вы вне РФ, то проще поставить какой-нибудь qbittorrent-nox на сервер и качать туда, а потом утаскивать к себе по https/sftp.

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

Скорее всего первое, если доверять метрикам самой 3x-ui там утилизация CPU и памяти всегда около нуля болтается. Но с другой стороны количество соединений в районе 500-1000 не должна создавать проблем?

В целом это скорее вопросы разряда "мы не знаем что это такое, если бы мы знали что это такое" просто не очень понятно как и где смотреть затыки в сети с включенной vless. Пинг до любого ресурса магическим образом начинает показывать погоду на марсе, <1мс.

Пинг до любого ресурса магическим образом начинает показывать погоду на марсе, <1мс.

Потому что VLESS и подобные не поддерживают ICMP вообще, вам на пинг отвечает не удаленный сервер, а локальный TUN-интерфейс (не знаю уж, зачем они так сделали).

Еще добавлю.
Можно в качестве теста попробовать взять HTTP2-транспорт для VLESS (он к сожалению не совместим с rprx-xtls-vision, но это временное решение). Там будет работать мультиплексирование, и это может существенно сократить количество активных подключений (но могут быть и побочные эффекты в виде падения скорости, если линк нестабильный или есть затыки по пути до сервера)

Временное решение? Конечно временное, потому что http транспорт удален.

Причина, по которой ранее не применим vision в озвученных транспортах проста: использование vision означает, что прокси не выполняет никаких операций, кроме копирования 1-в-1 от клиентского соединения к целевому соединению, Mux означает, что прокси использует одно соединение для передачи нескольких клиентских соединений, В пределах одного mux-соединения нельзя использовать vision, так как нет способа определить, куда отправлять данные.

На самом деле, область применения H2 Reality изначально была ограниченной. 

Если вам нужен аналогичный функционал, рекомендую уже щупать XHTTP Stream-One H2 & H3.

Этот режим позволяет устанавливать долгоживущие HTTP-соединения для отправки пакетов. Такой подход схож с уже существующими методами, но значительно быстрее и технологичней.

В текущей реализации транспортного уровня HTTP каждое соединение используется для передачи одного проксируемого запроса, без логики разделённой передачи данных. Однако существует серьезный недостаток — отсутствие header padding. Это приводит к тому, что заголовки запросов и ответов имеют фиксированную длину даже при использовании TLS.

Добавить header padding несложно, но обновления безопасности таких вещей не должны быть обратно совместимыми с устаревшими версиями, чтобы избежать их ограничений.

Ну что и было сделано.

HTTP транспорт с Header Padding теперь в транспортном уровенне XHTTP в режиме Stream-One, что  позволит нам задействовать такие функции, как XMUX, без необходимости поддерживать два отдельных кода.

Сервер XHTTP проверяет, соответствует ли x_padding, отправленный клиентом, заданному диапазону (по умолчанию используется стандартное значение). Это исключает совместимость с исходным транспортным уровнем HTTP.

Хотя Вы  можете установить параметр xPaddingBytes в значение -1 для обратной совместимости с текущим HTTP-транспортом, но это не рекомендуется.

Спасибо за лекцию, Капитан Очевидность, вот только нужды в этой лекции ноль :) Я тоже читал посты RPRX и исходники XRay, и про XHTTP уже в другом комменте упоминал кстати.

Конкретно в обсуждаемом случае не важно, что именно используется (пока HTTP2 транспорт не выпилили - в самой новой версии 24.11.30 он еще на месте и отлично работает - вполне нормально использовать и его, это же только для теста), потому что цель в данном случае - сделать временный конфиг на полчаса ( "временное решение") чтобы проверить теорию, что проблема именно в исчерпании системного лимита активных TCP-соединений самым простым способом, и копать дальше в зависимости от того, подтвердилась эта теория или нет.

Зря Вы переходите на подобного тона обсуждения, так как судя по тому что Вы написали ранее:

>> он к сожалению не совместим с rprx-xtls-vision, но это временное решение

никаких исходников, ни комментариев, Вы не читали.

У Вас отсутствует понимание как оно работает и почему это не было реализовано, поэтому называть кого то «капитан-очевидность» не совсем уместно, я же не виноват что мне приходится Вам объяснять очевидные вещи, которые Вы транслируете в мир и которые потом пойдут куда то дальше.

Даже если эта информация не оказалась полезной для Вас, это будет полезным для другого.

P.S. пошел дальше изучать ваши комментарии 😃

никаких исходников, ни комментариев, Вы не читали

Маленький секрет - я даже в репу XRay-core коммитил.
Но вам с дивана, конечно, виднее, что я делал, а что не делал.

У Вас отсутствует понимание как оно работает и почему это не было реализовано

С чего вы это взяли?

Я констатировал простой факт: HTTP2-транспорт (как и голый VLESS с mux.cool) не совместим с Vision, и сказал это чтобы человек выше не забыл его убрать из flow при тестировании. Причины этой несовместимости в контексте обсуждаемой темы не важны совершенно. Вы же с чего-то взяли, что раз я не привел в своем комментарии эти причины, то значит я не знаю о них, прибежали с умным видом просвещать неучей, и это действительно выглядит очень смешно.

Это видно по Вашим ответам, нам с дивана видно все.
Ладно, можете не оправдываться - на первый раз прощаю.

Это видно по Вашим ответам, нам с дивана видно все.

Когда видно что-то, чего на самом деле нет - это называется галлюцинации. При этом ни одного конкретного обоснования в пользу того, что вам мерещится, вы так до сих пор и не привели, ага, ага.

screenshot

Конкретно этот аккаунт не мой.

Есть такая проблема. Ради торрентов поднял IKEv2/IPsec.

Кстати у подмены SNI есть еще один эффект позволяющий "вернуть" ранее существовавшие безлимиты у мобильных провайдеров. Они существуют в виде доступа к определенным ресурсам(skype,whatsapp, и самое забавное youtube) за небольшую доплату.

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

они разве только по SNI проверяют, даже без какой-то просто проверки принадлежности IP к AS'ке или диапазону?

впрочем, если уж идти до конца, то DNSTT часто работает даже там, где вообще запрещен доступ во внешний интернет (например, висит captive portal и требует предъявить аусвайс, или когда интернет отключен за неуплату). но он довольно медленный (два-три мегабита при хорошей погоде) и с большим оверхедом.

они разве только по SNI проверяют, даже без какой-то просто проверки принадлежности IP к AS'ке или диапазону?

Зависит от конкретной реализации такого безлимита, кто-то проверяет по DNS, и тогда замена dns-сервера провайдера на свой - лишает безлимита. Кто-то смотрит SNI и тогда вышеописанный метод будет работать.

А самые упорные действительно способны смотреть и на IP/ASN.

Как поступает ваш провайдер - можно узнать только тестом.

Я не буду брать во внимание настройки которые предлагает уважаемый автор, так как смысл говорить о настройке средств для обхода не имеет смысла без основного момента.

Есть базовые требования безопасности, которые должны соблюдаться при любых условиях. Вы ведь не вводите свои банковские данных на http сайтах? Ведь так?

Так же и в нашем случае, прежде чем осуществлять настройку, доступа по  HTTP в панелях должен быть запрещен — это не принуждение для пользователей, а базовое требование.

Если этого нельзя достичь, то нет смысла в обходе блокировок.Открытый HTTP просто раскрывает приватный ключ сервера. Даже TLS и REALITY могут быть атакованы, а люди все еще пытаются делать вид, что такой доступ это окей.

Это мы еще не говорим про SS/vmess/etc

GFW с первого дня проверяет содержимое простого HTTP. Хотите, чтобы они обнаружили, что ваш сервер работает с Xray?

большинство администраторов панелей не заботятся о безопасности своих пользователей, к сожалению.

я думаю, что GFW в скором времени должен начать активно бороться с некоторыми из этих явно ненадежных схем, чтобы произошло что-то значимое.

Для меня главная проблема Vless - это отсутсвие нормальной документации и нормального клиента на Linux. Пробовал несколько клиентов, так и не смог с Linux подключиться, в итоге вернулся на wireguard.

и нормального клиента на Linux

Ядра XRay и Sing-box изначально кросс-платформенные и разрабатываются в первую очередь именно для работы под Linux (потому что они содержат в себе и серверную, и клиентскую часть, и серверная часть в 99% работают именно на линуксовых машинах).

Если хочется гуй, то Hiddify и Nekoray тоже с первых дней кроссплатформенные и прекрасно работают под Linux.

Пробовал несколько клиентов Hiddify и еще какие-то, в том числе с управлением через web-страницу, все они отображают - "подключено", а по факту подключение идет напрямую, так и не разобрался что не так, при этом с андроида все работало. С wireguard, в т.ч. с клиентом Amnezia вообще никаких проблем.

Клиенты могут работать в двух режимах: proxy и TUN.

В первом случае клиент выставляет себя как локальный socks-прокси, но браузер может плевать на системные параметры (потому что в Linux нет реестра или какого-то единого стандарта параметров, там у всех своя самодеятельность, а env'ы ваш прокси-клиент выставить принудительно всем тоже не может) - проверьте настройки браузера после подключения.

Во втором случае в системе поднимается TUN-интерфейс, как в случае с Wireguard и другими VPN, и такой проблемы нет, но по понятным причинам, клиент может поднять его только если запущен от рута, и об этом люди часто забывают (ну и в настройках клиента надо явно включить TUN иногда).

магические параметры которые путают последовательность и логику, например с DNS, зачем всё это

outbounds:

{ "tag": "dns-out", "type": "dns" }

route.rules:

{ "outbound": "dns-out", "protocol": "dns" },

Путаница с параметрами "а что нужно то?" например dns.final или dns.rules:

{ "outbound": "any", "server": "direct" },

Почему на linux в логах при запросах мы видим domain при resolve, а в windows только IP. Хотя конфиг-сервер-клиент одинаковые? Почему это работает не идемпотентно.

Что значит при sniffer RouterOnly который в выходных пакетах меняет IP->DOMAIN если в TCP\IP пакетах нету domain? или в 2024 кто то сайты по IP вызывает и в http пакете в заголовке host видим IP.

Почему sniffer не влияет на маршрутизацию с параметрами ip4_only? Тоесть если вызвал ресурс , он маршрутизируется как по IP route, так и по Domain route. Кто его просил?

Зачем нужно вообще настройка prefer_ipv4 если для сайта так и так придется делать resolve domain->IP (потому что так работает интернет), и у нас так и так будет связка DOMAIN:IP для пропуск через таблицу маршрутизации?

Если в DNS указать http://8.8.8.8 и detour proxy, почему этот запрос всё равно идет по таблице маршрутизации в чём смысл?

Что значит при sniffer RouterOnly который в выходных пакетах меняет IP->DOMAIN если в TCP\IP пакетах нету domain?

А с чего в взяли, что он меняет это в выходных пакетах? XRay - это не VPN, он не оперирует IP-пакетами, он оперирует потоками. И даже если на клиенте у вас TUN-интерфейс, то за ним всегда стоит tun2socks или подобное (а у sing-box оно из коробки встроено на базе gvisor и еще чего-то там), что "пересобирает" IP-пакеты от клиентских приложений в поток и запихивает данные в SOCKS-inbound.

Давайте сначала про сниффинг и destOverride в целом. Браузер хочет подключиться к серверу google.com, отрезолвив его адрес как 11.22.33.44. Клиент говорит прокси-серверу: мне надо подключиться к 11.22.33.44. Сервер говорит клиенту "валяй", подслушивает что там клиент собирается послать серверу, видит в TLS-хендшейке SNI "google.com", резолвит сам еще раз google.com, видит, что он резолвится в 55.66.77.88, и вместо 11.22.33.44 устанавливает подключение к 55.66.77.88.

Зачем нужна такая подмена: бывают случаи, когда на клиентской машине резолвинг происходит через провайдерский DNS (например, если у вас нет TUN, а вы укажете в системе XRay как локальный SOCKS-прокси, некоторые софтины будут сначала резолвить домен, а потом использовать отрезолвенный адрес как параметр в SOCKS-подключении). В таком случае, для заблокированных сайтов у вас вместо настоящего IP-адреса будет адрес заглушки с сообщением о блокировке, даже если вы пойдете до него через прокси. destOverride решает эту проблему.

Если вам это не надо - можно включить routeOnly: true, и тогда подслушанные данные будут использоваться только для роутинга, а подключение будет выполняться по тому адресу, о котором попросил клиент. Документация: https://xtls.github.io/ru/config/inbound.html#sniffingobject

Тоесть если вызвал ресурс , он маршрутизируется как по IP route, так и по Domain route.

Роутинг работает в соответствии с правилами. Чем выше правило, тем выше у него приоритет. Там есть параметр domainStrategy, где можно задать, роутить ли только по домену, роутить ли по IP если домен не совпал ни с одним правилом, и роутить ли только по IP. Документация: https://xtls.github.io/ru/config/routing.html#routingobject

например с DNS, зачем всё это

Это нужно для того, чтобы при использовании TUN-интерфейса можно было перехватывать DNS-запросы от клиента (UDP/TCP на 53 порт куда-либо) и перенаправлять их на встроенный DNS-сервер XRay, например, для оптимального кэширования (если у вас на прокси много пользователей), или для подмены адресов, или для использования DoH/DoT если клиентское приложение в них не умеет, или чтобы выдавать клиенту только A-записи без AAAA-записей (если у вас на сервере не работает IPv6, чтобы избежать ожидания фоллбэка или утечки в обход прокси при отсутствии IPv6-маршрутов на клиенте), или резолвить разные доменные записи разными серверами (например, если вы делаете гейт в Tor для .onion-сайтов). Документация: https://xtls.github.io/ru/config/dns.html

Сейчас выглядит неплохо, видимо доделали. Раньше там была помойка либо на китайском либо с мерзким переводом и гораздо меньшим количеством информации, если мне не изменяет память.

Самый шикарный "плюс" аезы - в том что однажды мне приходит письмо - "ваш root пароль изменен на такой-то". Это хорошо еще, что я был у компа, а не в отпуске. Предствляете, какие эмоции, когда на вашем сервере кто-то уже начал хозяйничать и замки меняет? Бросаю все дела, влетаю на сервак (пока мои ключи там еще не сменили): всем стоять, полиция Гонконга! Сверяю ключи, открытые сессии, да вроде все норм... может кто-то в админку влез? Лезу в админку, там уведомления:

...

For the security of previously created services, we have performed a one-time password update for all virtual services to a unique password with a strong length and format....

В общем, эти веселые ребята с мясокомбината внезапно решили, что все равно у них серьезные люди не хостятся, так, школота да нищеброды второсортные - а не сменить ли им рутовые пароли по приколу? И поменяли! Это лучший сценарий. Худший - кто-то (ФСБ? просто друг админа?) захотел удаленно зайти на мой сервак, пароль они не знают, поэтому поменяли для своего удобства.

Промо сервак у них в самом деле неплох для своей цены. (То есть, плох, но для своей цены - очень даже норм). Но ничего кроме этого брать там в обозримом будущем не буду.

P.S.

Если они напишут ФИО того, кто ответственнен за эту смену паролей, и выложат приказ, где я увижу, что он уволен - тогда я может быть изменю свое мнение о них. Но пока тот человек у них работает - ничего хоть капельку важного хостить там не буду, и всех буду отговаривать.

И еще - использовать для VPN сервак от российской компании.... ну такое... если хотите, чтобы товарищ майор за каждым комментарием, который вы отправили через этот VPN видел ваши ФИО, платежные данные, емейл и привязанные аккаунты - тогда да, подходит.

Как то раз тоже купил там VPS под VPN. Хотел попробовать подключить свой ISO-образ, так после его подключения пропала возможность любых действий с сервером кроме перезапуска и отключения, и всегда висела ошибка по этому образу. Написал в чат поддержки, ответили на следующий день, и так несколько дней ушло на несколько сообщений в чате и соотвественно решение проблемы, в итоге сказали что не могут решить проблему и предложили другой сервер. Настолько отвратной техподдержки нигде не встречал, чтобы днями ответ ждать.

только сейчас я заметил (тормоз, что поделать), что кликбайтный заголовок является аллюзией на старую загадку "где 99 плачут а один смеется ?" (ответ - в ГУЛАГе, по данным то ли Солженицына то ли Шаламова не помню точно). то ли автор хочет сказать "добро пожаловать в цифровой ГУЛАГ, дорогие рассияне. а вот вам тропинка для побега" то ли уже не знаю что и думать.

Мой VDS-провайдер обеспечивает консоль к серверу на странице моей учётной записи, причём это "железная" консоль, на которой отображается в том числе вся перезагрузка. Собственно, при этом доступ по сети к самому серверу не происходит, поэтому что-то отломать и остаться без доступа невозможно. Отсюда, SSH стал ненужным, ни на порту 22, ни на каком другом. Считаю, удобная штука.

Такое практически у любого хостера есть

ой, псина и даром не надо!

Простите, но такое "подробное руководство" очень похоже на руководство по ремонту авто - "откройте интернет и найдите телефон ремонтной мастерской, попросите к телефону мастера".

Это не руководство по установке и настройке, это реклама и описание сервиса.

А чем не устраивает warp? Я его даже не вырубаю, если только для лучшего пинга в игре. Для меня с вкл warp это увеличение пинга на 25-30 мс, а с warp+ вовсе на 10-15 мс (вот бы ещё узнать как оплачивать). На Андроиде нужно поменять протокол на masque в настройках, если автоматически не хочет, на винде тоже, но уже через команды в консоли (с вкл временно другим vpn).

А чем не устраивает warp

Тем, что он использует Wireguard, который давными-давно уже научились детектировать и блокировать, плюс ещё адреса серверов Warp тоже известны и блокируются элементарно, поэтому даже переход на Masque не поможет - оно тупо сразу перестанет работать при малейшем шухере.

Тем, что он использует Wireguard

Как раз таки больше не использует (вернее есть выбор), Masque это замена для Wireguard, а одна из его особенностей, это то, что его не отличить от обычного зашифрованного веб-трафика. Пользуюсь около 2 мес. (с середины октября) без проблем, в инете уже и русскоязычные статьи можно найти, как включить на Винде, я до этого ещё на Reddit'е нашёл. Ну даже если заблочат когда-то и каким-то образом, сейчас-то работает отлично.

Masque это замена для Wireguard, а одна из его особенностей, это то, что его не отличить от обычного зашифрованного веб-трафика

Я это прекрасно знаю, но вы кажется не внимательно читаете. Речь о том, что адреса endpoint'ов для подключения у warp хорошо известны, и следовательно их могут в любой момент элементарно заблокировать даже без какого-либо анализа протоколов.

Я это прекрасно знаю, но вы кажется не внимательно читаете. Речь о том, что адреса endpoint'ов для подключения у warp хорошо известны, и следовательно их могут в любой момент элементарно заблокировать...

Я достаточно внимательно читаю и на это тоже ответил, процитирую:

Ну даже если заблочат когда-то и каким-то образом, сейчас-то работает отлично.

Нас пугают отключением от всемирного интернета, так что теперь, уже перестать пользоваться им из-за того, что когда-то может быть это действительно произойдёт?

Я вас не отговариваю, хотите тратьте свои деньги на свой VPN, когда в данный момент есть полностью бесплатный и быстрый аналог. Я лишь уведомил о такой возможности тех, кто мог не знать об этом, ведь к ранее Warp перестал работать, а на Винде и сейчас не работает, без ручной настройки через терминал.

Нас пугают отключением от всемирного интернета, так что теперь, уже перестать пользоваться им из-за того, что когда-то может быть это действительно произойдёт?

Нет, неправильно. Речь о том, что всегда надо быть на несколько шагов впереди цензоров, чтобы когда те закрутят гайки сильнее, не пришлось в панике бегать и искать хоть какие-то другие рабочие варианты.

Речь о том, что всегда надо быть на несколько шагов впереди цензоров, чтобы когда те закрутят гайки сильнее, не пришлось в панике бегать и искать хоть какие-то другие рабочие варианты.

И всё это время платить за ненужный сервер? А через несколько лет узнать, что бесплатный способ как работал, так и работает? Ваше дело

Сервера стоят копейки (меньше доллара в месяц), так что их можно иметь хоть пачками (особенно учитывая, что они подходят и для разных других применений кроме прокси). А вот в критический момент остаться без связи - это выйдет гораздо дороже, чем заранее купить и настроить сервер.

Сервера стоят копейки (меньше доллара в месяц), так что их можно иметь хоть пачками (особенно учитывая, что они подходят и для разных других применений кроме прокси).

Ну если бы было так, да только я нигде таких цен не встречал и в самом посте скрин с самой низкой ценой почти 5 евро/мес, я даже российских серверов не встречал дешевле 100 рублей раньше, а сейчас тем более. Может подскажите, хотя бы, где найти такое добро?

То, что вы их не встречали, означает лишь то, что плохо искали.

Самый недорогой сервер в РФ у меня с год назад был за 44 или 55 рублей, не помню точно. Другой за 75.

Эти адреса УЖЕ давно заблокированы и с мобильных операторов давно не работают.

У меня и у других знакомых работают ¯\_(ツ)_/¯

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

Статья хорошая но хотелось бы действительно подключение по сертификатам а не по паролю и более глубокие настройки увидеть, а главное детальное описание что и зачем.

Но в любом случае статье +

Вот где найти полностью работоспособный клиент для Android TV? V2Ray перестал работать, Nekobox работает криво ((

Вот за это большое спасибо! Все облазил в поисках.

Sign up to leave a comment.

Articles