
Комментарии 42
Это всё хорошо, но расстраивает отсутствие последней версии в iOS appstore. Форк (напр sing-box-extended) выложить не получится?
Я задонатил автору sing-box через github (благодарность за хорошую программу). За это дается доступ к приватному telegram-чату с доступом к свежей версии sing-box для iOS и macOS.
Это геморно по сравнению с андроидом где взял и скачал последнюю версию, и не надо донатить и писать свой apple id. Я ему кстати тоже донатил, но он меня забанил после того как в очередной раз (хотя я лично всего 2 раза) попросил добавить amnezia wg, а ещё до этого он забанил меня за вопрос типа "почему ты постоянно блокируешь issue без объяснений? Что мешает чётко выражаться?". Вообще хотел 100$ ему закинуть, но он меня остановил на 10$ своим поведением
Я задонатил автору sing-box через github (благодарность за хорошую программу). За это дается…
Вы не задонатили, вы купили доступ к доп возможностям. Пожертвование, оно должно быть просто так, без получения чего-то в ответ. Иначе получится, как в РПЦ, когда, чтобы не соблюдать ЗоЗПП, всё выворачивают так, как быдто вы жертвуете деньги, а они вам в ответ нарят товар.
Я против публичного обсуждения благотворительности, но на публичное "обвинение" отвечу. Начать хотя бы с того, что доступ дается за любой единоразовый платеж. Я подключил ежемесячные платежи на хорошую сумму. Я стараюсь продвигать sing-box статьями на хабре, что идет в плюс автору (даже скорее всего финансово). Я пофиксил несколько багов в коде (один из них описан тут), PR приняты. Плюс добавил новое правило package_name_regex, будет в релизе в версии 1.14. Так что мои отношения с sing-box строятся именно на любви к продукту, а не на получении благ за деньги. Но конечно можно назвать это эгоизмом, потому что я сам пользуюсь программой и хочу сделать её лучше.
Так а я вас ни в чём не обвиняю. Это автор ПО называет благотворительностью то, что ей не является.
Как к этому относиться, личное дело каждого. Но лично моё мнение тостоит в том, что описанная ситуация сильно попахивает. Те, кому это нужно, часто не имеют “иностранной” карты, чтобы сделать “пожертвование”. В итоге, они не имеют доступа к свежим версиям ПО. Как по мне, это что угодно, но не пожертвование.
Вы можете иметь другое мнение, это нормально.
Автор изначально ничего не просил за последнюю версию, это apple заблокировали ему аккаунт и он не может выложить новую версию
Да, у меня тоже были такие подозрения. Но даже если так, то автора не осуждаю, делает хорошее дело (судя по коммитам это для него как основная постоянная работа). Плюс очень много бесплатных клиентов используют его ядро (то есть бесплатный доступ к его коду есть). Для обычных пользователей оригинальный sing-box сложноват. В AppStore доступна устаревшая версия, потом начались какие-то проблемы. И такие проблемы у него возникают не в первый раз (потом программа все-таки обновилась, а потом снова пауза).
А проблема в том, что у Apple для VPN отдельные более жесткие правила публикации. Такая программа может публиковаться только разработчиком, зарегистрированным как organization.
В Shadowrocket есть naive
Я написал клиент для naive для iOS:
https://habr.com/ru/articles/1023230/

