В наше время, когда популярное VPN/прокси-приложение не забанено в аппсторе в РФ, это уже тревожный звоночек и повод задуматься «а почему всех трогают, а именно их нет»
в дефолте проксирует Майкросовтовский сайт(в попытке найти едва уловимые различия) - цензуре достаточно сопоставить SNI в Вашем трафике, и пул адресов вашего хостинга в Нидерландах.
Не существует никакого «дефолта» для Reality с микрософтовским сайтом.
Ну и совет «берите белосписочный фейковый домен под который маскируетесь обязательно из той же AS’ки где у вас VPS» из каждого угла трубят уже много лет как.
Плюс имеющий возможность управлять доменом может перевыпустиить для него TLS-сертификат и провернуть MitM-атаку, например, подменив ссылки на скачивание на протрояненную версию.
Протокол-то добавлен, но я сильно сомневаюсь, что автор sing-box перетащил к себе всю целую реализацию сетевого стека chromium, а скорее всего он просто запилил соответствующий по формату протокол, таким образом потеряв основное преимущество naiveproxy.
Большая часть этих пунктов - не про «вред VLESS», а про «вред» Reality и других штук (типа uTLS), никакого отношения к самому VLESS не имеющих.
про п.2 классическое: сейчас не смотрят, а в любой момент могут начать смотреть. «Решать проблемы по мере их возникновения» в вопросе обхода блокировок и противодействия цензуре - это плохая и очень опасная практика.
Reality и MUX ортогональны. Vision не работает с мультиплексированием, поэтому при сибирской блокировке классический Vision работать не будет. Ставьте flow=none, все равно РКН до сих пор слишком туп чтобы делать какую-либо эвристику tls-in-tls.
Если читать всякие там научные работы, мультиплексирование довольно сильно осложняет такую детекцию, а разделение потоков (особенно по разным адресам) как в XHTTP - так тем более.
Для этого нужно чтобы на том конце у пользователя было намерение это сделать. Если вы доверяете собеседнику, то проблемы нет.
А в случае с Телегой и прочими мутными штуками, наличие намерения собеседника не обязательно - он может вообще не подозревать что что-то куда-то там сливается.
Даже если где-то кто-то творит дичь и глупость, не надо им уподобляться.
В наше время, когда популярное VPN/прокси-приложение не забанено в аппсторе в РФ, это уже тревожный звоночек и повод задуматься «а почему всех трогают, а именно их нет»
Далеко не все мобильные браузеры и мобильные приложения поддерживают настройки прокси.
Не существует никакого «дефолта» для Reality с микрософтовским сайтом.
Ну и совет «берите белосписочный фейковый домен под который маскируетесь обязательно из той же AS’ки где у вас VPS» из каждого угла трубят уже много лет как.
все правильно, только не TUN, а TURN, а в остальном все верно.
Inbound ip сольется только у Happ, у остальных клиентов такой баги нет.
Ну и Warp - это как раз про сути дела такой бюджетный вариант каскада
SSTP ещё проще блокируется по active probing
В итоге будете каждый день менять или даже каждый час
Плюс имеющий возможность управлять доменом может перевыпустиить для него TLS-сертификат и провернуть MitM-атаку, например, подменив ссылки на скачивание на протрояненную версию.
Учитывая что в 99% васянских self-hosted конфигах выходной адрес совпадает с входным, это очень серьезная атака.
Если вы не видели, это не значит что их никто не видел. Эта методичка уже давно слита в интернет и с ней может ознакомиться каждый желающий
Вообще даже близко нет. Ну и мы все-таки не на пикабу, а на профильном техническом ресурсе, надо аккуратнее с терминами и формулировками.
Практические никакие протоколы, которые он умеет, не поддерживают транзит ICMP, они не на L2 и даже не L3 работают, а уровнем выше.
Протокол-то добавлен, но я сильно сомневаюсь, что автор sing-box перетащил к себе всю целую реализацию сетевого стека chromium, а скорее всего он просто запилил соответствующий по формату протокол, таким образом потеряв основное преимущество naiveproxy.
Большая часть этих пунктов - не про «вред VLESS», а про «вред» Reality и других штук (типа uTLS), никакого отношения к самому VLESS не имеющих.
про п.2 классическое: сейчас не смотрят, а в любой момент могут начать смотреть. «Решать проблемы по мере их возникновения» в вопросе обхода блокировок и противодействия цензуре - это плохая и очень опасная практика.
Частично похоже на XHTTP с разделением потоков (а если поколдовать над конфигом XRay, то в теории даже можно сделать то что описали вы)
Reality и MUX ортогональны. Vision не работает с мультиплексированием, поэтому при сибирской блокировке классический Vision работать не будет. Ставьте flow=none, все равно РКН до сих пор слишком туп чтобы делать какую-либо эвристику tls-in-tls.
Если читать всякие там научные работы, мультиплексирование довольно сильно осложняет такую детекцию, а разделение потоков (особенно по разным адресам) как в XHTTP - так тем более.
используйте VLESS с gRPC-транспортом, там встроенный мультиплекс в 1 подключение.
ну или XHTTP с maxConnections=1 если клиент позволяет
Для этого нужно чтобы на том конце у пользователя было намерение это сделать. Если вы доверяете собеседнику, то проблемы нет.
А в случае с Телегой и прочими мутными штуками, наличие намерения собеседника не обязательно - он может вообще не подозревать что что-то куда-то там сливается.
Это нелегко, но все же легче, чем оставаться тут на месте с учётом всего приходящего, особенно в долгосрочной перспективе