Comments 351
А теперь у меня к вам есть просьба.
Мы все понимаем, что в нынешних реалиях и с новыми "законами" возможно эта статья здесь проживет только считанные дни. Как только кто-нибудь настучит, так в лучшем случае российские госорганы заставят Хабр закрыть ее для пользователей из России, в худшем случае — удалить целиком. Поэтому у меня есть к вам просьба:
Разошлите ссылку на эту статью своим знакомым, кому может быть интересна эта тема, и просто тем, кто в случае чего может помочь вам это настроить.
Делайте копии этой статьи где только можно - в личных блоках, в социальных сетях, на Telegraph (лицензия Хабра разрешает это при сохранении ссылки на оригинал)
Сохраните копию этой статьи к себе на диск в формате PDF! И другие статьи, про которые я говорил, тоже. Пока статья жива, обновляйте копию, здесь будут появляться дополнения, исправления ошибок и ценные комментарии.
Распространяйте сохраненный PDF с этой статьей по телеграм-группам и форумам.
Чем большему количеству людей всё это поможет (для благих целей) — тем лучше.
Кто скачивал/сохранял статью - пересохраните еще раз! Был исправлен ряд серьезных ошибок и существенно дополнено содержание.
Для тех, кому, также как мне, лень вручную очищать такие полезные статьи, чтобы сохранить в PDF - написал bookmarklet - он оставит только статью и комментарии, а также раскроет все спойлеры - останется только отправить на печать в PDF-принтер.
Пользуйтесь на здоровье
javascript:(function(){( () => {document.querySelectorAll( "details" ).forEach( i => i.setAttribute( "open", "" ) ); const dels = [".tm-base-layout__header",".tm-header",".tm-page__sidebar",".tm-comment-form",".tm-block_spacing-bottom",".tm-comment-navigation",".tm-footer-menu",".tm-footer",".tm-article-sticky-panel",];let el;for ( const s of dels ) {const els = document.querySelectorAll( s );if ( els ) for ( el of els ) el.remove();}el = document.querySelector( ".tm-page__main" );el.style.maxWidth = "100%";} )()})()
Спасибо за статью! Все давно настроено, но посмотрел, нет ли чего новенького)))
Не увидел, но очень важно:
В настройках Hiddify Next выберите "Активы маршрутизации" и регулярно обновляйте по трем точкам (2-3 раза в месяц точно обновляются).
Также, кому важно, протестировал все клиенты на Android TV / Google TV. Корректно работает только Hiddify Next. Правда стандартным пультом не зайти в настройки. Только включить и отключить. Покопаться в настройках и все сделать можно через AnyDesk, мышкой, управлением с телефона (кому как удобнее). Понравилось раздельное проксирование (Кинопоиск напрямую, а Prime и Netflix через сервер). Очень удобно.
У меня получилось завести. Был затык в том, что по умолчанию SSH сервер не разрешает туннелирование трафика. Чтобы разрешить, нужно на сервере в файле /etc/ssh/sshd_config добавить/заменить параметр AllowTcpForwarding yes.
Кстати, 21 марта Хабр по требованию Роскомнадзора был вынужден заблокировать доступ к этой статьи с территории РФ. Ура товарищи!
А теперь у меня к вам есть просьба.
Мы все понимаем, что в нынешних реалиях и с новыми "законами" возможно эта статья здесь проживет только считанные дни. Как только кто-нибудь настучит, так в лучшем случае российские госорганы заставят Хабр закрыть ее для пользователей из России, в худшем случае — удалить целиком. Поэтому у меня есть к вам просьба:
Разошлите ссылку на эту статью своим знакомым, кому может быть интересна эта тема, и просто тем, кто в случае чего может помочь вам это настроить.
Делайте копии этой статьи где только можно - в личных блоках, в социальных сетях, на Telegraph (лицензия Хабра разрешает это при сохранении ссылки на оригинал)
Сохраните копию этой статьи к себе на диск в формате PDF! И другие статьи, про которые я говорил, тоже. Пока статья жива, обновляйте копию, здесь будут появляться дополнения, исправления ошибок и ценные комментарии.
Распространяйте сохраненный PDF с этой статьей по телеграм-группам и форумам.
Чем большему количеству людей всё это поможет (для благих целей) — тем лучше.
Да тебе медаль за такое надо дать!
Как только кто-нибудь настучит, так в лучшем случае российские госорганы заставят Хабр закрыть ее для пользователей из России, в худшем случае — удалить целиком.
Статьи из списка уже начинают прикрывать. Одно радует, их можно читать через иностранный VPN.
Hidden text
Это какая конкретно статья?
Кстати, было бы неплохо собрать все такие статьи в архив и распространять скажем торрентом.
Это статья "четыре" из приведенного в начале списка.
Ее бывший адрес https://habr.com/ru/articles/728836/
И кстати, если маршрутизировать российские IP и домены напрямую, то обход блокировок из статьи не поможет. А если всё пускать через прокси, то, как в статье и написано, возможно будет сопоставить трафик туда и обратно.
Тут неплохо в пдф сконвертировалось
Вот только спойлеры не раскрываются
Я все сохраняю в mhtml. Для этого достаточно в браузере на базе хрома включить опцию save-page-as-mhtml. Но вот все спойлеры приходится открывать заранее перед сохранением, это явно какая-то недоработка формата (они же наверняка не по ajax запрашиваются при открытии, а сразу приходят вместе со страницей? в общем непонятно)
У меня похожая бурда была одно время при просмотре страниц в режиме Reader View из FF. Потом, вроде, стало лучше. Это должно лечиться правильной вёрсткой, статья (и комментарии, которых в Reader View до сих пор не видно) должны быть при упрощённом просмотре текста с утюгов не умеющих в js, всяких инстапаперов, е-книг и прочих медиа-реквестах типа @media print, но все забивают
Еще неплохой вариант сохранить в markdown файлы, расширением типа Markdownload, а потом в базу знаний - например в Obsidian. У меня там все статьи уважаемого MiraclePtr на эту тему уже надежно хранятся. И кстати, в makrdow и спойлеры сохраняются и код корректно отображается.
Слава тебе Господи, не я один такой сумасшедший)
А сразу её выложить в PDF++?
не вижу ссылки на pdf, который нужно распространять.
1. пролистываете статью, раскрывая спойлеры
2. в браузере нажимаете "Печать" -> "Печать в PDF"
= вы восхитительны, у вас есть PDF, который можно и нужно распространять!
(можно в режиме инкогнито, если не хотите чтобы был виден ваш ник)
в созданном pdf (драйвер млкософта) нет части форматирования. например, код не выделяется цветом фона и поэтому сливается с обычным текстом.
у вас странная логика. потратить кучу времени на написание статьи и ничего не всделать для ее сохранения.
и еще умиляют 300 человек, которые статью в закладочки добавили.
Используйте хром, у него своя сохранялка при "Печати", там все нормально
Не совсем
PDF не лучшее решение для сохранения страниц, например сожрутся строки с горизонтальной прокруткой.
лучшее решение на мой взгляд - https://github.com/gildas-lormeau/SingleFile
заодно подтягивает все фреймы, lazy картинки. На выходе удобный HTML все-в-одном, при желании еще и сжатый.
заодно подтягивает все фреймы, lazy картинки
Судя по опыту сохранения статей Хабра с длинными тредами он не всегда все комментарии сохраняет. Выход - перед сохранением прокрутить все ветки комментариев чтобы они все прогрузились.
да, это расширение сохраняет норм, в отличие от pdf.
только нижняя панель с ретингом статьи не убирается. чтобы ее убрать, нужно в содержимом файла заменить
.tm-article-sticky-panel{position:sticky;bottom
на
.tm-article-sticky-panel{bottom
Лет 15 использую расширение браузера ScrapBook (сейчас другой разработчик и наименование другое - WebScrapBook). Сохраняет web-страницы: отдельные, с заданной глубиной вложенности, по маске... Все вырезки держу в отдельном каталоге, который автоматически синхронизируется с моими рабочими компами. Можно просматривать вырезки по сети на встроенном web-сервере (python), но только просматривать, а не дополнять - поэтому синхронизирую с компами.
Сохраненные страницы можно редактировать - убирать лишние блоки, выделять текст маркерами, создавать заметки к частям текста...
Нет проблем с отображением всех комментариев? Или необходимо страницу докручивать до конца перед сохранением?
Проверил... если открыть ссылку и и сразу захватить страницу, то комментарии не развернуты:
Если прокрутить страницу вниз, до начала комментариев - то они разворачиваются.
Но я думаю - это работа самого сайта, для ускорения загрузки страницы.
PS. Свёрнутые (скрытые) блоки - разворачиваются после захвата
выбираю save as pdf в distination. код без фона, как я писал выше.
В чем проблема использовать сохранение в .html?
Если сохранять как один файл, то оно сохраняет только текст, могут потеряться картинки, стили, и т.д.
Если сохранять как много файлов, то неудобно передавать, нужно упаковывать в архив и потом распаковывать обратно.
В яндекс браузере пкм, сохранить страницу. Работает как живая, все картинки, скрытые списки и ссылки. Качается страница с папкой ресурсов, картинки, скрипты и т.д.
нет части форматирования. например, код не выделяется цветом фона и поэтому сливается с обычным текстом.
При печати в том же Chrome выбрать More settings -> Background graphics
и еще умиляют 300 человек, которые статью в закладочки добавили.
Так статья же хорошая, вдруг понадобится где-то на безопасном расстоянии от страны, в которой результаты выборов обсуждают задолго до самих выборов, и сразу называют целевые показатели в, кажется, 85%. Причем не для обхода блокировок вовсе.
Сохранил в веб архив
https://archive.ph/48HMR
Рекомендую сделать копию статьи на телеграф
Жаль на Хабре заблокирован Instant View, так бы могли читать прямо в превью Телеграма.
Кстати, если сделать копию страницы с каким-то предсказуемым названием (например "Обход блокировок"), то через nudecrawler можно будет попробовать найти, даже не имея закладок - просто по заглавию (адрес отражается в названии).
$ docker run --rm -v /tmp/run:/work yaroslaff/nudecrawler nudecrawler --total 0 -a "обход блокировок"
# No cache file /work/cache.json, start with empty cache
Loading nudenet classifier....
INTERESTING (ALL) https://telegra.ph/obhod-blokirovok-03-19 (0.0s)
Total images: 0
INTERESTING (ALL) https://telegra.ph/obhod-blokirovok-03-18 (0.0s)
Total images: 0
INTERESTING (ALL) https://telegra.ph/obhod-blokirovok-03-17 (0.0s)
Total images: 0
INTERESTING (ALL) https://telegra.ph/obhod-blokirovok-03-17-2 (0.0s)
Total images: 0
INTERESTING (ALL) https://telegra.ph/obhod-blokirovok-03-13 (0.47s)
Total images: 1
Самостоятельный поиск - хорошая штука, когда обычный поиск недоступен или фильтруется.
Ещё вы можете выложить эту же самую статью (либо в markdown формате, либо в PDF) на github/gitlab либо вообще magnet-ссылкой на торрент.
P.S. Я вообще все свои статьи так дублирую, потому что они мне дороги и я не хочу зависеть от администрации хабра. Мой репозиторий для примера: https://github.com/Kright/my-articles
Поставил бы плюс, если бы мог. Статья - супер.
Хотя надеюсь не дожить до того дня когда в моей стране мне это понадобится.
Но сохранил тем не менее.
И VPN у меня давно есть :)
Надо было писать не обход роскомзабора, а западных санкций. На многие западные ресурсы без впн никак. Ну а то что заодним еще и роскомзабор обошли, ну так это случайно. 😅 Проживет в сети явно дольше.
Я сохраняю полный слепок страницы в html, для этого использую плагин браузера SingleFile.
Для того, чтобы сохранить важную информацию обычно делаю слепок страницы в виде HTML. Для этого использую дополнение браузера SingleFile.
Прошу заметить, что в действительно ХУДШЕМ случае за эту статью могут включить весь ресурс в список запрещенных. :((
--
17 ноября 2023 г. правительство РФ выпустило постановление, позволяющее Роскомнадзору включать в Единый реестр запрещенной информации сайты, которые раскрывают способы обхода блокировок других онлайн-ресурсов. Для включения того или иного интернет-ресурса в Единый реестр запрещенной информации появилось еще одно основание. Если на нем есть сведения, как получить доступ к сайту, который уже заблокирован в России, то ресурс подпадает под ограничения.
Tor - адреса входных нод доступны в публичном реестре, и поэтому могут быть легко заблокированы. Бриджи (bridges) пока работают, но РКН в прошлом неоднократно их выборочно банил
Рано вы Тор хороните, на который и в Китае управы нет, старый добрый obfs4 хорошо работает. Мосты живут по несколько месяцев, если брать их не из тор-браузера. Только сегодня трансляцию SpaceX в твиттере через него смотрел. А мосты из браузера да, давно уже банят.
перспективы tor сомнительны, я предполагаю что на его удушение росТОРнадзор до сих пор не выделил достаточно ресурсов в т.ч. интеллектуальных. в любом случае лучше иметь проверенный запасной вариант, чем не иметь.
Есть такой интересный документ из недавних, отчёт группы GFW-Report под названием "How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic", в том числе про то, как в случае необходимости они блокируют obfs4 и подобные протоколы в Китае.
Мы пока не Китае и операторы Tor успешно борятся с РКН.
Не очень успешно. РКН уже игрался с блокировками по белым спискам, tor-бриджи с obfs4 в таком случае тоже отваливаются.
А также вносил в чёрный список личные серверы с замедлением или блокировкой по портам, но блокировка новых бесплатный регионов ProtonVPN прошла с лагом в пару недель, как и говорят в ролике.
РКН успешно поблочил спаршенные бриджи obfs из вшитых конфигов сетапера тора, snowflake держится уже год-полторта.
В последний раз snowflake отвалился не из-за РКН, а из-за хостера Fastly, которым прикрывались в domain fronting. Но это полечили, там по ссылке есть рекомендация.
А еще есть webtunel транспорт, который тоже вполне работает.
Я с начала февраля не могу подобрать входную ноду, чтобы TorBrowser заработал (Ростелеком, Москва). Он или бесконечно коннектится, или падает.
Можете подсказать источник доступных нод?
Попробуйте запросить бридж у телеграм-бота или через емайл-адрес.
Если будете запрашивать бриджи, то они там обновляются раз в день, чаще смысла нет запрашивать.
У телеграм-бота запрашивал около 20 штук, ни одна не заработала.
Про емайл-адрес попробую. Спасибо!
Разработчики Tor'а на днях выкатили новый протокол для бриджей WebTunnel, можно запросить через сайт (позже можно будет и через тг и мейл). У меня работает.
тольно не HTTPTunnel, а WebTunnel, они его так называют
Скачал новую версию 13.0.11 - она сама нашла бриджи, когда указал, что я в России. Старая 13.0.8. так не могла. Спасибо разрабам за прогресс!
Спасибо, обновился, заработало с WebTunnel. Хотя пришлось с настройками повозиться, опять они в torrc все поменяли, со старым конфигом не хотел заводиться.
Вот тут беру,всё работает:https://bridges.torproject.org/
Входные ноды скорее всего почти все переблочены, это не сложно, потому и нужен мост (bridge) между пользователем и входными нодами тора. Где их брать выше правильно подсказали.
Кстати, тор умеет работать как сервис ОС, а не как компонент браузера. То есть TorBrowser не обязателен для работы тор, у меня он даже не установлен.
Если все кажется очень сложным
Мне кажется вы сами все делаете предельно сложным.
А ведь можно просто разместить в статье конфиги на Terraform и Ansible или их аналоги.
Какая интересная компания...
В этот список можно же добавить отдельно Украину, вышеупомянутый Туркменистан, ненулевое кол-во других стран азии и африки, ЕС (451 из-за GDPR), ЕЭС (санкции), доступ к госсайтам извне (и другим, блокирующим по гео-признаку). Веселье только начинается.
Блокировки это не бинарное явление. В некоторых странах ресурсы блокируются только по решению суда, а обойти блокировку можно элементарной сменой DNS-сервера на гугловский, а в некоторых странах блокируют сразу целые диапазоны адресов просто по желанию какого-то тупого чиновника, воюют с технологиями обхода блокировок (тратя миллиарды денег на оборудование для цензуры), а рассказ об этом считается незаконным.
Мир очень разный, и тренды в нем очень разные. Цензура в том или ином виде есть везде, но ее проявления, масштабность, темпы развития и отношение к ней общества очень разные. Именно поэтому в списке стоят вместе Китай, Иран Афганистан и Россия, но нет стран ЕС, про которые вы сказали, - в них у жителейпросто нет нужды в таких мощных и сложных инструментах как Hiddify, и наврядли эта нужда появится в ближайшее время, в то время как перечисленных в списке странах это уже реальность сегодняшнего дня, и становится только хуже и хуже.
Ладно, Украина - она банит русскую пропаганду, но ЕС чем не угодил? Я тут живу, кроме всяких торрентов, ничего забаненного не встречал.
Скорее наоборот, из ЕС ряд сайтов в США недоступен. Мол, сорямба, мы не готовы следовать GDPR, пожалуйте на выход.
Можешь привести пример? Чисто, ради интереса, потестировать.
Регулярно встречал местечковые новостные сайты США (точнее, они же под кем-то находятся), которые вместо cookie banner тебе 451 дают, что мол не можем из-за легальной ситуации вам сейчас дать доступ из Европы. Ссылок нет, такое найти намеренно будет не проще, чем припаркованный домен (полчаса потратил тогда).
Регулярно = достаточно часто, что запомнилось.
451: Unavailable due to legal reasons
We recognize you are attempting to access this website from a country belonging to the European Economic Area (EEA) including the EU which enforces the General Data Protection Regulation (GDPR) and therefore access cannot be granted at this time. For any issues, contact customerservices@timesargus.com or call 802-479-0191.
В Украине банят не российскую пропаганду, а все крупные российские сайты целиком) их можно понять, но цензура есть цензура, и ничего хорошего в ней нет
Я ж не зря ЕЭС отдельно привел. Не хотел распространяться тут, но Google с Youtube очень странные вещи творил еще до официально принятых решений против СВО. Я не вдавался в подробности, потому лишь текстом напишу:
Геоблок на каналы рос. СМИ в YT. На странице поиска каналы были видны, при переходе ошибка (не помню какая именно, но не буквальная). Геоблок распостранялся не только на - как бы - страны ЕС, а выходя через VPN Норвегии и Швейцарии я наблюдал ту же картину. Вот через США и другие страны доступ был. Пока каналы спустя пару дней полностью не удалили. Потом последовало оф. принятое решение о санкциях, в т.ч. о блокировке и отзывах лицензий СМИ. Если пресса написала о блокировке трансляции RT (к чему и без того несколько лет население готовили), то блокировка rt-com посредством провайдерского DNS прошла практически без фанфар.
https://www.sistrix.com/blog/eu-sanctions-takes-rt-com-out-of-google-search-results/
https://www.consilium.europa.eu/en/press/press-releases/2022/03/02/eu-imposes-sanctions-on-state-owned-outlets-rt-russia-today-and-sputnik-s-broadcasting-in-the-eu/ Здесь про веб (еще?) ни слова
https://lv.baltnews.com/News_Latvia/20220317/1025515427/Potomu-chto-potomu-v-Latvii-zablokirovali-rossiyskie-sayty-.html Более менее какой-то список представили по Латвии здесь
Точно так же как и СМИ не освещали практически интернет-цензуру в других странах. Максимум про Китай известно, а про Россию из профильных сайтов-СМИ. Следовательно, нет запроса настраивать граждан против этого феномена.
Перенаправляют на страницу http://nelegalssaturs.lv/
Заблокированы, в частности, vk.com и yandex.ru. Блокировки также осуществляют сторонние компании, обнаружил на публичном DNS-резолвере от Cogent/Sprint.
$ dig yandex.ru @204.117.214.10
; <<>> DiG 9.18.24 <<>> yandex.ru @204.117.214.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38147
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9ba12e0d97d2717c01000000660abce0f36a89712a2d2512 (good)
;; QUESTION SECTION:
;yandex.ru. IN A
;; ANSWER SECTION:
yandex.ru. 5 IN CNAME nelegalssaturs.lv.
nelegalssaturs.lv. 1793 IN A 81.198.74.204
;; ADDITIONAL SECTION:
lv-blockedzones. 1 IN SOA LOCALHOST. support.cogentco.com.lv-blockedzones. 2024032600 3600 900 2592000 7200
;; Query time: 1439 msec
;; SERVER: 204.117.214.10#53(204.117.214.10) (UDP)
;; WHEN: Mon Apr 01 20:55:44 +07 2024
;; MSG SIZE rcvd: 209
Ага, так же N-ое количество ближневосточных стран ОАЭ, Катар, Саудия, Египет, Оман etc тоже туда. Индия и Пакистан туда же)
Кстати, Дуров там обеспокоен свободой интернета в Дубае, где не половина интернета, но хорошая часть заблокирована или он тоже прокси использует, чтобы позвонить!? :)
У меня в 3X-UI панели в настройках в этой компании еще почему-то Въетнам. Интересно, там тоже что ли все плохо? Как-то не слышал про Въетнамский файервол.
Там выборочный бан всех сайтов, где кто-нибудь говорит плохое про ВВП КПВ или там про протесты внтури страны рассказывает.
В индексе свободы прессы 172 место из 179 стран.
У Украины 79-е -- огонь! =)
У Украины 79-е -- огонь! =)
Не забудьте еще упомянуть страны, где негров линчуют - тоже отличный демагогический аргумент.
Просто странная позиция в рейтинге с учётом наличия пополняемого списка для обхода блокировок для граждан страны (Заборона) и иных обстоятельств в этой сфере (в смысле СМИ и соцсети). Не думаю, что в Грузии или Армении как-то сложнее с работой журналистов (или Азербайджан, я не запомнил, кто из них ниже был, смотрел на карте проекта).
Вас беспокоят чужие негры? Суд Линча не есть хорошо в любом случае.
Посоветуйте, какой защищенный протокол лучше сделать.
Сейчас стоит pfSense, на который пересылается список блокированных IP который отлавливает сниффер в соседней виртуалке. pfSense по этому списку перебрасывает траффик на другую виртуалку, которая работает как роутер через установленный на нее VPN. Сейчас стоит Wireguard, но нужно его менять, только на что?
Я бы посоветовал openvpn + Cloak. Они нормально запускаются из systemd-юнитов, надёжны, и относительно легко настраиваются. Openvpn я люблю за то что он хорошо работает в режиме бриджа "сеть-сеть" и нормально поддерживают любую сложную маршрутизацию (хотя там есть нюансы).
Я добавлял Cloak к уже существующему openvpn-серверу и клиенту, это вообще работа на полчаса по инструкции. С openvpn придётся повозиться, если нет опыта, но зато он богат по возможностям. Читал (но сам не пробовал) что можно использовать Amnezia для установки как раз связки OpenVPN + Cloak на сервере и дальше экспортировать конфигурацию, которую использовать в консольных клиентах (и их запускать автоматически).
Спасибо, быстро глянул про Cloak. На сколько понял, Cloak создает дополнительный интерфейс, через который и работает. Получается, можно существующий WG через него же пустить.
Да, это тормозно, но работает.
Про скорости в десятки мегабайт в секунду можно забыть.
Быстрое гугление показало что вроде так можно, но я сам не пробовал.
Уже нашел инструкцию, разбираюсь.
Если кому интересно: тыц
Я так и сделал. Cloak не интерфейс создает, а порт слушает на localhost клиента (этот порт - endpoint для WG), а на сервере шлет на порт WG также на localhost. Оба работают как сервисы systemd.
Про скорость. Канал 170Мбит/с. Клиент: WG+Cloak на Ubuntu 22.04 минипк N95/4 ядра, RAM 8. Сервер: дешевая VPS за 3 Евро с 1 ядром и RAM 2G также на базе Ubuntu 22.04. iperf3 через WG без Cloak выдавал 140, с Cloak - 65. Что ОЧЕНЬ важно - размер MTU у WG. При установке стоял у клиента 65535, разумеется, фрагментация. CPU на 4 ядрах подскакивал до 40% при 65Мбит, на сервере MTU был указан 1420. Поставил 1400 везде, теперь CPU у клиента на каждом ядре не выше 5% при тех же 65Мбит. Я полагаю, что узкое звено - это дохлая VPSка, на которой еще крутится ffmpeg, который тянет по RTSP 10Мбит, конвертит аудио и сохраняет потоки. Если сервер на 2 ядрах хотя бы, то вполне 100МБит выжать, думаю. Возможно поможет эта статистика личного пользования.
Поэтому часто советуют настраивать раздельную маршрутизацию на клиентах
можно упростить двумя методами:
1) один браузер - для обычных сайтов через открытый И-нет, второй - для обходных путей, третий (в максимальной изоляции) - для госсайтов (это будет хромиум гост или яндекс браузер мать его мизулина).
2) один браузер и несколько профилей.
Да, это хороший вариант, но на мобилках довольно трудно такое настроить.
Почему трудно?
Первый браузер, для обычных сайтов - какой-нибудь Soul, Vuvaldi. Для обходных путей - TorBrowser, WebShuttle. Ну и скрепный ЯндексБраузер, в который тоже можно воткнуть расширения для обхода.
На Андроиде у браузеров обычно нет параметров прокси в настройках, используются системные. Да и системные работают не всегда, поэтому все мобильные клиенты заворачивают трафик всех приложений в TUN, а потом уже разбираются.
Я это к тому, что сложностей нет.
Имея сейчас на борту мобилки этот набор браузеров - спокойно читаю статьи Хабра, отмеченные как 451, захожу на Рутрекеры, вижу стены в ВК, заблоканные для РФ.. Всё изкаропки или пара кликов для установки какого-нибудь расширения, типа NetHealer
А для прочих приложений, не браузеров - есть прекрасно работающий Orbot
С TorBrowser, WebShuttle и Orbot проблема та же, они пока работают, но блокировку по белым спискам протоколов, с чем недавно развлекался РКН, не переживут, как и некоторые другие возможные вещи.
Можно легче - взять v2rayng или nekobox, запустить там как vpn режим и выбрать приложухи, которые будут идти в обход или наоборот не в обход (в зависимости какой режим выберете). Всё, один браузер заворачиваем в обход, второй нет. Даже давно в клиенте wireguard такое появилось.
один браузер - для обычных сайтов через открытый И-нет, второй - для обходных путей
Есть вариант проще. Расширения для браузера вроде SmartProxy, которые запоминают на какие сайты трафик в прокси заворачивать. Так и с одним браузером не заметно, что существуют какие-то блокировки.
Del
хотел написать - неправильно вы бутерборд, дядя Федор, едите. Надо уеб-вать, а вы его колбасой к верху, но не напишу, потому что у важдого своя ситуация. Пичаль.
Полностью согласен. Я об этом тоже сказал в статье, в самом конце раздела с перечислением протоколов и технологий.
Хорошая статья. Может, я что-то не понял, может просто эта тема не рассматривалась как неоднородная. Вот что такое белые списки? Представим себе вы идете на некий хост, ваш ISP вам сообщил DNS резолвер, который резолвит вам имя в адрес и всё остальное понятно. DNS запросы по UDP идут отрытые, ТСПУ сверяет со своим разрешенным списком и если имя хоста не в списке - то может или заблокировать ответ, или подменить адрес в ответе. Это одна ситуация. Клиент может может использовать DoT протокол и запрос ответ не будут видны и правильный адрес будет доставлен. Но есть ведь и другая ситуация - корневой DNS находится под контролем, все DNS получают обновления только с него, и таким образом всё пространство имен содержит только разрешенные имена. Можно что угодно делать с запросом, но ответ не будет содержать правильный адрес, потому что его никто в этих сетях просто не знает. (если считаете такой сценарий невероятным - вспомните что они недавно подписали уже своим собственным ключем на своем корневом DNS и целый час гоняли и проверяли что и как отваливается, тут не до шуток, чебурнет уже включали - но это моя личная интерпретация, я не обладаю никаким инсайтом). Т.о. тут должна быть фича по поддержке надежного доступа к независимым резолверам и обновление этой информации.
В клиенте Amnezia есть опция поднять на VPN-сервере свой резолвер, или использовать внешние через тот же тоннель. Так что проблема сводится к VPN решению.
Почти все популярные клиенты на базе XRay и Sing-box используют не провайдерский DNS из свойств интерфейса, а какой-нибудь иностранный резолвер (обычно по умолчанию заданы 1.1.1.1, 8.8.8.8, 9.9.9.9), и отправляют запросы на него через прокси, как раз чтобы не зависеть от подконтрольных цензорам резолверов и не допустить подмену результатов
Видимо, я сформулировал недостаточно прозрачно. Ппонятно, что google, cloudflare и т.п. - первые в списке на явное блокирование при включении в режим чебурнета. И сам 53й порт становится критически важным, чтобы разрешался только по белым адресам. Поэтому, очевидно, критически важно чтобы VPN service discovery работало как-то по-другому. Отсюда и вопрос - есть ли такая фича, потому что только такие и имеют шанс выжить.
Так а в чем проблема подключаться к прокси/VPN сразу по IP-адресу, не используя DNS, а после подключения продолжать использовать те же гугловские DNS, обращаясь к ним через прокси/туннель?
Более того, предложенные в статье схемы именно так и работают. Кроме той, что с CDN, но и там ничего не мешает добавить пару записей в hosts-файл чтобы решить проблему.
Первый вариант - не работает на практике. Как только этот IP кто-то опубличит и им начнут пользоваться существенное количество пользователей, его заблокируют.
CDN - да примерно так и должно быть. Паша Дуров довольно долго бегал через CloudFront - суть тот же CDN (хотя и не только) и попробуй его заблокировать, а имена хостов в нем - дело сугобо личное и TLS-защищенное. Но сам CDN - если приложение его находит по именам, то нужен DNS, а его нет. В общем замкнутый круг курица-яйцо.
Схема, разрывающая этот порочный круг может выглядеть так -- актуальные адреса в большом количестве вшиваются в текущую версию дистрибутива и сидят в нем в зашифрованном виде. Приложение открывает первый блок используя встроенный ключ и начинает работать с адресами из него. Если получается, то оно получает ключ для расшифровки второго блока и этот ключ приходит из этих сервисов первого блока. Суть этих сервисов лишь проверить аутентичность приложения и выдать ключ для второго блока. А дальше второй блок - это уже endpoints сервисов выдачи актуальной новой версии приложения, где могут быть обновленные адреса, -- ее надо скачать и поставить если сейчас работает устаревшая версия. Дальше следующий ключ и следующий блок дает доступ к доменным именам, по которым находятся текущие endpoints VPN сервисов. Чем гибче схема, тем дольше ее разматывать и блокировать. Но я не видел где, кроме телеги, подобное реализовано. Впрочем, может быть Паша сподобится добавить и VPN в телегу.
Как только этот IP кто-то опубличит и им начнут пользоваться существенное количество пользователей
Так поэтому и не надо, чтобы сервером пользовалось много людей, уж тем более чтобы данные для подключения где-то открыто публиковались. Именно поэтому надо иметь свой сервер для себя и пары человек и никому об этом не говорить. Упомянутый VPN Generator работает, кстати, по той же схеме - 'каждому по серверу".
а имена хостов в нем - дело сугобо личное и TLS-защищенное.
Ага, щаз. Имена хостов даже в TLS 1.3 передаются в открытом виде. Есть ECH для их шифрования, но подключения с ним в России давно уже блокируются.
Но сам CDN - если приложение его находит по именам, то нужен DNS, а его нет
Если речь именно про CDN, то адреса фронтендов у популярных CDN обычно вполне известны, их можно собрать заранее.
суть тот же CDN (хотя и не только) и попробуй его заблокировать
Туркменистане заблокировали на изи, в Иране тоже справляются когда надо. Догадаетесь как или подсказать?
Но я не видел где, кроме телеги, подобное реализовано
Телега просто получала адреса новых прокси через пуши гугл-сервисов. Банить гугл-сервисы в тот момент РКН зассал.
Впрочем, может быть Паша сподобится добавить и VPN в телегу.
Очень сомнительно. Когда РКН воевал с Телегой, Паша потратил колоссальные деньги на это, долго бы он не продержался, ему повезло, что РКН сдался раньше. Сейчас у него с деньгами, судя по недавнему интервью, сильно лучше не стало, и ещё раз он ввязываться во все это точно не будет в здравом уме. Так что если ввяжется и это все будет работать, то это скажет только об одном - с ним обо всем договорились, и тогда использовать такой VPN будет явно небезопасно.
Я даже картинку в статью добавил, больно уж мысль правильная.
Как обходить блокировки с другой стороны, т.е. когда нас банят по российскому IP ? Мне бы найти способ попроще типа PlanetVPN (у меня он перестал работать) под Windows 7/10. Паре приложений нужен доступ для обновлений. Анонимность не интересует. Спасибо.
У способов попроще есть тот недостаток, что однажды они могут просто попасть под раздачу вместе с теми, кому анонимность нужна. Собственно, в статье об этом есть - OpenVPN уже банят.
Никак. Эти идиоты теперь ведут список регионов адресов интернет-провайдеров "последней мили". Арендовать VPS в России бесполезно, так как добавляют только адреса провайдеров, работающих с физлицами.
Более того, люто страдают российские абоненты мелких провайдеров, которые не могут на сайт налоговой и всякие госуслуги зайти, так как диапазона их провайдера нет в списке. В качестве решения предлагают абонентам звонить провайдеру, а провайдеру уже писать в Роскомнадзор, Ростелеком и Минцифры.
Так и живут - страдают, не работает, звонят друг-другу, чинят, потом адреса меняются и всё по новой. Плачут, но едят какутс.
В качестве хоть какого-то решения возможны только малинка или сервер на домашнем интернете.
С цель повышения градуса абсурда сейчас пытаются составить всероссийский список IP-адресов, чтобы "упорядочить" блокировки. Но, как вы понимаете, список составляют вручную (!!!), так как все эти ваши ASN и BGP, это богомерзкие западные изобретения, которым верить нельзя. В результате уже понятно, что совершенно неизбежно снова всё поломают, но теперь на уровне магистральных провайдеров. Опять будут звонить, вручную править списки, которые будут непрерывно устаревать, будут проблемы с распространением списков и тому подобное... короче, неизбежно станет хуже, но всем плевать и все заняты делом.
Дикари-с
Кстати, тут недавно всплыл очень забавный кейс с использованием VPN. Мне почту забанили в Google. Говорят робот. И не верят что человек. Почта новая. Но регестрировал я её через VPN, но номер указал российский...
Новые версии Openconnect умеет обходить active probing.
А для игр что лучше использовать?
Навыки эникейщик.
Условия карточка "Мир"
Без UI тяжело, тем более новичкам. Мне нравится X-UI. Легко настраивать, баги оперативно фиксятся.
Для тех, у кого есть иностранные карты или друзья, которые могут помочь с покупкой, хороший каталог-поисковик по VPSкам.
Сохранено как single-file html (включая часть 4, которую уже успели забанить). Спойлеры работают.
На 14 дней, не особо знаю куда сейчас нормально надолго залить можно.
На mega.nz
Ваша ссылка почему-то не открывается.
Можно на github/gitlab, если файлы не сильно большие.
Ещё можно сделать раздачу в торренте и шарить магнет-ссылку, вот это запретить только вместе с остальными торрентами получится
Этот коммент раньше был написан, чем автор статью дополнил и попросил пересохранить, имейте в виду
https://mega.nz/folder/c7sAARKb#k_erI9nbPP2Ziavndw17gg
Ссылка на мегу (с обновленным файлом)
Кстати, интересный вопрос: а как DPI соотносится с законом "О связи", который требует от операторов пропускать весь не запрещенный явно трафик без изменений? При этом самые гуманные в мире суды запрещают доступ к определенным сайтам/IP, но не пропуск пакетов, которые по чьему-то оценочному суждению могут использоваться для...
Автор жару дал конечно, + в карму за огромный объем работы. Вообще ряд популярных впн сервисов работает в направлении маскировки трафика, но пока их дождешься... готовь дрова летом что называется.
Спасибо за труд! Но можно же назвать как-то попроще без слова "блокировка". Типа "Инструменты для удаленного соединения между двумя офисами. Обзор современных решений."
Из каких соображений не приводятся бесплатные сервера с конфигами?
Первый раз про такие слышу. Как обычно, если что-то бесплатное, то кто-то за это заплатил. Либо энтузиасты (и нет вообще никаких гарантий, что оно будет работать стабильно и долго ли проработает), либо какие-то мутные личности в своих целях (сбор данных).
это я пытаюсь объяснить детям, когда они создают себе сети для игры в локалке через RAdmin.
А доблесные провайдеры, чтобы создать внутри города ВПН, не получается, горячий привет Фридому, что ИСЧ... Создал сервер впн на своем домашнем ip, с штатными или легко настраиваемыми в виндах впн-клиентами, чтобы не лепили горбатого на какой-то бесплатный сервис ВПН-сетей. Так всё, кроме этих бесплатных забугорных сервисов у клиентов зарезано. Тупо. Созванивался с их техподами - у нас ничего не заблокировано, проблема клиента.
Решения типа Tailscale/ZeroTier не гоняют через себя трафик если можно этого избежать, а если внутри города - прямые соединения (если получится пробить nat) - будут бодрыми. Если не получится пробить nat - ваш вариант решения будет быстрее (но обычно получается). Да и в целом, поиграть детям в локалке - ваше решение более чем достаточно
Хотя тут остается риск утечки метаинформации. Но есть и аналогичные селфхост-решения
Кто скачивал/сохранял статью - пересохраните еще раз! Был исправлен ряд серьезных ошибок и существенно дополнено содержание.
Действительно круто, что вы написали такую информативную и важную статью. Себе сохранил) Удачи автору, надеюсь, ваша работа найдет своих читателей и будет оценена по достоинству!
Спасибо большое автору! Собрал основное в одном месте и очень понятно разъяснил. Сохранил себе статью)
А что-нибудь насчет I2P сказать можете? Там те же проблемы что и у Tor?
Я их трафик не анализировал, но насколько я знаю, у них не ставится целью маскировка. Так что там один из трех вариантов, или у них протокол который фильтры могут опознать (по заголовкам, размерам пакетов, и т.д.), или у них там протокол ни на что не похожий (неплохо, но белые списки не переживет), или обычный TLS снаружи (тоже неплохо, но active probing)
А можно ли еще одного или нескольких user в config?
Уже недоступна - https://habr.com/ru/articles/728836/
с vpn достоупна
и автор MiraclePtr удален(
Нет же
Статьи написаны неким Deleted-user, доступ к профилю MiraclePtr закрыт. Надеюсь, у него самого всё хорошо.
Он разочаровался в местном сообществе, остатки обсуждения можно найти здесь - Новая блокировка OpenVPN и Wireguard замедляет интернет в России / Комментарии / Хабр (habr.com)
Сами комментарии MiraclePtr потёрты, но по ответам можно примерно догадаться, да и в кеше Bing пока ещё что-то сохранено.
Наверное сам попросил удалить, учитывая параноидальные дисклеймеры к каждой статье.
Для тех, кому, также как мне, лень вручную очищать такие полезные статьи, чтобы сохранить в PDF - написал bookmarklet - он оставит только статью и комментарии, а также раскроет все спойлеры - останется только отправить на печать в PDF-принтер.
Пользуйтесь на здоровье
javascript:(function(){( () => {document.querySelectorAll( "details" ).forEach( i => i.setAttribute( "open", "" ) ); const dels = [".tm-base-layout__header",".tm-header",".tm-page__sidebar",".tm-comment-form",".tm-block_spacing-bottom",".tm-comment-navigation",".tm-footer-menu",".tm-footer",".tm-article-sticky-panel",];let el;for ( const s of dels ) {const els = document.querySelectorAll( s );if ( els ) for ( el of els ) el.remove();}el = document.querySelector( ".tm-page__main" );el.style.maxWidth = "100%";} )()})()
Спасибо
Правда, например здесь спойлеры не раскрывает
У меня vless стал дисконнектиться в этом году каждые минут 10-20, хотя раньше работало стабильно сутками. Вряд ли это всё проживет долго, так что смысл сохранять в pdf вижу околонулевой.
Без подробного описания конфигурации (в том числе транспортов и расширений), используемых клиентов и логов клиента/сервера при дисконнекте, невозможно сказать, в чем у вас причина. Но если вы используете правильно настроенный VLESS, то она явно не в действиях РКН (у вас бы не отключалось каждые N минут, а не работало бы вообще).
Главное проверяйте внимательно, совсем дешевые VPS (за 7 долларов в год) могут не иметь публичного IPv4-адреса (только IPv6 и NAT-IPv6). Поставить и использовать прокси на них тоже можно (через Cloudflare CDN), но неопытным пользователям я бы в это ввязываться не советовал.
Что я видел - обычно самые душман решения имеют IPv6 и открытые несколько портов IPv4 (типа один IPv4 адрес на много клиентов), конечно нет 443 порта, но для некоторых целей сгодятся. Совсем нет статического IPv4 у "мейнстримовых" более дорогих/популярных провайдеров, но там прямая цель, "нужна виртуалка, IPv6 хватит". Кстати, как понимаю в цитате опечатка, NAT-IPv4 должно быть.
И кто-нибудь stunnel проверял? Я понимаю, что это HTTPS, но какой fingerprint, устойчивость к обнаружению?
обычно самые душман решения имеют IPv6 и открытые несколько портов IPv4 (типа один IPv4 адрес на много клиентов), конечно нет 443 порта, но для некоторых целей сгодятся
Да, все так. Там обычно дается IPv6-адрес или подсеть, и 10-20 портов на общем IPv4-адресе, и иногда еще SNI-прокси для всех на 443 порту. По идее на одном из этих портов можно поднять Shadowsocks или mKCP, через SNI-прокси можно даже использовать VLESS (но работают эти SNI-прокси обычно там хреново), но главная проблема в том, что из-за того что на одном адресе висит куча вируталок, стоит одному кому-то сделать что-то не то, так под блокировку попадет весь адрес.
Поэтому я бы предпочел, если нужен прокси, до таких виртуалок ходить по IPv6 или через Cloudflare, если у клиентов только IPv4 - тогда вполне можно пользоваться.
Отличная статейка, спасибо сохранил себе)
Это фундаментальный труд! Прям супер для тех, кто ещё не заскочил в последний вагон.
Ещё бы указать лицензии упомянутых продуктов. А то может оказаться что средство обхода блокировок написано под чутким руководством товарища майора, нашего или китайского, и вместо обхода мы генерируем себе готовое уголовное дело.
Участие либо неучастие какого-либо из майоров не зависит от лицензии продукта вообще никак. Код от майора может быть под GPL или MIT, код от энтузиаста Васи или Вэньмина без каких-либо закладок может быть под своей EULA.
А что до открытости и возможности аудита, у всех описанных серверных реализаций код открытый, у большинства клиентов тоже, за исключением клиентов под iOS. При наличии сомнений ничто не мешает собрать сервер и клиенты (кроме айфоновских, там все плохо) самостоятельно.
В текущих реалиях нужно зеркалить статьи в какой-нибудь Zeronet. Было бы классно иметь raw-статью со всеми тегами, чтобы хоть в ручном режиме в свой блог постить.
У кого-нибудь получилось завести ssh proxy в Streisand? У меня отображается как подключённый, но по факту не работает. Пробовал и с pubkey, и с password аутентификацией. При этом `ssh -D` с компа работает.
Ссылку вставляли, или вручную вводили реквизиты? Если ссылку, то попробуйте вручную, там всего четыре параметра.
У меня получилось завести. Был затык в том, что по умолчанию SSH сервер не разрешает туннелирование трафика. Чтобы разрешить, нужно на сервере в файле /etc/ssh/sshd_config добавить/заменить параметр AllowTcpForwarding yes.
У меня X-Ray не завёлся. Клиент к серверу подключается, а вот трафик от сервера дальше никуда не уходит. Не работает ни напрямую, ни через WARP.
Логи сервера
[Info] [4045738493] proxy/vless/inbound: firstLen = 1186
[Info] [4045738493] proxy/vless/inbound: received request for tcp:2ip.io:443
[Info] [4045738493] proxy: Xtls Unpadding new block, content 168 padding 950 command 0
[Info] [4045738493] proxy: XtlsFilterTls found tls client hello! 168
[Info] [4045738493] app/dispatcher: sniffed domain: 2ip.io
[Info] [4045738493] app/dispatcher: default route for tcp:2ip.io:443
[Info] [4045738493] proxy/dns: handling DNS traffic to tcp:2ip.io:443
188.242.236.180:50759 accepted tcp:2ip.io:443 [reality-in >> dns] email: darkdaskin
[Info] [4045738493] app/proxyman/outbound: failed to process outbound traffic > proxy/dns: connection ends > unexpected EOF
[Info] [4045738493] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > io: read/write on closed pipe
Попробовал поставить Amnezia, через неё трафик ходит нормально.
По логам видно, что клиент нормально подключается к серверу, проходит все проверки, и сервер понимает, что клиенту от него надо.
У вас он почему-то пытается еще трафик до самого 2ip.io (443 порт) переадресовать на встроенный DNS резолвер, возможно что-то не то с конфигом.
Попробуйте конфиг из текущей версии статьи, я еще утром убрал оттуда секцию "dns" и rule для него (53 порт), и также я убрал rule для geosite:google, потому что и на то и на то некоторые люди жаловались (но там ошибки другие были, и возможно связано с особенностями каких-то определенных клиентов).
На Гитхабе статью схороните дополнительно. Ну и правки там, обсуждение и всё такое
хотите, чтобы в России гитхаб заблокировали? :)
Уже было, правда, ненадолго. 10 лет назад РКН нашёл в каком-то репозитории файлик suicide.txt. Формально это действительно инструкция по самовыпилу, но способы там были из разряда «воспользуйся машиной времени, чтобы устранить себя в прошлом», и склонить кого-либо к деструктивным действиям оно явно неспособно.
Было бы отлично! Чем больше беZумия чинуш, тем больше саморазрушительных последствий для режима, и тем лучше.
Спасибо за идею. Надо заняться наполнением крупнейших git площадок всякой запрещённой информацией. Особенно инструкциями о VPN и прочем. Пусть роZкомпоZор всё блочит. Пусть стреляют себе по ногам. 😄
А уж айтишникам давно пора освоить все способы обхода блокировок. Время такое. Увы.
На моменте создания uuid установка не продвигается:
xray: command not found
Кому не сложно, можете объяснить, в чём заключается проблема? Все предыдущие шаги выполнил.
При выполнении команды надо находиться в той дире, где у вас лежит распакованный Xray. Ну и попробуйте выполнять команду добавляя в начало "./", то есть как "./xray"
Благодарю, помогло. Но возникла другая беда: systemctl status xray выдает ошибку xray.service: Failed with result 'exit‑code'.
Проверяю через journalctl -u xray — пишет infra/conf/serial: failed to read config: /opt/xray/config.json > open /opt/xray/config.json: no such file or directory, хотя такой файл есть и json проверен через валидатор.
Пробовал запустить через ./xray run /opt/xray/config.json, и он вроде бы показывает конкретную проблему: Failed to start: main: failed to load config files: [/opt/xray/config.json] > infra/conf: Failed to build REALITY config. > infra/conf: please fill in a valid value for "dest". Но параметр dest у меня назначен согласно инструкции. В общем, я в тупике.
Решил проблему. В dest и serverNames нужно указывать домен без протокола https. Возможно, стоит обозначить это в статье — вдруг кто-то столкнется с той же ошибкой.
Tip: трафик с виртуалок у российских говнопровайдеров не подвергается dpi, так что можно юзать для какой-нибудь инсты
У многих подвергается, и таких становится все больше и больше. См. тут: https://ntc.party/t/list-of-vpsdedicated-server-network-censorship-in-russia/4867
Понемногу заливаю статьи по обходам блокировок в IPFS: /ipns/k51qzi5uqu5dlerxnsvstxd80o2xq9h23rhews1ouk5eafyi4avabjxm37vy6e (или через gateway), ссылка если что постоянная. Попутно перевожу их в markdown, что чутка запарно и времязатратно, поэтому коллекция будет пополняться по мере появления свободного времени :) В планах залить туда все статьи MiraclePtr
Автору большое спасибо за компиляцию и статью. Уже настраивал ранее VLESS, но решил поэкспериментировать еще и столкнулся со странным: в базовой настройке с подменным доменом все коннектит и цепляет, но скорость не позволяет использовать такое соединение всерьез: дальше отрисовки хедеров страниц дело не идет, просто невероятно медленно. Хотя по логам пакеты бегают и все как будто бы работает
Кто-то отмечал такое поведение? Как лечить?
Использовать другой подменный домен, от него зависит скорость установления соединения (а при загрузке страниц браузер нередко устанавливает десятки соединений)
Включить на сервере bbr как написано в статье
Не, сам разобрался.
В первых версиях конфига из статьи в outbounds первым был выход на dns-out, а надо на freedom, они последовательно читаются.
Видимо, я начал раньше, чем были внесены правки. Поставил первым freedom, и все полетело.
Кстати, bbr не будет работать для виртуализации OpenVZ, на Ubuntu 20 просто нет таких модулей. Я пробовал доустановить, но тщетно
Сегодня пытался настроить по гайду автора прокси-сервер и у меня на моменте с клиентом все начинает сходить на нет, выдает разные ошибку по типу "tls: internal error" либо "i/o timeout", в документации к hidiffy и на github эти проблемы нормально не описаны и я совершенно без понятия как эти ошибки нормально отлавливать, на серверной стороне все хорошо.
Что значит "на серверной стороне все хорошо"? В логах на серверн видны какие-то попытки подключения или нет? От этого зависит куда дальше копать
Проверить, что вы настраиваете по текущей версии статьи, там вчера утром были внесены важные исправления в конфиги
Убедиться, что ссылка сгенерировалась правильно со всеми параметрами (можно вставить её в Nekoray/Nekobox, они ее разберут и покажут каждый параметр отдельно)
Убедиться, что на сервере не закрыт 443 порт фаерволом, и что вообще xray запущен и слушает порт
Убедиться, что на клиенте, если это десктоп, нет никакого антивирусного ПО, разбирающего TLS-трафик (таким точно грешит Аваст и Касперский, возможно и другие тоже)
Попробовать использовать другой чужой домен для маскировки, от этого многое зависит
В общем, штатные фокусы с VLESS и Shadowsocks проверил, работает.
А вот нештатные с Cloudflare (CF) так и не смог победить: не проходят запросы от клиента на сервер.
Кажется, какая-то ошибка в сборке строки подключения в статье. Кто-то еще это (вебсокет через CF) проверил, получилось?
Домен был, в его NS прописал у регистратора NS-cервера CF, в самой панели CF выполнил нужные настройки, все проверил несколько раз. Подождал письма от CF, в котором они говорят: можете использовать свой домен. Убедился, что при входе на него пропали ошибки вроде 500, 502, а возвращает 404 по https.
Собрал строку подключения, она валидна, Hiffify-Next пытается слать пакеты, но на сервере тишина, входящих нет.
Пока без идей, что не так.
Можно ещё попробовать браузером пойти на URL домена с секретной строкой - должен вернуть не 404, a Bad request.
Если сработает, то попробовать в ссылке в аргументе "path" оставить только секретную строку без спецсимволов и параметров (то есть не "/mysecret?ed=2048", а просто "mysecret") - можно проверить в Nekobox, что там сгенерилось. Можно наоборот, вбить в Nekobox все данные руками, сгенерить в нем ссылку (Share) и сравнить разницу
И переключить на сервере уровень логгирования в debug, чтобы видеть больше подробностей
Ещё варианты для теста: сходить CURL'ом с заголовками для вебсокет-подключений (в инете есть примеры) по этому урлу, убедиться что CF все правильно передает. На время для теста скорректировать ссылку, подключаться не через CF, а напрямую к вашему IP, на слушающий порт (не 443) и без TLS, то есть исключить из схемы CDN чтобы проверить.
Заработало. Помог совет засунуть ссылку в клиента Neko сначала и там сравнить с вашим скриншотом. Подправил по аналогии и получислось так: vless://uuid@domain.xyz:443?security=tls&sni=domain.xyz&fp=chrome&type=ws&path=/anypath?ed%3D2048&host=domain.xyz&encryption=none
И сразу заработало уже в Hiddify-Next
И да, квадратные скобки в listen конфига для IPv6 не нужны. Работает обычное указание адреса в кавычках
Спасибо, попробовал!
Если пойти в браузере на domain.xyz:443/?encryption=none&type=ws&sni=domain.xyz&host=domain.xyz&path=%2Fanypath%3Fed%3D2048&ed=2048&eh=Sec-Websocket-Protocol&security=tls&fp=chrome&security=tls&packetEncoding=xudp
, где значение anypath = anypath в серверном конфиге, то будет 404
И на domain.xyz:443/?encryption=none&type=ws&sni=domain.xyz&host=domain.xyz&path=%2Fanypath тоже 404
До Bad request не добираюсь
Пока меня смущает "listen": "[0000:0000:10:d::0000]" — точно в таком виде в конфиге IPv6 передаем? Зачем там эти квадратные, не фигурные, скобки? ))
Если пойти в браузере
Не, я имел в виду пойти браузером на https://vashdomain.com/anypath
Зачем там эти квадратные, не фигурные, скобки?
Это надо у разработчиков XRay спросить, а скорее у разработчиков стандартных библиотек в Go. Если ввести без скобок, он при старте будет ругаться на то что не может разобрать адрес и падать.
Можете проверить командой nestat -nlp на сервере, оно покажет, на каких адресах и портах какой процесс слушает
А как поживает I2P в плане устойчивости к блокировкам? Или из-за малого количества контента в этой сети проект так и останется тёмной пустой прослойкой.
Вот тут уже спрашивали
logs
14:34:41 [Info] proxy/vless/inbound: firstLen = 184
14:34:41 [Info] proxy/vless/inbound: received request for tcp:cp.cloudflare.com:80
14:34:41 [Info] proxy: Xtls Unpadding new block, content 76 padding 29 command 0
14:34:41 [Info] app/dispatcher: sniffed domain: cp.cloudflare.com
14:34:41 [Info] app/dispatcher: default route for tcp:cp.cloudflare.com:80
14:34:41 [Info] transport/internet/tcp: dialing TCP to tcp:cp.cloudflare.com:80
14:34:41 46.146.170.131:53111 accepted tcp:cp.cloudflare.com:80 [reality-in >> direct] email: user1
14:34:41 [Info] proxy/vless/inbound: firstLen = 1036
14:34:41 [Info] proxy/vless/inbound: received request for tcp:ipwho.is:443
14:34:41 [Info] proxy: Xtls Unpadding new block, content 247 padding 719 command 0
14:34:41 [Info] proxy: XtlsFilterTls found tls client hello! 247
14:34:41 [Info] app/dispatcher: sniffed domain: ipwho.is
14:34:41 [Info] app/dispatcher: default route for tcp:ipwho.is:443
14:34:41 [Info] transport/internet/tcp: dialing TCP to tcp:ipwho.is:443
14:34:41 46.146.170.131:53114 accepted tcp:ipwho.is:443 [reality-in >> direct] email: user1
14:34:41 [Info] proxy/freedom: connection opened to tcp:cp.cloudflare.com:80, local endpoint 77.238.227.150:53772, remote endpoint 104.16.132.229:80
14:34:41 [Info] proxy: XtlsPadding 756 126 0
14:34:42 [Info] proxy/freedom: connection opened to tcp:ipwho.is:443, local endpoint 77.238.227.150:44392, remote endpoint 5.188.158.161:443
14:34:42 [Info] proxy: XtlsFilterTls short server hello, tls 1.2 or older? 2896 70
14:34:42 [Info] proxy: XtlsFilterTls found tls 1.2! 2896
14:34:42 [Info] proxy: XtlsPadding 2896 214 0
14:34:42 [Info] proxy: XtlsPadding 378 1020 0
14:34:42 [Info] proxy: Xtls Unpadding new block, content 126 padding 952 command 0
14:34:42 [Info] proxy: XtlsPadding 258 847 0
14:34:42 [Info] proxy: Xtls Unpadding new block, content 159 padding 857 command 1
14:34:42 [Info] proxy: XtlsPadding 973 149 1
14:34:43 [Info] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > context canceled
14:34:51 [Info] proxy/vless/inbound: firstLen = 1117
14:34:51 [Info] proxy/vless/inbound: received request for tcp:u.myteam.vmailru.net:443
14:34:51 [Info] proxy: Xtls Unpadding new block, content 517 padding 518 command 0
14:34:51 [Info] proxy: XtlsFilterTls found tls client hello! 517
14:34:51 [Info] app/dispatcher: sniffed domain: u.myteam.vmailru.net
14:34:51 [Info] app/dispatcher: default route for tcp:u.myteam.vmailru.net:443
14:34:51 [Info] transport/internet/tcp: dialing TCP to tcp:u.myteam.vmailru.net:443
14:34:51 46.146.170.131:53126 accepted tcp:u.myteam.vmailru.net:443 [reality-in >> direct] email: user1
14:34:51 [Info] proxy/freedom: connection opened to tcp:u.myteam.vmailru.net:443, local endpoint <IP_server>:34750, remote endpoint <мой_IP>
14:34:51 [Info] proxy: XtlsFilterTls found tls 1.3! 4420 TLS_AES_256_GCM_SHA384
14:34:51 [Info] proxy: XtlsPadding 4420 92 0
14:34:51 [Info] proxy: Xtls Unpadding new block, content 80 padding 1286 command 0
14:34:51 [Info] proxy: Xtls Unpadding new block, content 92 padding 1133 command 2
14:34:51 [Info] proxy: CopyRawConn readv
14:34:51 [Info] proxy: XtlsPadding 684 622 2
14:34:51 [Info] proxy: CopyRawConn splice
Config
{
"log": {
"loglevel": "info"
},
"inbounds": [
{
"listen": "My IP",
"port": 443,
"protocol": "vless",
"tag": "reality-in",
"settings": {
"clients": [
{
"id": "мой_UUID",
"email": "user1",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "www.yahoo.com:443",
"xver": 0,
"serverNames": [
"www.yahoo.com"
],
"privateKey": "privateKey",
"minClientVer": "",
"maxClientVer": "",
"maxTimeDiff": 0,
"shortIds": [""]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
],
"routing": {
"rules": [
{
"type": "field",
"protocol": "bittorrent",
"outboundTag": "block"
}
],
"domainStrategy": "IPIfNonMatch"
}
}
Господа, уже поломал голову, но так и не заставил это работать.
В конфиге была проблема с блоком dns - его я сразу убрал - подключается.
Пробовал несколько доменов для маскировки: microsoft, oreilly, samsung, yahoo - результат один:
через Hiddify подключение выполняется, логи на сервере появляются и дальше ничего не происходит.
при попытке подключиться через NekoRay - вообще ничего не происходит.
Строка для подключения одинаковая
При этом 2ip.io как показывал мой реальный IP, так и показывает.
Это логи с клиента или с сервера?
У вас почему-то то ли клиент, то ли сервер отправляет все запросы сразу в direct (freedom). Если логи с сервера, то нужно видеть конфиг, чтобы понять, что там не так (уберите из него все сенситивные данные перед постингом)
это логи с сервера.
Конфиг под вторым спойлером :)
Короче говоря, в конфиге все нормально, в логах сервера тоже.
Вопрос - а запрос к 2ip.io в логах сервере-то видно? Проверьте после включения Hiddify в браузере и в системе настройки прокси - он должен выставить системный прокси-сервер в localhost, браузер должен использовать этот параметр по-умолчанию, но иногда бывает что в браузере стоит опция не использовать системный прокси.
Другой вариант - запускать Hiddify с правами администратора, и в настройках включить TUN-режим, но он менее стабилен
@UranusExplorer, спасибо большое. Отдельное спасибо за баланс между "хау-ту без пояснений" и "сейчас я устрою лекцию, как оно устроено, а как пользоваться, сами разберётесь".
Это был явный знак проапгрейдить стародавний shadowsocks, который я не трогал со времён битвы с телеграмом.
Завёл аккаунт у Оракла, создал бесплатную виртуалку (для тех, кто знает где взять "настоящую" visa/mastercard - рекомендую). А вот дальше начались боль и страдания большого энтерпрайза.
Во-первых, все входящие соединения у них запрещены, их надо разрешать в ДВУХ местах - во внешнем файрволе через веб-морду оракла и внутри виртуалки через iptables. (если делать невнимательно - теряется доступ по ssh. Хорошо, что не было ничего ценного...).
Во-вторых, внешний адрес и адрес внутри виртуалки - не одно и то же, там где-то по пути какой-то NAT стоит. При этом xray пишет в лог невразумительное cannot bind port. (я в итоге в конфиге xray указал inbounds / listen = 0.0.0.0, пусть все интерфейсы слушает, мне не жалко).
В-третьих, почему-то мне не повезло пару раз с доменом, используемом для маскировки. Т.е. curl -bla -bla успешно отдаёт страничку, а при подстановке этого в xray соединение не устанавливается (с какой-то мутной диагностикой). Это пока не решил, www.microsoft.com из примера работает. Если кто-то подскажет, как и куда смотреть, буду благодарен, метод тыка довольно долгий.
Во-вторых, внешний адрес и адрес внутри виртуалки - не одно и то же, там где-то по пути какой-то NAT стоит. При этом xray пишет в лог невразумительное cannot bind port
Я думаю в случае NAT в listen должен быть не внешний IP (у вас не будет интерфейса с ним), а внутренний (типа 10.x.x.x), а в ссылке наоборот будет внешний.
Я чайник...
добавил нового пользователя , но под ним нельзя редактировать файл config. Наверно надо как-то права новому пользователю расширить, а потом уже закрыть пользователя root?
Спасибо! Попробую
Спасибо, хорошая работа)
Спасибо за статью! Все давно настроено, но посмотрел, нет ли чего новенького)))
Не увидел, но очень важно:
В настройках Hiddify Next выберите "Активы маршрутизации" и регулярно обновляйте по трем точкам (2-3 раза в месяц точно обновляются).
Также, кому важно, протестировал все клиенты на Android TV / Google TV. Корректно работает только Hiddify Next. Правда стандартным пультом не зайти в настройки. Только включить и отключить. Покопаться в настройках и все сделать можно через AnyDesk, мышкой, управлением с телефона (кому как удобнее). Понравилось раздельное проксирование (Кинопоиск напрямую, а Prime и Netflix через сервер). Очень удобно.
Доброго дня.
Спасибо за мануал, все получилось с VLESS. Запрещенные сайты работаю, но обычные ходят без VLESS. А можно как-то заставить вообще весь трафик заворачивать в туннель? Клиент поставил Hiddify, подключаюсь в режиме VPN.
Спасибо большое за статью!
Сохранил в md через экстеншн из хрома и добавил в свой Obsidian. Так же как и все остальные статьи по теме.
У меня вопрос. Как в HiddifyNext подправить конфиг, чтобы в зоне RU нужные сайты шли через VPN? И наоборот, чтобы нужные зарубежные шли напрямую?
Огромная благодарность за статью.
Не могли бы Вы поделится чем то подобным или хотя бы ссылками на особенностях подъема VPN серверов на модных и дешевых сейчас VPS типа OpenVZ, LXC, .. Там местами большие трудности и в первую очередь с wireguard.
Да, на контейнерной виртуализации могут быть проблемы с WG, потому что он требует модуль ядра и требует tun-интерфейс. Первую проблему можно обойти использованием wireguard-go вместо обычного wireguard, вторую уже никак. Это относится ко всем VPN, для прокси (типа XRay) tun-интерфейс на сервере не нужен (если только вы не заворачиваетесь в warp)
Но wireguard в нынешних реалиях на территории РФ смысла использовать все меньше и меньше.
Здравствуйте. Я, что называется, чайник. Настраивал сервер через Windows PowerShell, однако больше не могу попасть на него таким же способом. При попытке войти выдает сообщение: "ssh: connect to host <IP сервера> port 22: Connection refused". В чем моя ошибка?
Спасибо за статью, сохранил. А пока пользуюсь goodbye dpi. Я так понял автор это называет HTTP Custom ? Минусы конечно есть, вроде того, что это вообще не анонимно, но вроде бы смертным пока и не запрещено заходить на заблокированные сайты.
Что касается статьи, хорошо бы добавить в список VPS, если такие существуют, с возможностью оплатить каким нибудь payeer.
Еще один нормальный клиент для iOS - V2Box. За несколько месяцев пользования серьезных проблем не встретил. Бесплатный, есть не слишком досаждающая реклама.
Отличная статья! Но стоит добавить, что у метода заворачивания всего не РУ сегмента есть уязвимость. Предположим, на устройстве включен клиент, пользователь с этого устройства заходит на любой гос. ресурс (те же госуслуги):
В верстке присутствует безобидный
<img src="//negosuslugi.com/pixel.jpg?tratata">, где tratata - это закодированная параuser_id;client_ip, а по user_id можно идентифицировать пользователяnegosuslugi.comхостится за пределами РФ, но подконтролен гос-вуВсё, что делает скрипт пикселя - сохраняет в базу
user_id, client_ip, proxy_ip, если client_ip != current_client_ip и current_client_ip не из РУ сегмента. А так как хостится этот пиксель за пределами РФ, то трафик пойдет через VPN и current_client_ip будет отличаться от client_ip из закодированной пары.
Таким нехитрым образом можно мало того, что собрать список ip адресов (VPN), но и установить кто пользуется VPN и за каким VPN сидит. Поэтому белые списки того, что заворачивается выглядят несколько безопаснее.
Поэтому белые списки того, что заворачивается выглядят несколько безопаснее.
Никто не мешает пользоваться разными VPN, часть из которых будет работать как раз только по белым спискам. Более того, цифровая гигиена подразумевает такой подход.
Верно. Однако в статье есть параграф о настройке клиентов, в котором есть абзац:
при первом запуске он предлагает выбрать страну, и если вы выберете Россию, то автоматически применятся правила, направляющие трафик до иностранных ресурсов через ваш прокси, а до российских сайтов — напрямую
И при такой конфигурации "из коробки" юзер будет подвержен описанной уязвимости. Из самого безобидного - потенциальный бан ip сервера РКН'ом.
В статье описан вариант заворачивания выходного трафика с прокси на warp, можно заворачивать не только для категорий geoip:ru, geosite:ru, geosite:category-gov-ru, а весь трафик (вместо ip/domain опции в правиле просто добавить ваш inboundTag). Тогда весь трафик, приходящий на прокси будет выходить в интернет уже с другого айпи-адреса, у цензоров будет виден только IP прокси, а на госуслугах и сервере-ловушке только IP WARP, и так просто сопоставить их уже не получится
Да уж... Рано обрадовался. Всë настроил, запустил клиент, подключение устанавливается, но доступа в Интернет нет.
Если кто-то может подсказать, что не так, буду премного благодарен:
Конфиг
{
"log": {
"loglevel": "info"
},
"inbounds": [
{
"port": 18882,
"protocol": "vless",
"tag": "kcp-in",
"settings": {
"clients": [
{
"id": "",
"email": "user1"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "kcp",
"kcpSettings": {
"mtu": 1350,
"tti": 20,
"uplinkCapacity": 10,
"downlinkCapacity": 20,
"congestion": false,
"readBufferSize": 1,
"writeBufferSize": 1,
"header": {
"type": "srtp"
},
"seed": ""
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
},
{
"listen": "",
"port": 443,
"protocol": "vless",
"tag": "reality-in",
"settings": {
"clients": [
{
"id": "",
"email": "user1",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "www.yahoo.com:443",
"xver": 0,
"serverNames": [
"www.yahoo.com"
],
"privateKey": "",
"minClientVer": "",
"maxClientVer": "",
"maxTimeDiff": 0,
"shortIds": [""]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
},
{
"port": 19222,
"tag": "ss-in",
"protocol": "shadowsocks",
"settings": {
"method": "2022-blake3-aes-128-gcm",
"password": "",
"network": "tcp,udp"
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
],
"outbounds": [
{
"protocol": "wireguard",
"tag": "warp",
"settings": {
"secretKey": "",
"address": [
"",
""
],
"peers": [
{
"endpoint": "",
"publicKey": ""
}
],
"mtu": 1280,
"reserved": "WPM9",
"workers": 2,
"domainStrategy": "ForceIP"
}
},
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
],
"routing": {
"rules": [
{
"type": "field",
"domain": ["geosite:openai", "geosite:category-gov-ru", "domain:ru"],
"outboundTag": "warp"
},
{
"type": "field",
"ip": ["geoip:ru"],
"outboundTag": "warp"
},
{
"type": "field",
"protocol": "bittorrent",
"outboundTag": "block"
}
],
"domainStrategy": "IPIfNonMatch"
}
}
v2rayNG при проверке соединения пишет: net/http:TLS handshake timeout
А в системном журнале Hiddify нашёл вот что:
9210): measureV2rayDelay: go.Universe$proxyerror: Get "https://cp.cloudflare.com/generate_204": net/http: TLS handshake timeout
Это как-то связано с WARP?
Не работает по всем протоколам, или по какому-то одному?
Исключайте шаг за шагом. Уберите сначала инбонд и правила для warp и посмотрите, что поменяется.
Кстати, у вас в конфиге варпа значение "reserved", такое же как в примере из статьи, "WPM9". Вы взяли конфиг варпа из статьи полностью (его уже могли заблокировать), или сгенерировали свой, но забыли изменить это поле?
Ну и да, важнее смотреть логи сервера, а не логи клиента - видны ли там вообще попытки подключения, на что ругается, и т.д.
Это как-то связано с WARP?
Не факт, на варп отправляюся только определенные запросы. То, что вы видите домен Cloudflare в логе - это просто его многие клиенты используют для теста связи
Upd: кстати, ещё заметил. Когда не подходит ни одно из правил в rules, XRay шлёт трафик на первый inbound. Поэтому WARP лучше передвинуть в конец списка, а первым пусть будет freedom.
Вы взяли конфиг варпа из статьи полностью (его уже могли заблокировать), или сгенерировали свой, но забыли изменить это поле?
Я сгенерировал данные через скрипт wgcf, но в конфиге для WireGuard не было строки «Reserved». Я заметил, что некоторые данные совпадают с Вашими, в частности publickey, ipv4, mtu, endpoint. Я подумал, что reserved тоже подойдёт (да и делать мне было особо нечего; в конфиге этого параметра попросту не было).
Сейчас проверю, если дело в WARP, попробую по-другому сгенерировать данные.
Если reserved не было, то скорее всего можно попробовать оставить его пустым в конфиге.
И да, попробуйте передвинуть warp в конец массива outbounds, чтобы первым был freedom, и временно убрать правила warp из routing rules.
Проблема всё-таки была в warp: убрал его из outbounds — и всё заработало. Видимо, параметр reserved был необходим для подключения. Буду искать способы, как сделать конфиг с ним.
UPD: переставил warp в конец outbounds — не работают российские сайты; поэтому да, проблема была в нём.
А вот сейчас не понял. Через mKCP почему-то warp работает. Почему он отказывается работать с xtls — для меня загадка.
А вот это странно. Клиент один и тот же используете? Можно ещё раз на текущий конфиг посмотреть?
Клиент тот же — v2rayNG. Конфиг тот же, что и в моëм первом комментарии, только outbound warp идёт после freedom.
UPD: Сейчас ещё раз проверил — через mKCP уже не работает. Странно, конечно.
Сгенерировал через NekoBox. Теперь всë работает. Огромная благодарность Вам — за статью и за помощь.
Еще хотелось бы узнать: если я не создавал нового пользователя, а только поменял порт для ssh, это ведь никак не отразится на работе? Всё равно к серверу нет доступа ни у кого, кроме меня.
Респект автору и тем кто схоронил.
Где почитать как настроить Streisand, он QR код из ссылки не читает, когда вручную вбиваешь он делает вид что подключается, но соединения нет.
Чтобы понять, почему подключения нет, надо смотреть логи сервера.
Ещё вариант - скормить ссылку более понятливому клиенту (я уж не знаю где именно вы в ссылке ошиблись) типа Nekoray, посмотреть как он ее распарсит, и сравнить данные в полях.
В том то и дело, клиент на Windows Hiddify отлично работает, туже строку пытаюсь скормить Streisand, он ее не хочет принимать. А в ручную вбиваю, он делает пишет коннект, но поля ip пустые, то есть по факту не коннект. FoXray тоже самое.
Посмотрел Nekoray, он выставляет Security TLS, а у меня было в Streisand, Reality. Поменял на TLS, но теперь из UI пропал пункт куда вводить Public Key... Ну и как итог ниче не подключается)
Не, тут все верно, это особенность Nekoray. У вас в ссылке security=reality, но Nekoray при парсинге таких ссылок ставит у себя "tls" (что логично, reality это его расширение), а использует или не использует в зависимости от наличия Pubkey в конфиге. Так что в Стрецзанде надо вернуть тип обратно на реалити.
Что видно в логах сервера, когда Стрейзанд пытается приконнектиться?
Кстати, появился ещё один клиент под айфоны (и кажется разработчики из наших), и первые отзывы очень неплохие: https://apps.apple.com/ru/app/v2raytun/id6476628951
Я логи не смотрел, вроде все заработало. Как раз тестирую приложение V2RayTun которое вы написали. Там даже роутинг легко настраивается. Спасибо. Кстати 2ip.io при проверки на анонимность говорит что у меня Defining tunnel (two way ping). Я так понял мне просто на сервер надо обрубить возможность пинговать его?
Короче какой-то бред. Сгенерил QR код из Nekoray, Streisand его понял и все заработало. Я еще раз посмотрел профили вручную и тот который вставился. Они полностью идентичные, но вручную не работает) П..ц
Но теперь не работает, если поставить галочку роутинга. Роутинг был загружен из этого поста первая ссылка.
Как-то сложно все. Может спросить - "GPT, как мне обойти блокировку?"
Спасибо за статью! Вроде всё понятно, буду пробовать.
Вопрос по хостеру VDSina - даёт ли он к серверу за 2 доллара IPv4 адрес или его придётся докупать отдельно за дополнительную плату? А ещё там пополнение счёта только от 20 долларов.
Спасибо за статью!
Попробовал настроить у себя, но что-то не выходит. Настраивал на двух разных серверах, сервера находятся у разных хостеров, но ошибка в логах везде одинаковая. Установку выполнял с помощью скрипта.
Подключаюсь с мобильного с помощью Hiddify‑Next. Подлючение происходит сразу, но интернет на устройстве после подключения не работает.
Конфиг
{
"log": {
"loglevel": "info",
"access": "/var/log/xray/access.log",
"error": "/var/log/xray/error.log"
},
"inbounds": [
{
"listen": "255.255.255.255",
"port": 443,
"protocol": "vless",
"tag": "reality-in",
"settings": {
"clients": [
{
"id": "xxxxxxxx",
"email": "user@example.com",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "www.asus.com:443",
"xver": 0,
"serverNames": [
"www.asus.com"
],
"privateKey": "yyyyyyyy",
"minClientVer": "",
"maxClientVer": "",
"maxTimeDiff": 0,
"shortIds": [""]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
],
"outbounds": [
{
"protocol": "dns",
"tag": "dns"
},
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
],
"routing": {
"rules": [
{
"type": "field",
"protocol": "bittorrent",
"outboundTag": "block"
}
],
"domainStrategy": "IPIfNonMatch"
}
}Лог
2024/03/18 17:53:30 [Debug] app/log: Logger started
2024/03/18 17:53:30 [Debug] app/proxyman/inbound: creating stream worker on 10.0.0.99:443
2024/03/18 17:53:30 [Info] transport/internet/tcp: listening TCP on 10.0.0.99:443
2024/03/18 17:53:30 [Warning] core: Xray 1.8.9 started
2024/03/18 17:53:45 [Info] transport/internet/tcp: REALITY: processed invalid connection
2024/03/18 17:53:45 [Info] transport/internet/tcp: REALITY: processed invalid connection
2024/03/18 17:53:45 [Info] transport/internet/tcp: REALITY: processed invalid connection
2024/03/18 17:53:46 [Info] transport/internet/tcp: REALITY: processed invalid connection
2024/03/18 17:53:46 [Info] transport/internet/tcp: REALITY: processed invalid connection
2024/03/18 17:53:46 [Info] transport/internet/tcp: REALITY: processed invalid connection
В чём может быть причина?
Уберите DNS inbound или переместите его в конец списка (в новом варианте статьи я его вообще убрал).
processed invalid connection означает, что что-то не то с конфигом reality (вероятно со стороны клиента). Может быть перепутаны private/public ключи или ещё что. Может быть вместо asus.com стоит попробовать использовать другой домен
Удалось решить проблему? Столкнулся с такой же ошибкой: processed invalid connection
DNS inbound был убран изначально.
processed invalid connection означает, что что-то не то с конфигом reality (вероятно со стороны клиента). Может быть перепутаны private/public ключи или ещё что. Может быть стоит попробовать использовать другой домен для маскировки
Пробовал делать и с microsoft. Пробовал пересоздавать uid и связку ключей. Всё равно выдаёт ошибку на сервере:
[Info] transport/internet/tcp: REALITY: processed invalid connection
Через Hiddify он пишет Timeout на главном окне, в журнале программы пишет:
inbound/mixed[mixed-in]: process connection from 127.0.0.1:64761: reality verification failed
Через NekoRay пробую запускать тесты, там ругается:
pp/proxyman/outbound: failed to process outbound traffic > proxy/vless/outbound: failed to find an available destination > common/retry: [REALITY: processed invalid connection] > common/retry: all retry attempts failed
Не пойму что я упускаю(
Конфиг
{
"log": {
"loglevel": "info"
},
"inbounds": [
{
"listen": "ip_моего_сервера",
"port": 443,
"protocol": "vless",
"tag": "reality-in",
"settings": {
"clients": [
{
"id": "мой_uid",
"email": "user1",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "www.microsoft.com:443",
"xver": 0,
"serverNames": [
"www.microsoft.com"
],
"privateKey": "Мой_приватный_ключ",
"minClientVer": "",
"maxClientVer": "",
"maxTimeDiff": 0,
"shortIds": [""]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
],
"routing": {
"rules": [
{
"type": "field",
"protocol": "bittorrent",
"outboundTag": "block"
}
],
"domainStrategy": "IPIfNonMatch"
}
}
В моё случае проблема решилась, когда на клиенте я поменял адрес сайта с microsoft.com на www.microsoft.com
Оказывается эти параметры должны быть максимально одинаковыми и на сервере и на клиенте. В примере статьи было указано без www и меня это сбило с толку)
Спасибо за статью, продолжу дальше настраивать)
Пробема в моём случае решилось заменой dest и serverNames в конфиге. При указании www.asus.com получал processed invalid connection . Выбрал microsoft и сразу всё заработало. Сейчас заменил на свой собственный сайт.
Благодарю за статью, великолепно.
А есть ли клиенты для windows, которые бы оборачивали полностью весь трафик в этот прокси? Потому что Hiddify‑Next и nekoray в режиме vpn/tun пропускают например трафик телеги или торрент клиентов. Браузер идет через прокси, но хотелось бы чтобы шел весь трафик системы. Или это невозможно реализовать?
Nekoray в режиме TUN точно заворачивает на прокси весь трафик, в том числе телегу и торренты, это проверено неоднократно. Вы что-то не так делаете.
P.S. Касательно торрентов, некоторые слишком умные клиенты типа qBittorrent выбирают неправильный сетевой интерфейс для работы, наплевав на дефолтные маршруты и метрики интерфейсов в системе. Это можно проверить там в настройках, какой именно интерфейс оно исаользует. Но я не видел, чтобы таким страдала телега, у меня в офисе телега заблоктрована, и я в ней сижу именно через Nekoray без проблем.
Объясните пожалуйста подробнее про эти настройки
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
Оно активирует BBR congestion control
Я читал, что первая версия BBR имеет негативный побочный эффект в виде агрессивного перетягивания одеяла на себя с других методов. В следующей версии это доработали, но в Linux на данный момент входит именно первая. Насколько важно и нужно её включать? Что это даст и какие будут минусы? Если BBR это так круто, как описывают в статьях, то почему по-умолчанию оно выключено?
А как настроить клиент чтоб он торренты тоже не проксировал?
Зависит от конкретного торрент-клиента, мы же не знаем, чем вы там пользуетесь.
Если вы не используете TUN-режим, то в торрент-клиенте надо прописать локальный прокси.
Если вы используете TUN-режим, то в торрент-клиенте надо выбрать соответствующий системный сетевой интерфейс.
В каждом клиенте это настраивается по-разному.
Любители VLESS, объясните почему этот протокол уже два года как
WARNING
VLESS is deprecated and subject to removal.
Please consider using the Trojan protocol as a replacement for new deployments.
Отличная статья! Спасибо!
Настроил всё, используя панель панель 3X-UI. Также добавил ко всему VLESS-gRPC через CloudFlare. С панелью гораздо удобнее, конечно, если по умному настроить.
Несколько дней пытаюсь настроить VLESS c XTLS-Reality, но сервис не стартует. Имеется VPS с ограниченным диапазоном портов. Устанавливал и скриптом и врусную.
конфиг
{
"log": {
"loglevel": "info"
},
"inbounds": [
{
"listen": "ххх.ххх.ххх.ххх",
"port": 14414,
"protocol": "vless",
"tag": "reality-in",
"settings": {
"clients": [
{
"id": "bafb29bc-0911-45c8-8ec6-9102ff2dcd3e",
"email": "user1",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "www.microsoft.com:14414",
"xver": 0,
"serverNames": [
"www.microsoft.com"
],
"privateKey": "WGorELK2TcGAdqSgvPVN4EuqrFlKcipES_0ncAF7m3A",
"minClientVer": "",
"maxClientVer": "",
"maxTimeDiff": 0,
"shortIds": [""]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
],
"routing": {
"rules": [
{
"type": "field",
"protocol": "bittorrent",
"outboundTag": "block"
}
],
"domainStrategy": "IPIfNonMatch"
}
}
лог
● xray.service – Xray
Loaded: loaded (/etc/systemd/system/xray.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/xray.service.d
└─10-donot_touch_single_conf.conf
Active: activating (auto-restart) (Result: exit-code) since Fri 2024-03-22 12:06:48 GMT; 28s ago
Process: 2345 ExecStart=/usr/local/bin/xray run -config /usr/local/etc/xray/config.json (code=exited, status=255)
Main PID: 2345 (code=exited, status=255)
Mar 22 12:06:48 antiputin.gullo.me systemd[1]: xray.service: main process exited, code=exited, status=255/n/a
Mar 22 12:06:48 antiputin.gullo.me xray[2345]: Failed to start: app/proxyman/inbound: failed to listen TCP on 14...dress
Mar 22 12:06:48 antiputin.gullo.me systemd[1]: Unit xray.service entered failed state.
Mar 22 12:06:48 antiputin.gullo.me systemd[1]: xray.service failed.
Подскажите, плз, куда копать?
Копать в сторону других протоколов (Shadowsocks, mKCP). XTLS-Reality (как и все остальное, что поверх TLS) должно работать всегда только и только на 443 порту. Иначе это множит на ноль всю маскировку, это то же самое как встать с табличкой "смотрите, смотрите, я - подозрительный тип!".
Конкретно в вашем случае проблемы две, или занят порт 14414, или вы задали неправильный IP-адрес (если вы за NAT'ом, то должен быть локальный адрес, обычно типа 10.x.x.x), это видно по сообщению "failed to listen"
А когда он запустится, то скорее всего не заработает из-за "dest": "www.microsoft.com:14414" - сервер microsoft.com не слушает на 14414 порту, он слушает на 443. Исправьте в этой строке 14414 на 443 и все заработает, но, как , уже говорил, такая схема довольно сомнительная (хотя можно рассчитывать на эффект Неуловимого Джо)
Попытка с Shadowsocks, к сожалению, тоже неудачная((
Конфиг
GNU nano 7.2 /etc/shadowsocks-libev/config.json {
"server":["::1", "ххх.ххх.ххх.ххх"],
"mode":"tcp_and_udp",
"server_port":14402,
"local_port":1080,
"password":"rvJEyvyWv7Sd",
"timeout":86400,
"method":"chacha20-ietf-poly1305"
}
Лог
× shadowsocks-libev.service - Shadowsocks-libev Default Server Service
Loaded: loaded (/lib/systemd/system/shadowsocks-libev.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Mon 2024-03-25 09:56:58 CET; 3s ago
Duration: 13ms
Docs: man:shadowsocks-libev(8)
Process: 1980 ExecStart=/usr/bin/ss-server -c $CONFFILE $DAEMON_ARGS (code=exited, status=255/EXCEPTION)
Main PID: 1980 (code=exited, status=255/EXCEPTION)
Mar 25 09:56:58 antiputin.gullo.me systemd[1]: Started shadowsocks-libev.service - Shadowsocks-libev Default Server Service.
Mar 25 09:56:58 antiputin.gullo.me ss-server[1980]: 2024-03-25 09:56:58 INFO: UDP relay enabled
Mar 25 09:56:58 antiputin.gullo.me ss-server[1980]: 2024-03-25 09:56:58 INFO: initializing ciphers... chacha20-ietf-poly1305
Mar 25 09:56:58 antiputin.gullo.me ss-server[1980]: 2024-03-25 09:56:58 INFO: tcp server listening at [::1]:14402
Mar 25 09:56:58 antiputin.gullo.me ss-server[1980]: 2024-03-25 09:56:58 INFO: tcp server listening at 144.76.97.102:14402
Mar 25 09:56:58 antiputin.gullo.me ss-server[1980]: 2024-03-25 09:56:58 ERROR: bind: Cannot assign requested address
Mar 25 09:56:58 antiputin.gullo.me ss-server[1980]: 2024-03-25 09:56:58 ERROR: failed to bind address
Mar 25 09:56:58 antiputin.gullo.me systemd[1]: shadowsocks-libev.service: Main process exited, code=exited, status=255/EXCEPTION
Mar 25 09:56:58 antiputin.gullo.me systemd[1]: shadowsocks-libev.service: Failed with result 'exit-code'.
mKCP: я так понимаю не может считать конфиг. Но почему?
конфиг
/opt/xray/config.json
{
"log": {
"loglevel": "info"
},
"inbounds": [
{
"port": 14400,,
"protocol": "vless",
"tag": "kcp-in",
"settings": {
"clients": [
{
"id": "d6be3310-81e3-4904-b40d-8ad7d33ab431",
"email": "user1"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "kcp",
"kcpSettings": {
"mtu": 1350,
"tti": 20,
"uplinkCapacity": 10,
"downlinkCapacity": 20,
"congestion": false,
"readBufferSize": 1,
"writeBufferSize": 1,
"header": {
"type": "WebRTC"
},
"seed": "bhyBYGbjkuVYXJ1cyEhIQ"
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
]
}
},
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
],
"routing": {
"rules": [
{
"type": "field",
"protocol": "bittorrent",
"tag": "block"
}
],
"domainStrategy": "IPIfNonMatch"
}
}
статус
● xray.service - XRay
Loaded: loaded (/lib/systemd/system/xray.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Mon 2024-03-25 12:05:32 UTC; 2s ago
Process: 9743 ExecStart=/opt/xray/xray run -c /opt/xray/config.json (code=exited, status=23)
Main PID: 9743 (code=exited, status=23)
Mar 25 12:05:32 antiputin.gullo.me xray[9743]: A unified platform for anti-censorship.
Mar 25 12:05:32 antiputin.gullo.me xray[9743]: Failed to start: main: failed to load config files: [/opt/xray/config.json] > infra/conf/serial: failed to decod>
Mar 25 12:05:32 antiputin.gullo.me systemd[1]: xray.service: Main process exited, code=exited, status=23/n/a
Mar 25 12:05:32 antiputin.gullo.me systemd[1]: xray.service: Failed with result 'exit-code'.
Здесь у вас ровно так же самая ошибка, что и с VLESS.
ERROR: failed to bind address
Убедитесь, что вы вводитев конфиге IP-адрес реально существующий среди системных сетевых интерфейсов (можно посмотреть командой IP addr).
Кстати, для Shadowsocks не обязательно было ставить shadowsocks-libev (его разработка прекращена, он больше не развивается), XRay умеет в него не хуже.
А вот такой вопрос. При настройке VLESS с XTLS-Reality включается маскировка под другой сайт. Но разве нельзя получить список адресов этого сайта и увидеть, что нашего IP в списке нет? Тем же curl, который вы советуете использовать для проверки сайта. Он в начале пишет:
>curl -v -L --tlsv1.3 --http2 -s https://yahoo.com
Host yahoo.com:443 was resolved.
IPv6: (none)
IPv4: 74.6.231.21, 74.6.143.26, 98.137.11.164, 74.6.143.25, 98.137.11.163, 74.6.231.20
Trying 74.6.231.21:443...
Connected to yahoo.com (74.6.231.21) port 443
Настроил VLESS+XTLS-Reality, вроде работает, curl выдаёт страничку маскировочного сервера. Но в выводе RealiTLScanner мой сервер не появился, что-то не так?
"можно сгенерировать его командой openssl rand -base64 16"
Там бинарный выхлоп, xray нужен текстовый.
Ну и стоило бы явно написать какие порты нужно открывать, при наличии файервола на сервере.
Кстати, 21 марта Хабр по требованию Роскомнадзора был вынужден заблокировать доступ к этой статьи с территории РФ. Ура товарищи!
MiraclePtr рассказывал не просто сложный вариант с CDN, а как подключится к Reality через CDN, используя nginx. У вас же просто VLESS (без Reality) через CDN. Может быть копнёте глубже и раскроете тему подключения к Reality через CDN?
Невозможно подключиться к Reality через CDN. Просто невозможно, для Reality нужно чтобы TLS-сессия теосинировалась на XRay, а в случае с CDN она терминируеься на фронтендах самой CDN. У MiraclePtr в статьях описывалась схема, когда reality-подключения шли напрямую к серверу, а не-reality подключения шли через CDN. Nginx там использовался для разруливания прямых- и CDN-подключений по SNI, чтобы повесить на CDN какой-нибудь веб-сайт с котиками.
Хмм, возможно я неправильно понял. Вот его прямая цитата "Обратите внимание: если у вас на сервере настроен XTLS-Reality, то черезWebsocket/gRPC подĸлючаться ĸ нему нужно тольĸо через CDN!" Разве из неё не следует, что к Reality можно подключится через CDN? То есть будем подключаться к Reality не через IP VPS, а через адрес домена (CDN CF, например). То есть к Reality можно будет подключиться, даже если IP VPS попал в бан.
Я имел в виду, что если на сервере настроен Reality, то второе (вебсокетное) подключение должно идти только через CDN, но не напрямую. Иначе цензоры увидят у вас на IP-адресе сразу два SNI, одно от какого-нибудь microsoft.com, а другое от вашего неизвестного домена, и это будет очень подозрительно.
То есть вы пользуетесь XTLS-Reality, а если ваш сервер попал в бан, то все равно можете подключаться к нему через CDN через обычный VLESS (но уже без Reality, Reality через CDN работать не может). В статье описана эта схема, MiraclePtr писал тоже о подобном.
Спасибо за разъяснение. Грустно, конечно. Казалось, что MiraclePtr нашёл способ совместить CDN и Reality :(
А какая цель? Если вам надо на одном сервере использовать и Reality и подключаться через CDN со своим доменом, то это легко можно сделать как описано в статье.
Если вам надо подключаться через CDN прикрываясь чужим доменом, то у MiraclePtr есть статья про domain fronting - это не Reality, но суть похожа. Правда, он там же писал, что сейчас все меньше и меньше CDN разрешают фронтинг, вроде как всеми любимый для этого дела Fastly его недавно собирался запретить
Отличная статья, настроил себе xtls-reality с маскировкой под небольшой сайтик на nginx
Правда похоже что nekoray неправильно понимает параметры mKCP, с ним он ни в какую не заработал. А вот по той же самой ссылке v2rayNG на андроиде — работает
Ибо в логах на сервере такое:
transport/internet/kcp: discarding invalid payload from udp:<IP>:44139
Низкий поклон за статью. К сожалению, не хватает репы отлайкать по достоинству) Настроила вот по этому пункту: Просто: Настройка VLESS c XTLS-Reality. Hiddify-next на андроиде работает отлично, а вот под линуксом не работает совсем (та же ссылка, тот же клиент). В какую сторону можно копнуть? Я не полный чайник, но близко к тому, прошу помочь)
А что значит "не работает совсем"? Не запускается приложение? После установления подключения перестает работать интернет? После установления подключения все открывается как открывалось раньше, а не через прокси? Или что?
Ну и да, интересно будет ещё посмотреть на логи клиента и сервера в момент попыток подключения
Приложение запускается, делает вид, что подключено, но санкционные сайты не открываются. Остальной ру интернет работает как обычно. В настройках стоит регион Россия. Причем уже на двух ПК с Линукс попробовала - ситуация такая же. И в том числе пробовала, как в статье указано, отключиться и подключиться повторно, не помогло. Логи попробую добыть чуть позже, я ведь почти чайник)
Из того, что удалось найти:
app.log
Memory Limit: false
18:47:14.399073 - [D] ConnectionRepositoryImpl: setting up singbox
18:47:14.460605 - [D] FFISingboxService: starting, memory limit: [false]
18:47:14.465909 - [I] ConnectionNotifier: connection status: CONNECTING
18:47:14.471054 - [D] SystemTrayNotifier: updating system tray
18:47:15.624016 - [I] ConnectionNotifier: connection status: CONNECTED
18:47:15.624434 - [D] IpInfoNotifier: disposing
18:47:15.624753 - [D] ProxyRepositoryImpl: getting current ip info using [https://ipwho.is/]
18:47:15.624922 - [D] FFISingboxService: singbox native libs path: "libcore.so"
18:47:15.626902 - [D] SystemTrayNotifier: updating system tray
18:47:22.791998 - [D] LogsOverviewNotifier: resuming
18:47:24.080049 - [D] SettingsRepositoryImpl: checking battery optimization status
18:47:24.083425 - [D] PreferencesEntry<PerAppProxyMode, String>: getting persisted preference per_app_proxy_mode
18:47:24.111240 - [D] LogsOverviewNotifier: pausing
18:47:26.160426 - [D] SettingsRepositoryImpl: checking battery optimization status
18:47:26.977079 - [D] IpInfoNotifier: entering idle mode
18:47:26.977254 - [D] IpInfoNotifier: disposing
18:47:44.112415 - [D] LogsOverviewNotifier: disposing
18:48:48.324466 - [D] LogsOverviewNotifier: adding listeners
box.log - вообще пусто
Не подскажете, где и как еще можно посмотреть?
+ box.log
Hidden text
+0300 2024-03-30 20:03:02 INFO router: Hiddify!notifyNetworkUpdate 1
+0300 2024-03-30 20:03:02 INFO router: updated default interface wlan0, index 3
+0300 2024-03-30 20:03:02 INFO router: loaded geoip database: 250 codes
+0300 2024-03-30 20:03:02 INFO clash-api: restful api listening at 127.0.0.1:6756
+0300 2024-03-30 20:03:02 INFO inbound/mixed[mixed-in]: tcp server started at 127.0.0.1:2334
+0300 2024-03-30 20:03:02 INFO inbound/direct[dns-in]: tcp server started at 127.0.0.1:6450
+0300 2024-03-30 20:03:02 INFO inbound/direct[dns-in]: udp server started at 127.0.0.1:6450
+0300 2024-03-30 20:03:02 INFO sing-box started (0.199s)
+0300 2024-03-30 20:03:02 INFO outbound/vless[vless § 0]: outbound connection to cp.cloudflare.com:80
+0300 2024-03-30 20:03:02 INFO [2158745755 0ms] inbound/mixed[mixed-in]: inbound connection from 127.0.0.1:39718
+0300 2024-03-30 20:03:02 INFO [2158745755 1ms] inbound/mixed[mixed-in]: inbound connection to ipwho.is:443
+0300 2024-03-30 20:03:02 DEBUG [2158745755 3ms] router: sniffed protocol: tls, domain: ipwho.is
+0300 2024-03-30 20:03:02 INFO [2158745755 4ms] outbound/vless[vless § 0]: outbound connection to ipwho.is:443
+0300 2024-03-30 20:03:02 INFO outbound/vless[vless § 0]: outbound connection to cp.cloudflare.com:80
+0300 2024-03-30 20:03:02 INFO [2158745755 215ms] outbound/vless[vless § 0]: outbound connection to ipwho.is:443
+0300 2024-03-30 20:03:03 DEBUG outbound/urltest[auto]: outbound vless § 0 available: 254ms
+0300 2024-03-30 20:03:48 INFO router: Hiddify!notifyNetworkUpdate 1
+0300 2024-03-30 20:03:48 INFO router: updated default interface wlan0, index 3
+0300 2024-03-30 20:03:48 INFO router: loaded geoip database: 250 codes
+0300 2024-03-30 20:03:48 INFO clash-api: restful api listening at 127.0.0.1:6756
+0300 2024-03-30 20:03:48 INFO inbound/mixed[mixed-in]: tcp server started at 127.0.0.1:2334
+0300 2024-03-30 20:03:48 INFO inbound/direct[dns-in]: tcp server started at 127.0.0.1:6450
+0300 2024-03-30 20:03:48 INFO inbound/direct[dns-in]: udp server started at 127.0.0.1:6450
+0300 2024-03-30 20:03:48 INFO sing-box started (0.188s)
+0300 2024-03-30 20:03:48 INFO outbound/vless[vless § 0]: outbound connection to cp.cloudflare.com:80
+0300 2024-03-30 20:03:48 INFO [504311486 0ms] inbound/mixed[mixed-in]: inbound connection from 127.0.0.1:36310
+0300 2024-03-30 20:03:48 INFO [504311486 0ms] inbound/mixed[mixed-in]: inbound connection to ipwho.is:443
+0300 2024-03-30 20:03:48 DEBUG [504311486 1ms] router: sniffed protocol: tls, domain: ipwho.is
+0300 2024-03-30 20:03:48 INFO [504311486 1ms] outbound/vless[vless § 0]: outbound connection to ipwho.is:443
+0300 2024-03-30 20:03:48 INFO outbound/vless[vless § 0]: outbound connection to cp.cloudflare.com:80
+0300 2024-03-30 20:03:48 TRACE outbound/vless[vless § 0]: XtlsPadding 76 223 0
+0300 2024-03-30 20:03:48 INFO [504311486 595ms] outbound/vless[vless § 0]: outbound connection to ipwho.is:443
+0300 2024-03-30 20:03:48 TRACE outbound/vless[vless § 0]: XtlsFilterTls found tls client hello! 247
+0300 2024-03-30 20:03:48 TRACE outbound/vless[vless § 0]: XtlsPadding 247 736 0
+0300 2024-03-30 20:03:49 TRACE outbound/vless[vless § 0]: Xtls Unpadding new block 21 772 padding 235 0
+0300 2024-03-30 20:03:49 DEBUG outbound/urltest[auto]: outbound vless § 0 available: 163ms
+0300 2024-03-30 20:03:49 TRACE outbound/vless[vless § 0]: Xtls Unpadding new block 21 3864 padding 253 0
+0300 2024-03-30 20:03:49 TRACE outbound/vless[vless § 0]: XtlsFilterTls short server hello, tls 1.2 or older? 1163 70
+0300 2024-03-30 20:03:49 TRACE outbound/vless[vless § 0]: XtlsFilterTls found tls 1.2! 1163
+0300 2024-03-30 20:03:49 TRACE outbound/vless[vless § 0]: Xtls Unpadding new block 5 491 padding 890 0
+0300 2024-03-30 20:03:49 TRACE outbound/vless[vless § 0]: XtlsPadding 126 1212 0
+0300 2024-03-30 20:03:49 TRACE outbound/vless[vless § 0]: Xtls Unpadding new block 5 258 padding 1119 0
+0300 2024-03-30 20:03:49 TRACE outbound/vless[vless § 0]: XtlsPadding 155 921 1
+0300 2024-03-30 20:03:49 TRACE outbound/vless[vless § 0]: Xtls Unpadding new block 5 978 padding 1 1
+0300 2024-03-30 20:03:52 DEBUG [504311486 4.47s] inbound/mixed[mixed-in]: connection closed: process connection from 127.0.0.1:36310: download: read tcp 192.168.100.13:58400->xxx.xxx.xxx.xxx:443: use of closed network connection | upload: raw-read tcp 127.0.0.1:2334->127.0.0.1:36310: use of closed network connection | upstream: context canceled
+0300 2024-03-30 20:04:05 INFO router: Hiddify!notifyNetworkUpdate 1
+0300 2024-03-30 20:04:05 INFO router: updated default interface wlan0, index 3
+0300 2024-03-30 20:04:05 INFO router: loaded geoip database: 250 codes
+0300 2024-03-30 20:04:05 INFO clash-api: restful api listening at 127.0.0.1:6756
+0300 2024-03-30 20:04:05 INFO inbound/mixed[mixed-in]: tcp server started at 127.0.0.1:2334
+0300 2024-03-30 20:04:05 INFO inbound/direct[dns-in]: tcp server started at 127.0.0.1:6450
+0300 2024-03-30 20:04:05 INFO inbound/direct[dns-in]: udp server started at 127.0.0.1:6450
+0300 2024-03-30 20:04:05 INFO sing-box started (0.177s)
Ну и дальше уже такие же однотипные записи.
В общем, и hiddify, и nekoray на ПК в режиме системного прокси не завелись, работают только в режиме tun/vpn, что не очень удобно, т.к. запускать нужно под админом. Пока не понимаю, почему так. И, главное, какие последствия могут быть при использовании этого варианта.
Проверьте, что у вас в браузере в настройках стоит опция "использовать системный прокси", скорее всего дело в этом.
Последствий никаких.
По идее и chrome, и brave по умолчанию используют системный прокси. Но настройка не открывается, т.к. нет для нее gui. Это те два браузера, что изначально пыталась использовать.
Поставила дополнительно firefox, в настройках эта опция стоит. Hiddify в режиме системного прокси так и не завелся, а вот nekoray работает.
Ну а хром, как уже писала ранее, только в режиме tun/vpn как в hiddify, так и в nekoray. Пока не могу победить. Гугл подсказывает, что прокси нужно явно задать в переменных окружения, но что-то не понимаю, что туда вписывать в контексте используемых клиентов. Не адрес же своего сервера писать. Или да?
Странно. У вас точно обычный Хром? Потому что в моем Хроме под Linux, помнится, настройки прокси были в GUI.
Точно обычный хром, но использую голый оконный менеджер без DE. А гуи обычно как часть окружения идут. И при попытке открыть настройки прокси хром пишет:
При работе Google Chrome в поддерживаемой среде на компьютере используются системные настройки прокси-сервера. Однако либо ваша система не поддерживается, либо возникли неполадки при запуске системной конфигурации.
Но вы все же можете выполнить конфигурацию с помощью командной строки. Подробнее о флагах и переменных окружения вы можете узнать в
руководстве к google-chrome.
Я попробовала из терминала запустить с флагами --proxy-server="мой сервер", но так тоже не завелось.
Разумеется не заведется, на вашем сервере никакого стандартного прокси нет, иначе бы смысла в xray не было. А подключаться надо к локалхосту, где клиент поднимет локальный socks5 прокси для использования софтом. По аналогии как tor на порту 9050 его поднимает.
А как прописывать — смотрите мой комментарий ниже.
Если используете hiddify, то для хрома аргумент --proxy-server="socks5://localhost:2334"
Для Firefox просто в настройках прокси тип socks5, локалхост и порт 2334. И поставить галочку на проксирование DNS.
Спасибо за статью! К сожалению не могу поставить плюс.
Статью сразу прочитал, пошел покупать VPS и пробовать настроить.
Сам я не айтишник, никогда до этого не имел опыта с удаленными серверами, никогда в глаза не видел Debian и линукс. Мне было сложно разобраться с нуля, но я смог запустить Xray и VLESS. Это заработало.
Но не я не могу добавть Shadow Socks, в конфиге из статьи есть ошибка....
Вот что пишет валидатор:
Ошибка
Если убарать запятую перед "]" квадратной скобкой, то скрипт валидацию проходит. Но если я вставляю этот скрипт в конфиг /usr/local/etc/xray/config.json , Shadow Socks на сервере не запускается.
При рестарте xray ругается на: infra/conf: invalid field rule > infra/conf: neither outboundTag nor balancerTag is specified in routing rule
Ошибка SS
× xray.service - Xray Service
Loaded: loaded (/etc/systemd/system/xray.service; enabled; preset: enabled)
Drop-In: /etc/systemd/system/xray.service.d
└─10-donot_touch_single_conf.conf
Active: failed (Result: exit-code) since Sat 2024-03-30 04:35:38 CET; 40s ago
Duration: 38ms
Docs: https://github.com/xtls
Process: 4793 ExecStart=/usr/local/bin/xray run -config /usr/local/etc/xray/config.json (code=exited, status=23)
Main PID: 4793 (code=exited, status=23)
CPU: 31ms
Mar 30 04:35:38 vm2235376.stark-industries.solutions systemd[1]: Started xray.service - Xray Service.
Mar 30 04:35:38 vm2235376.stark-industries.solutions xray[4793]: Xray 1.8.9 (Xray, Penetrates Everything.) 37f8654 (go1.22.1 linux/amd64)
Mar 30 04:35:38 vm2235376.stark-industries.solutions xray[4793]: A unified platform for anti-censorship.
Mar 30 04:35:38 vm2235376.stark-industries.solutions xray[4793]: Failed to start: main: failed to load config files: [/usr/local/etc/xray/conf>
Mar 30 04:35:38 vm2235376.stark-industries.solutions systemd[1]: xray.service: Main process exited, code=exited, status=23/n/a
Mar 30 04:35:38 vm2235376.stark-industries.solutions systemd[1]: xray.service: Failed with result 'exit-code'.
Может кто подскажет как поправить конфиг, что бы SS заработал?
P.S. Эту статью из Росси уже не видно...
У вас на картинке в конце массива между закрывающей скобкой } и закрывающей скобкой ] стоит лишняя запятая (там запятая вообще не нужна), на это ругаются и валидатор, и xray
Спасибо,
Да, я понял что запятая лишняя. Валидацию конфиг проходит, но когда я его запускаю на xray, выходит ошибка: infra/conf: invalid field rule > infra/conf: neither outboundTag nor balancerTag is specified in routing rule
code=exited, status=23
Гугление не помогло... Xray не запускается, пришлось восстановить конфиг только с vless.
neither outboundTag nor balancerTag is specified in routing rule
Покажите часть "routing" вашего конфига
У меня точно так же как в статье. Я ничего не менял...
outbounds and routing
"outbounds":
[ { "protocol": "freedom", "tag": "direct" }, { "protocol": "blackhole", "tag": "block" }
],
"routing": { "rules": [ { "type": "field", "protocol": "bittorrent", "tag": "block" } ], "domainStrategy": "IPIfNonMatch" }}
Когда делаешь вставляешь, вся разметка слетает :((
А, все понятно. Исправьте внутри "routing" - "rules" название поля "tag" на "outboundTag" и все должно заработать.
Это у меня была ошибка в конфиге когда я писал статью, я ее отловил когда проверял конфиги перед публикацией, но видимо под одним из спойлеров забыл исправить. Вы первый, кто наткнулся :)
Спасибо, все верно. Исправил на "outboundTag" и xray заработал.
Shadowsocks работает на Windows и на Android. Благодарен за помощь и поддержку :)
Есть вопрос, когда я подключаюсь через vless в клиенте винды сыпятся ошибки:
Hiddify
Но в тоже время в клиенте андроида такого нет, там все чисто.
Это можно как-то починить? Или это глюк какой-то?...
Скорее глюк. Если все работает, то, думаю, волноваться не о чем.
Вопрос по Hiddify
Установил клиент Hiddify для винды, в хроме все вроде работает, заходит куда надо. Но при выключении Hiddify в хроме не открывается ни один сайт, пишет No Internet. WiFi работает, сетевые настройки не трогал, все по умолчанию.
Где смотреть, куда копать?.... Может кто сможет подсказать?
Заметил проблемы с мобильным приложением instagram на андроид при подключении через XTLS-Reality (настроил в 3x-ui). Контент то загружается быстро, то совсем не грузится ничего (ни посты, ни комментарии, ни список подписчиков - ничего). Бывает, что всё отваливается сразу после открытия приложения, но иногда при запуске всё работает как надо, а через пару минут может отлететь, после чего может заработать через несколько десятков секунд, а может не заработать. Какую-то закономерность я выявить не смог.
В логах из интересного только ошибки подключения по ipv6, но это и для других приложений характерно. На сервере ipv6 нет.
Hidden text
app/proxyman/outbound: failed to process outbound traffic > proxy/freedom: failed to open connection to tcp:[2a03:2880:f223:e6:face:b00c:0:6e2e]:5222 > common/retry: [dial tcp [2a03:2880:f223:e6:face:b00c:0:6e2e]:5222: connect: network is unreachable] > common/retry: all retry attempts failed
Клиент nekobox. Пробовал Hiddify - та же проблема. Пробовал пускать трафик geosite:meta через warp (client->vps->warp->instagram). Проблема не решилась.
От интернет провайдера как будто бы не зависит.
Попробовал подключиться через wireguard (vps один и тот же) - с ним таких проблем нет и раньше не было.
Что интересно, при использовании сайта всё быстро, как и ожидается.
Подобных проблем с какими-либо другими сайтами и приложениями не выявлено.
Есть вариант, что это фича самого приложения инсты. Может кто-то сталкивался с этим?
Это известный баг Instagram и WhatsApp, у них сломан фоллбэк с IPv6, вот тут разобрано: https://ntc.party/t/низкая-скорость-доступа-к-instagram-через-xrayoutlineopenvpn/7246/12
Недавно решил добавить в конфиг работу через CDN. Настроил, всё работает с одним "но": если направить трафик через warp, то при использовании на клиенте функции "проверка подключения", иногда пишет:
Сбой проверки интернет-соединения: io: read/write on closed pipe
А может и сообщать об успешном соединении. То есть раз 5 подряд нажать — будет выдавать и успех, и ошибку. Стоит убрать warp — и ошибка пропадает. В принципе, соединение работает нормально и меня всё устраивает. Мне не дает покоя сам факт ошибки: откуда она и можно ли её исправить. Вот что указано в логах на сервере:
app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > websocket: close 1006 (abnormal closure): unexpected EOF
app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > websocket: close 1000 (normal)
common/mux: unexpected EOF > common/mux: failed to read metadata > io: read/write on closed pipe
Просмотр запросов на гитхабе и других тематических ресурсах так и не дал ответа. Буду признателен за помощь.
А если подключаться напрямую, без с CDN, но с WARP, то то же самое? Как-то не видно связи между тем и тем.
Интересно посмотреть на логи со стороны сервера в момент проблемы
У меня все inbound проходят через warp, и с ними таких проблем нет. Я не особо разбираюсь в тонкостях вопроса, но, возможно, дело в websockets? Нашёл похожие проблемы — там говорят, что ему не хватает времени и он закрывается и советуют увеличить время в handshake.
Нашёл этот параметр в Local Policy в документации конфига Xray. Но там не понятная мне система с level.
Как думаете, дело может быть в этом?
Хендшейк через вебсокеты действительно медленнее, чем без них, но не настолько, чтобы сильно что-то сломать. Если у вас клиент основанный на XRay, убедитесь что у вас стоит ?ed=2048 в конце урла (модно попробовать ещё значения поменьше, например 1024 и 512). Если на базе Sing-box, в них обычно есть аналогичные параметры early data. Делают они и то и то - ускоряют установление соединения (часть данных пересылается ещё в первом upgrade-запросе).
Подключение к WARP тоже занимает время, особенно если до этого долгое время не было трафика и оно "заснуло". Можно добавить http-inbound слушающий локально на 127.0.0.1, и добавить в Cron однострочник с curl, который будет раз в минуту дергать какой-нибудь урлтчерез него, чтобы не давать проксику заснуть.
А зачем вам Warp с CDN? Warp обычно используют при прямых подключения к прокси, чтобы не палить факт наличия прокси на адресе совпадение адресов. У вас же трафик идёт через CDN, сопоставить не получится.
Тут писать нечего, но хаброредактор не даёт удалить существующий пункт
Спасибо за инструкцию! Ранее ставил уже какие-то обходы блокировок на уровне "скопировать код+заменить Алексею поля". Эту инструкцию осилил на 80%.
Вопрос: вижу, что вариант подключения с SS работает значительно быстрее, чем базовый. Есть риски скомпрометировать IP VPS и все остальные методы, если я буду использовать его?
Если будете корректировать статью для нубов типа меня (пришлось интуитивно разбираться через логи и валидатор json по ошибкам) :
1) почему-то копипаст uuid и ключей не работает в вашей статье. Установка xray и получение ключей с uuid почему-то помогла из смежной статьи. Далее шел по вашей инструкции.
2) в правилах inbound в json в каждом случае в конце стоит } с запятой, хотя интуитивно ты добавляешь каждый следующий вариант следующим. В самой статье написано про запятую, но код и коммент не бьются в случае внесения правил ниже, а не выше старых.
3) в каком-то из примеров ссылок скопировалась куча пробелов. Долго разглядывал, нашел один, потом - второй, убил штук 6 в ворде через "найти и заменить"
4) mKCP не знает параметр хедера "webrtc". Бегло погуглил - его нет списка возможных параметров.
4) с вариантом http/2 так и не разобрался. Надо убить первое правило inbound из статьи?
почему-то копипаст uuid и ключей не работает в вашей статье
Можно чуть подробнее, что значит "не работает"?
в каком-то из примеров ссылок скопировалась куча пробелов.
Странно, визуально ничего не видно, потом перепроверю
mKCP не знает параметр хедера "webrtc"
Да, ошибся, должно быть "dtls". DTLS используется в WebRTC. Отредактировал.
с вариантом http/2 так и не разобрался. Надо убить первое правило inbound из статьи?
Если у вас VLESS+XTLS идет в конфиге первым inbound'ом, то да, надо заменить или отредактировать его.
Советую сделать бэкап файла перед изменениями, если у вас сейчас все работает как надо.
Вопрос: вижу, что вариант подключения с SS работает значительно быстрее, чем базовый. Есть риски скомпрометировать IP VPS и все остальные методы, если я буду использовать его?
Скорость работы XTLS-Reality сильно зависит от сервера, под который вы маскируетесь - насколько далеко он находится от вашего сервера и насколько быстро отвечает. Иногда помогает просто попробовать другой домен для маскировки.
Но хендшейк у ShadowSocks и mKCP действительно быстрее, чем у TLS-based протоколов. Можете пользоваться на сервере преимущественно SS или mKCP, в этом нет ничего плохого, проблем быть не должно (если только не начнутся какие-то прям совсем адовые блокировки).
Надежный обход блокировок в 2024: протоколы, клиенты и настройка сервера от простого к сложному