Вроде она поддерживает наив, смотрел в натсройке на ютубе. Но у меня нет айфона чтоб проверить)
Перехватив этот пакет, можно довольно точно определить программу, которая его отправила. Xray и sing-box написаны на Go, поэтому без дополнительных ухищрений их ClientHello соответствует стандартному для Go — такие соединения можно распознать и заблокировать.
Вообще то в конфигах спокойно можно прописать под какой браузер маскироваться. Какой еще ClientHello, стандартный для Go? Это что то новое.
Дочитайте, пожалуйста, подраздел до конца. Следующее предложение после процитированного вами:
Для маскировки оба проекта используют библиотеку uTLS, которая позволяет сделать ClientHello похожим на ClientHello реального браузера (Chrome, Firefox или др.).
Как раз uTLS (о котором подраздел) и обеспечивает похожий на браузерный ClientHello, если он включен через конфиг. Если не использовать uTLS, то будет стандартный ClientHello от Go (в случае программы, написанной на Go).
Не затронуты плюсы и минусы по сравнению с VLESS. Но за статью спасибо.
Это сложно сделать из-за того, что VLESS очень сильно отличается в зависимости от настроек и транспорта (Vision, XHTTP, gRPC, Reality и прочее). И даже Vision работает сильно по-разному в зависимости от трафика, который он прогоняет (где-то включается Splice, а где-то нет).
Основное же отличие Naive я постарался описать в разделах "ClientHello и uTLS" и "О NaïveProxy". А к чему реально будет в дальнейшем привязываться цензор (какая особенность того или иного протокола будет мешать или помогать) - неизвестно. Может вообще все закончится белыми списками, а не анализом протоколов.
Насколько я понял из ответов ИИшки (которую мучал этим вопросом несколько недель назад) Naive по сравнению с VLESS Vision Reality:
+ Лучше маскируется
- Медленее (неизвестно на сколько)
- Нет поддержки туннелирования UDP - голос и игры могут не заработать
Т.е. если VLESS (Reality Vision) работает и устраивает - то можно не смотреть в сторону Naive или поднять второй сервер с ним на всякий пожарный, если вдруг VLESS начнут резко детектировать.
При связке, описанной в статье, UDP работает. Я отдельно упомянул параметр udp_over_tcp. С клиентами на базе sing-box тоже работает. И с популярным Shadowrocket работает.
По поводу скорости всё индивидуально, можно сделать замеры. ИИ так мог ответить из-за режима Splice в Vision Reality, но он скорее про нагрузку сервера, да и включается не всегда (зависит от условий). И наоборот, у Vision Reality есть принципиальная проблема (особенность) с отсутствием мультиплексирования и необходимостью на каждое новое подключение подключаться к удаленному серверу для получения сертификата, что создает существенные задержки на каждое устанавливаемое соединение (а если сайт-донор еще и тормозит или блокирует частые подключения, то становится совсем плохо).
А вот то, что переходить с VLESS на Naive нет смысла, если VLESS хорошо работает - это верно (я об этом тоже сказал в заключении статьи).
Насколько я понял из ответов ИИшки
LLM лучше не спрашивать о тонкостях работы этих средств обхода блокировок без обогащения контекста документацией или исходным кодом (иначе галлюцинируют).
Подскажите, пожалуйста, проблему детектирования за счёт TLS in TLS автор уже решил?
К сожалению, проблема TLS in TLS остается. Вот что автор пишет в своей документации:
Соединение TLS поверх TLS требует большего количества циклов обмена данными (round trips) при рукопожатии, чем необходимо для обычных HTTP/2 (h2) запросов; иными словами, ни одному h2-запросу не нужно такое количество двусторонних обменов при установке соединения. Простого способа избежать этого нет, кроме использования MITM-проксирования, что нарушает сквозное (E2E) шифрование.
Накладные расходы TLS поверх TLS приводят к заметному увеличению длины пакетов и отсутствию пакетов малого размера. Устранение этих издержек также требует MITM-проксирования.
Кроме того, из-за накладных расходов TLS поверх TLS размер пакетов постоянно превышает лимиты MTU, чего не должно происходить со стороны исходного пользовательского агента (клиента). Решение этой проблемы требует повторной сегментации (re-segmentation), что реализовать непросто.
По сути маскируется это только мультиплексированием множества конечных соединений внутри одного туннеля (поэтому автор и рекомендует insecure_concurrency = 1), что затрудняет анализ длины и отчасти скрывает TLS in TLS.
А в 3 x-ui будет поддержка данного протокола? 🤔
Поддерживает ли sing-box протокол XHTTP? Хочу настроить клиента на базе sing-box (нужен tun). Если да, то какой это тип?
Все эти методы обхода рано или поздно распознают и все.
Из статьи не понял, это собственный домен надо иметь что ли? Под чужой как в Reality маскироваться не получится?
Да, прошу прощения, я не обозначил это в статье. Конфигурация из статьи подразумевает наличие своего домена. Но можно обойтись и без него, но тогда не будет защиты от активного сканирования. Вариант с self-signed сертификатом. Caddy нужно будет настроить иначе. И в клиентской конфигурации sing-box в секции tls указать `insecure: true`.
https://sing-box.sagernet.org/configuration/shared/tls/#insecure
Если я правильно понял, требуется иметь свой домен. В связи с законом о регистрации ru доменов, для этих целей лучше брать зарегистрированный за границей или не о чем волноваться?
Да, прошу прощения, не сделал на этом акцента. Показалось, что если мы говорим о настройке своего сервера, то покупка домена не сложнее (и не дороже) аренды сервера.
Ответил выше на похожий комментарий: https://habr.com/ru/articles/1024990/comments/#comment_29851264
Я считаю, что нет никакого риска взять ru домен (по крайней мере на данный момент). Плюс можно использовать поддомены.
Я всеже советую брать у зарубежного регистратора, благо их довольно много, и вот почему:
С 1 сентября у ру регистраторов нужно пройти жёсткий KYC, через госуслуги, а это всеже нежелательно, как понимаете
Большинство ру регистраторов отличаются изрядной жадностью, покупал недорогой домен за 100 рублей, а на следующий год предложили его продлить за 1999. (Для сравнения американский предложил за первый год $1.5, а за второй и далее - 4.5, что уже гораздо более честные условия)
Он называется ClientHello и содержит версию TLS, список поддерживаемых шифров, HTTP-протокол, домен запрашиваемого сайта и прочее. Эти данные передаются в открытом виде и отличаются от браузера к браузеру.
Интересно, а ECH (Encrypted Client Hello) блочат? Я делал в тулзе для доступа к админкам и внутренним сервисам. Там публичный домен и реальный (зашифрованный) отличаются.

NaïveProxy
Интересно узнать страну проживания разработчика решения, раз используется нестандартная "i". =)
Ну вообще naïve французское слово, а в английском пишется с одной точкой, потому что в алфавите нет символа с двумя точками и не используются диакритические знаки над буквами :)
NaïveProxy в sing-box (альтернатива VLESS)