
Комментарии 226
Вероятно, из-за наличия заблокированных иностранных ресурсов всегда можно будет вшить в сайт/приложение ББ запрос к ним, который они вернут к ББ, что раскроет наличие ВПН. Думаю, такие сайты будут устраняться аналогично рекламе, но в режиме "второго шага".
если ваш промежуточный узел будет отвечать нормальным сайтом на запросcurl -k https://1.2.3.4 (где 1.2.3.4 - ip-адрес сайта), то доказательств наличия там vpn не будет. Только предположения. Я понимаю, что банят и без доказательств. Но всё-таки.
Не совсем понятно, зачем пользоваться услугами обсосов, которые работают через задний проход, не хотят работать - пускай разоряются
А то очень выгодно получатся, тарифы растут, условия предоставления "хз" ниче не зависит от них, услуги подключаются сами, цены меняются сами, "лох крутится - лавеха мутится"
Насколько я понял, им важно наличие VPN как такового, не важно в РФ он или нет.
Т.е. если spyware видит, что включён ВПН, оно определят его IP и блокирует MY.VPN, остальные два ему и не нужны.
внутри суверенного государства ресурсы пока (пока!) блокируются только посредством суда, для которого нужна докбаза
блокировка freedom.vpn2 предложенному решению не опасна
а о freedom.vpn1 РКН информации получить негде. Он конечно может начать давить на датацентры. Но это займёт не один месяц. (думаю, годы).
Получается, что в идеале нужно чтобы vpn1 и vpn2 были у разных хостингов, чтобы диапазоны ip-шников максимально различались?
Или в этот раз они планируют точечно блокировать.
внутри суверенного государства ресурсы пока (пока!) блокируются только посредством суда, для которого нужна докбаза
Вы многое пропустили. Министерство «порекомендовало» всем кто в белых списках отказать в обслуживании клиентам с впн
Позволю себе не согласиться. У меня уже почти месяц подобная схема реализована в тестовом режиме на нескольких устройствах. Даже если на MY.VPN завернуть трафик к определенным доменам\зонам напрямую с MY.VPN, т.е. оставить внутри страны, некоторые приложения\страницы отказываются работать совсем. Предположительно, у них есть чекер на какие-то свои домены ВНЕ границ, что вполне вероятно, т.к. страница на ПК не может знать что у меня в системе включено или на роутере завернуто. На телефоне же им достаточно самого факта включения vpn. Речь идет о гос ресурсах. Так же приложение такси (не яндекс) реагирует на этот факт. Хочу поиграться с wireshark, чтобы определить этот момент, но пока руки не дошли. Прочие помои типа яндекса и сбера не реагируют на vpn. Полагаю, что им достаточно того, что к ним приходят с внутреннего IP, а сам факт включенного vpn их не интересует. Хотя и не мешает стучать.
Увы, РКН уже давно имеет право внесудебной блокировки внутри суверенного государства. Детей же надо от порнографии защищать, а пока суды расчехлятся... Это, кстати, было официальной мотивацией, когда внесудебные блокировки пробивали. Ну и на личном опыте знаю сайт, который вынужден доменные имена и хостинг менять регулярно, ибо банят его без всякого суда.
внутри суверенного государства ресурсы пока (пока!) блокируются только посредством суда
???
о freedom.vpn1 РКН информации получить негде
Простите за, возможно, глупый вопрос, а команда tracert разве не показывает все промежуточные узлы через проходит пакет ? Таким способом шпионское ПО не может посмотреть и вычислить первый узел за границей суверенного государства ?
если vpn строится на общепринятых в настоящее время технологиях (xray), то для того, чтобы показать маршрут tracert надо приложить усилия
(усилия не к тому чтоб собрать, а к тому чтоб организовать такую возможность)
а по умолчанию никакой роут не собрать
1 192.168.0.11 0.4ms 0.4ms 0.5ms
2 192.168.1.11 5ms 5ms 5ms
3 192.168.2.11 50ms 50ms 50ms
4 149.28.42.42 200ms 200ms 200ms
Упс, отстрелили сами себе пятую точку, надо срочно заблокировать 192.168.2.0/24, а лучше сразу 192.168.0.0/16 ну и последний, таааак, стопэ, мы же его уже заблокировали
трейс передаётся через туннель и соответственно показывает адреса внутри туннеля. а это обычно только вход (адрес интерфейса tun на клиенте, он вообще как правило из локальных диапазонов) и выход (выходной адрес на том конце туннеля).
кроме того трейс можно блокнуть кучей способов. а именно запретить отвечать ттл экспайред, подкрутить ттл и т.п.
можно даже заспуфить адресами тындекса. если они начнут его использовать это будет бесконечное поле для глумления над ними.
Tracert покажет скачки по адресам локальной сети.
Условно 10.0.0.1->10.0.1.1->интернет.
ты увидишь только внутренние айпи на туннелях
Внутри суверенного государства уже (уже!) блокируется все что не в белых списках безо всяких судов. Речь про мобильную связь и возможно про отдельные регионы.
freedom.vpn1 будет жить рядом с VDS других пользователей, которые не будут строить анти-spyware цепи. Просто попробуйте запустить RealiTLScanner в подсети своего хостера, и вы увидите много гуглов и майкрософтов. Сначала РКН будет блокировать точечно, а потом и всю подсеть (вместе с freedom.vpn1, который нигде не светился).
Схема на текущий момент рабочая, но вот "на года" - слишком оптимистично.
не годы, к сожалению
https://www.kommersant.ru/doc/8590872
VLESS строго говоря это не VPN, здесь не надо мешать в кучу. Обращение к транзитному узлу находящемуся в РФ (помечен у автора как gosuslugi, но всем понятно что это) абсолютно легетимно и понять что это не взаимодействие с "госуслугами" или "мессенджером скам" (в зависимости от того, какой сайт указан камуфляжным) практически нереально, особенно на больших площадях. Тесты типа nDPI, what-vpn и пр. не могут обнаружить, тестировал это.
Раскрытие происходит через IP exit-точки за рубежом. В предложенном варианте IP зарубежной точки выхода не совпадёт с IP зарубежного dest-сервера, а по IP dest-сервера ТСПУ получит камуфляжный зарубежный сайт, например, kernel.org. Ну, т.е. мы выяснили что VDS на условных gosuslugi очень любит посещать условный kernel.org. Наш трафик зашифрован TLS 1.3 (Reality) и неотличим от обычного посещения сайта kernel.org, что там внутри на самом деле котики с ютуба неизвестно.
IP dest-сервера не фигурирует ни в каких списках, а IP exit-сервера знает только dest-сервер. Деньги на дне бидона. Это может работать.
На телефоне (андроид) стоит блокировщик рекламы и трекеров adguard. Это приложение поднимает локальный VPN на телефоне и гонит весь трафик через себя, чтобы отсекать рекламу и в браузерах, и в других приложениях. Даже на это местами возбуждаются другие приложения, хотя тут обходом блокировок даже и не пахнет. Решается отключением фильтрации траффика этих приложений в самом adguard.
Берется просто сим-карта с роумингом и не нужен не какой VPN.
У моей финской карты в России - 6 евроцентов за мегабайт. Дорого.
Есть виртуальные операторы только с интернетом - до 2-х тысяч за 10 гигов. Есть чуть более сложные , но интересные кейсы - типо французского оператора за 30 евро с анлимом в роуминге.
как вы собираетесь разделять трафик на my.vpn?
*.ru внутрь остальное наружу?
Можно всё так же обойтись двумя VPSками. Есть хостеры, у которых пул IP состоит из множества мелких диапазончиков, вероятно скупленных на вторичке, и при докупке адресов на VPSку выдаются адреса, не похожие даже в первом октете. В таком случае этот сервер спокойно имитирует оба - вход условно на 26.x.x.x, а выход на 175.x.x.x.
Второй вариант - I2P-рой между my и freedom2. Создается много-много инстансов клиента (my) и сервера (freedom2) с параметрами: quantity 16/16, length 0/1 (или 1/0 - равноценно, это как левостороннее или правостороннее движение). Оба i2pd включаются на флудфил, чтобы иметь хорошую репутацию и максимально полную netDb, крайне желательно также собрать их в семью. Все инстансы на клиенте агрегирует haproxy с постоянным тестированием и отбраковкой неудачных, на сервере - они просто все смотрят на один сокет. То есть, на место freedom1 встает распределенный рой запараллеленных пиров.
Хотите верьте, хотите нет, но на практике такая система с хорошим размером роя обеспечивает сотни Мбит/с с пингом 300-500 мс. Пруфов не будет (господин жандарм, подите прочь делать сами свою сыскную работу, с вас тошно-с), но проверить мои слова может каждый собственным экспериментом.
Да если до одного сервера дотянуть два айпи и выходной трафик пускать через тот, который не жалко, то можно сэкономить один VPN
Ещё можно использовать тот факт, что ipv4 и ipv6 - разные протоколы. Требуется два сервера с поддержкой ipv6:
1. К MY.VPN клиенты цепляются по ipv4
2. MY.VPN соединен с FREEDOM.VPN по ipv6
3. FREEDOM.VPN раздает интернет по ipv4.
При попытке прощупать FREEDOM.VPN отдаст ipv4 адрес. Но при блокировке этого ipv4 адреса ipv6 продолжает работу штатно, поскольку это другой протокол, который не фильтруется.
Проверено лично, ipv4 адрес моего сервера в Германии попадал под блок (этот сервер, кстати, как раз брался для экспериментов с ipv6); но ipv6 адрес на том же сервере продолжал работать и быть доступным из России.
А точно ли провайдер не видит квн? У меня есть пример с местным провайдером в одном городе. Вот на какие конфиги хватило фантазии: 1) ru-blocked на свободу, остальное в директ; 2) то же самое, но YouTube отдельно в прокси от byebyedpi (по сути директ с порчей пакетов); 3) ru-blocked на сервер в России (как тут на схемах) и оттуда на свободу, остальное прямо с устройства в директ. Минуту работает YouTube, после чего интернет накрывает белым списком (да-да, проводной!): не работает даже поиск в гугл, но вк без проблем. После перезагрузки роутера интернет опять работает (серый и белый), но стоит загрузить что-нибудь в YouTube - опять белые списки. Пока не могу разгадать, на моем провайдере все три конфига работают. X-ray+VLESS+Reality
Похоже поведение наблюдал - оказалось, что у этого провайдера ip моего зарубежного ДЦ в черном списке. Т.е. что там в трафике он не видел, но вот что трафик идёт туда, куда нельзя - да. Решилось сменой хостера.
У меня несколько месяцев назад было похожее поведение на МТСе по проводу, но не работало вообще ничего. Специально тестировал трассировкой до Яндекса и ВК, 98% потерь на TCP-соединениях. Что послужило триггером -- тоже неясно.
Объясните мне зачем городить такой огород? Есть более простыре решения, а именно: раздельное туннелирование на Android - приложения кто не в списке просто не смогут попасть внутрь тунеля (но будут занать что у вас есть VPN). Если у вас iPhone тогда сложней можно например использовать sing-box и разделять трафик (RU и не RU локация) прямо на самом телефоне.
Далее нам нужно иметь максимум два VPS, один на России для входа трафика, второй в Европе для выхода трафика. MY.VPN в вашей логике это сам телефон кто делит трафик, не вижу смылка делать его как VPS в России. а вот FREEDOM.VPN1 должен быть в России т.к. рано или поздно трафик с телефона перестанет идти зарубеж напрямую.
а вот FREEDOM.VPN1 должен быть в России
Если сделать так, то при попадании FREEDOM.VPN2 в список блокировки FREEDOM.VPN1 из России не сможет до него достучаться.
Если VPN1 в России у хостинг провайдеров, а не просто дома на роутере с белым IP тогда достучится, у хостинг провайдеров кажется более щадящие режимы блокировки, ну во всяком случаи у тех что мне покападались подруку. Более того 95% всех зарубежных провайдеров уже в черном списке искать то что не заблочено сложно, а если найдешь то есть вероятность что заблочат через время.
Как выяснилось раздельное туннелирование - это дырка на дырке
https://habr.com/ru/articles/1020080/
Я не пойму одного, столько всего городить, а все будет проще, "шпиен" -> "андройд у тебя сетевой интерфейс квн" -> "Да сэр" -> "квн детектед".
Это все конечно позволит нашему брату меньше пользоваться отечественными ресурсами, т.к. придется передёргивать впн, но такой подход не палит ip хостера - а ркн по методичке четко хочет не только выявить но и получить списки для бара
Потому что куча легальных ВПН используется в ИТ для корпдоступа. А какой конкретно ВПН сейчас активирован, белосписочный или нет, так не определить.
Уважаемые коллеги! Вам не приходило в голову, что все эти ваши трёхзвенные схемы легко вскрываются, стоит только заняться анализом статистики соединений? Вы же, наверно, в курсе, что есть такая замечательная вещь, как NetFlow различных версий, и что среди провайдеров принято вынимать c его помощью сведения о сеансах связи с граничных маршрутизаторов? И, наверное, понимаете, что совершенно ничего не мешает накапливать эти сведения, а затем сгруппировать сеансы связи по парам «адрес источника» — «адрес назначения» и таким образом выявить устойчивую связь между вашими MY.VPN и FREEDOM.VPN1?
Вы ж через этот самый MY.VPN непрерывно долбитесь во FREEDOM.VPN1, и он, само собой, отвечает вам через него взаимностью? Ведь долбитесь же, да? Ага, я так и думал. Так что адрес этого самого FREEDOM.VPN1 вы спалите просто самим фактом постоянного трансграничного трафика между ним и MY.VPN.
Ну а если провайдер по какой-то странной причине не выгружает сведения о соединениях со своих граничных маршрутизаторов сам, всегда есть ТСПУ, через которые проходит весь трафик и на которых можно накапливать нужную статистику соединений по парам адресов источника и назначения, или оборудование СОРМ, которое вообще обязано хранить весь трафик с этими самыми адресами за три последних месяца. Сиди, да считай не спеша нужную статистику, а затем блокируй выявленные адреса FREEDOM.VPN1 квадрадно-гнездовым методом, поблочно.
Мой ПК 24/7 долбиться к microsoft сливая телеметрию, а ещё у Гуглу и куче других сервисов. Иногда объем трафика большей (качаем обновления/гугл карты/etc), иногда маленький. Объем трафика через тоннель с разеделем у меня когда я ещё мониторил это - был около 10-15гб, что в общем потоке 350гб идущих даже не особо заметно. Иногда он был большой (смотрим Ютуб), иногда маленький (служебный трафик для поддержки соединения или чисто веб).
Так что все не так очевидно, как кажется. Хотя есть некие признаки, но о них умолчим и точных данных они все равно не дадут)
Мой ПК 24/7 долбиться к microsoft сливая телеметрию, а ещё у Гуглу и куче других сервисов. Иногда объем трафика большей (качаем обновления/гугл карты/etc), иногда маленький.
Во первых, туда долбится не только Ваш ПК. Туда долбятся миллиарды, а из нашей страны —миллионы. Вот по этому признаку их очень быстро можно исключить из списков VPN.
А ещё можно составить список DNS имён широко известных сервисов в сети интернет, поднять у себя на ТСПУ кэширующий сервер DNS и постоянно ресолвить имена из этого списка впрямую на самих ТСПУ, а затем пробивать адреса из статистики NetFlow из кэша своего сервера DNS на предмет того, что же это за имя. И так можно будет гарантированно исключить соединения с широко известными сервисами.
Во-вторых, вы же не пускаете трафик к серверам Microsoft и Гуглу непосредственно c MY.VPN? Правильно, не пускаете. Он ведь у Вас либо идёт через туннель MY.VPN <—> FREEDOM.VPN1, либо, если эти сервера не заблокированы, вообще даже не доходит до MY.VPN, а уходит в интернет непосредственно с Вашей машины, ведь трафик MY.VPN надо экономить, правильно? Поэтому, если исключить обновления ПО, то единственный трансграничный трафик вашего MY.VPN — это трафик VPN-туннеля MY.VPN <—> FREEDOM.VPN1.
Объем трафика через тоннель с разеделем у меня когда я ещё мониторил это - был около 10-15гб, что в общем потоке 350гб идущих даже не особо заметно. Иногда он был большой (смотрим Ютуб), иногда маленький (служебный трафик для поддержки соединения или чисто веб).
Вот как только из статистики NetFlow будут исключены соединения с общеизвестными сервисами, так сразу на верхнюю строчку трансграничного трафика вылезет длительно висящее соединение MY.VPN <—> FREEDOM.VPN1, и ничего Вы с этим сделать не сможете.
Вот как только из статистики NetFlow будут исключены соединения с общеизвестными сервисами, так сразу на верхнюю строчку трансграничного трафика вылезет длительно висящее соединение MY.VPN <—> FREEDOM.VPN1, и ничего Вы с этим сделать не сможете.
Если исключить обновления - то трансграничный трафик из моей сети - это может быть куча всего, даже включенный торрент генерирует трансграничный трафик по рандомным ip адресам, игры генерируют трансграничный трафик и их не так просто включить в "общеизвестные", они вполне предоставляют выделенные сервера для узкой группы лиц, webrtc стримы с вебкамер, экзотическая аппаратарура коей немало (всякие 3д принтерны, которые могут быть вообще в штучном количестве в стране).
Ну тоесть бахнуть то конечно можно всё и сразу - можно и белыми списками всё накрыть, но вот сказать - что так легко и просто все вычислится - нелегко, не просто, и с большими сопуствующими потерями. и это при том, что на многих vps - сменить ip - дело дешевое и быстрое, а после этого нужно опять несколько месяцев собирать статистику, чтобы снова бахнуть.
Если исключить обновления - то трансграничный трафик из моей сети - это может быть куча всего, даже включенный торрент генерирует трансграничный трафик по рандомным ip адресам, игры генерируют трансграничный трафик и их не так просто включить в "общеизвестные", они вполне предоставляют выделенные сервера для узкой группы лиц, webrtc стримы с вебкамер, экзотическая аппаратарура коей немало (всякие 3д принтерны, которые могут быть вообще в штучном количестве в стране).
Так в том-то и дело, что торрентокачалка — это короткие соединения с огромным количеством разных адресов, а VPN-туннель — это устойчивый трафик между двумя адресами, который не прерывается в течение суток. Особенно если в туннеле включить keepalive. Про стримы с вебкамер ничего определённого не скажу, не щупал, про 3D принтеры — не понимаю, зачем им нужно устойчивое соединение с одним и тем же адресом, висящее сутки напролёт.
P.S. Если Вы решили, что я предлагал сортировать статистику по суммарному объёму трафика между парами адресов и искать наибольший, то это не всё. Есть ещё вариант брать соединения за сутки и смотреть, когда в эти сутки трафик между конкретной парой адресов начался, а когда — закончился, а затем сортировать по наибольшей длине интервала между этими двумя событиями. Так можно выявлять пары адресов, между которыми существует устойчивый круглосуточный трафик, а на что это больше всего похоже? На VPN-туннель это похоже.
Ведь долбитесь же, да? Ага, я так и думал. Так что адрес этого самого FREEDOM.VPN1 вы спалите просто самим фактом постоянного трансграничного трафика между ним и MY.VPN.
Здесь Вы правы и не правы одновременно.
Да факт соединения - спалится. Но что это за соединение? Обычная часть микросервисной архитектуры, где микросервси стучится в другой? Или это VPN?
Было бы можно такое отличить методом анализа трафика, разве стали бы они городить огород со стукачами?
(об этом и в статье написано)
Да факт соединения - спалится. Но что это за соединение? Обычная часть микросервисной архитектуры, где микросервси стучится в другой? Или это VPN?
Было бы можно такое отличить методом анализа трафика, разве стали бы они городить огород со стукачами?
Зачем отличать? Блокируем, а затем внимательно слушаем эфир: если снизу начинают раздаваться действительно массовые злобные истеричные выкрики, слышно, как кто0то швыряет в стену телефонный аппарат, кто-то в сердцах хлопает дверью, а потом нам звонят сверху и вежливым матом объясняют, что мы наступили ногой на горло бизнесу уважаемых людей, и эти уважаемые люди уже вот прям щаз теряют кучу бабок в минуту — значит, мы заблокировали что-то не то. Тут важно, чтобы низы и верхи взбунтовались одновременно. Если бунтуют только низы и в микроскопических объёмах — значит, мы нащупали и пристрелили чей-то микроскопический бизнес по продаже услуг того самого трёхзвенного VPN.
Всё нормально, это древний и весьма уважаемый способ составления правил межсетевого экрана в информационных системах, когда никто из сотрудников уже не в состоянии внятно объяснить, кто и куда должен иметь доступ и по каким протоколам, потому что никто не знает, как и что устроено ввиду того, что критически важные элементы инфраструктуры разрабатывались и внедрялись лет десять тому назад, на коленке и без надлежащего документирования, а кто знает, тот уже не помнит, а кто ещё помнит — те давно релоцировались: редкие счастливчики — в верхние эшелоны мегакорпораций, и теперь им нельзя просто так взять и позвонить, кто на удивительное Бали, кто в психушку (ночные смены и работа по двенадцать часов в сутки, ага), а кто и вообще на кладбище.
Шучу. А может, и не шучу ;)
Да, до некоторых хомячков начала доходить банальность, что вход и выход могут использовать разные IP-адреса (тут самое время задуматься, кстати, почему кое-кому поддерживать IPv6 становится противоестественно — что прямо даёт ответ на вопрос о перспективах развития этого протокола в РФ). По этому поводу пишется мега-портянка с пафосом официального пресс-релиза испанского двора. И да, как справедливо указано выше, корреляцию между трафиком это не решает. Пульс детектируется на выходе из смартфона, даже если он летит не туда, откуда потом прилетает. Усложняет ли это блокировку входного узла — несомненно. Но если система наблюдает, что ваш смартфон долбится в одну дверь, а при этом такой же стук раздаётся на другой, то сопоставление технически реализуемо. Апп-стукач может даже постукивать по шаблону, чтобы повысить шансы на верный детект, без false positives.
Скорее всего РКН даже не будет анализировать весь NetFlow, просто ТСПУ будет настроен на детект подозрительно долгих TLS-сессий с нетипичным распределением длин пакетов
Ресурсы. Они не безграничны. Иначе придётся полстраны до майоров повысить.
Ресурсы. Они не безграничны. Иначе придётся полстраны до майоров повысить.
Для описанного мною случая много ресурсов не надо. ТСПУ со своим онлайн DPI потребляет существенно больше.
Не согласен. Здесь нужен анализ большого объёма данных в одном месте.
Не согласен. Здесь нужен анализ большого объёма данных в одном месте.
У меня был опыт решения подобной задачи с помощью SiLK CERT NSA tools. Особо больших объёмов данных это, вроде бы, и не требовало. По сравнению с объёмами самого трафика объёмы обрабатываемых мною данных о сеансах передачи данных были, скажем прямо, микроскопическими, потому что первичную обработку трафика для экспорта этих сведений по протоколу NetFlow выполняли сами граничные маршрутизаторы своими SoC'ами. Вместо всего трафика они отдавали только записи о том откуда, куда, по какому протоколу, с какого порта на какой порт, время начала и время окончания передачи, а также флаги TCP/ICMP. Нагрузка на маршрутизаторы после включения экспорта NetFlow если и возросла, то это было совершенно незаметно.
Ну и надо сказать спасибо дизайнерам этих самих SiLK CERT NSA tools: благодаря грамотной упаковке данных NetFlow поиск и генерация отчётов по формируемой базе данных происходили практически моментально, особенно если брать окно размером всего в сутки, как я выше предлагал.
Во всех статьях на эту тему не вижу простой мысли. Троян не сможет слить выходной адрес, если split _routing_ настроен на обход исключительно конкретных заблокированных ресурсов, вместо bypass только RU сегмента. Whitelist доступной поверхности атаки для трояна, куда не впихнуть левый чекер IP. Сам факт он узнает, попинговав ютуб, но не сможет узнать точку выхода, так как не может пропинговать чекер. Ошибаюсь ли я?
Есть еще нюансы с попаданием заблокированных сайтов на одни ip адреса с сервисами выявления ip (где-то на хабре же товарищ описывал такой кейс). Но вообще одно из лучших решений, на мой взгляд:
1) не ходить на VPN через сотовые сети
2) На компьютере полностью отказываемся от Российских решений в виде ПО.
3) Весь трафик через split-routing с точечным перенаправлением трафика посредством внешней к компьютеру коробочки на openwrt
3) Весь трафик через split-routing с точечным перенаправлением трафика посредством внешней к компьютеру коробочки на openwrt
Я не совсем понимаю такого решения (не сарказм). Если не сложно, можете объяснить чуть подробнее?
Допустим у нас есть телефон -> коробочка -> VPN сервер (или напрямую). Коробочка принимает решение о маршрутизации трафика по доменному имени/адресу назначения.
Любой запрос с телефона, например к api.telegram.com, будет в итоге перенаправлен через VPN сервер. Коробочка же не знает, кто отправитель. Легитимное ПО или шпион.
Учитывая, что на телефоне у нас сетевой интерфейс доступен любому приложению, не смотря на настройки раздельного туннелирования (как на днях выяснилось), то шпион спокойной сможет отправить запрос через обнаруженный туннель.
Либо я неверно понимаю схему?
Почему то сейчас все пытаются в первую очередь защитить от компрометации выходной адрес (да, это важно для сохранения работоспособности), но все предлагаемые схемы (в т.ч. в статье) сохраняют возможность детекции факта обхода блокировки заблокированного ресурса.
Пока меры принимаются только технического характера, это конечно не особо критично...
Тоже активно ковыряюсь в этой теме последнюю неделю. Как понял, суть в том, что детекторы VPN ориентируются на совокупность признаков, чтобы выявить использование VPN наверняка, иначе это грозит false-positive срабатываниями и блокировками всего и вся (что, правда, кажется, периодически и происходит).
Схема с OpenWRT позволяет добиться того, чтобы VPN и его производные туннели на мобильном устройстве, в принципе, были выключены, то есть часть проверок на этом этапе действительно будет отваливаться.
Но вот достучаться приложению-шпиону до заблокированных ресурсов это никак не помешает, это верно.
Ну и тут вопрос что именно вы хотите. У меня, например, большинство кейсов сводится к тому что мне нужно обходить не наши блокировки, а зарубежные. Например зайти на документацию к FastAPI. Причем сделать это так чтобы мне мой рабочий VPN не заблокировали.
Тут весь юмор ситуации в том что мне не нужно обходить Российские блокировки, но РКН очень сильно мешает мне обходить западные...
Если это про fastapi.tiangolo.com - нет блокировок по GeoIP. Есть блокировка TLS ECH Cloudflare в РФ.
В Firefox(Encrypted Client Hello):
about:config
network.dns.echconfig.enabled false
network.dns.http3_echconfig.enabled false
Все отлично.
https://fastapi.tiangolo.comдетекторы VPN ориентируются на совокупность признаков, чтобы выявить использование VPN наверняка, иначе это грозит false-positive срабатываниями
Хорошая идея для саботажа этой схемы: фейковые аккаунты могли бы сливать обычные адреса как задетекченные входные точки квн и так рандомно разрушать связность
Я не верно выразился в части 1) не ходить на VPN через сотовые сети
Правильно будет сказать не ходить через VPN с телефона на котором есть установленное шпионское ПО.
Я сейчас просто не хожу с телефона на котором установлено Российское ПО через VPN. А на рабочем ноутбуке, где мне необходим доступ к зарубежному интернету я снес все что имеет отношение к Российскому ПО.
Раздельный роутинг в рамках такого сценария защищает от кейсов типа "нечаянно по ошибке набрал в браузере яндекс"..
А если в туннель разрешить ходить только приложению? Например говорим что телега может пользоваться туннелем, а остальное нет? Тогда запрос на api.telegram.org пойдет мимо туннеля? Или я что-то не так понимаю?
https://habr.com/ru/articles/1020080/comments/#comment_29790062
Фактически, любое приложение имеет доступ к сетевому интерфейсу, если найдет его (плюс остальные вещи, типа открытого SOCKS5).
Сам факт он узнает, попинговав ютуб, но не сможет узнать точку выхода, так как не может пропинговать чекер. Ошибаюсь ли я?
спай на телефоне может узнать:
да здесь VPN
да ютуб достигается через IP1.2.3.4
Далее РКН может даже забанить IP1.2.3.4
Но от этого VPN работать не перестанет
Это в описанной вами реализации. Но что, если сделать точечный роутинг, например, только до ютуба, а все остальное слать напрямую?
Тогда троян сможет определить только
"Да, здесь VPN" - и то, если перебирает все, что заблокировано
А "ютуб достигается через IP1.2.3.4" он определить не сможет, так как все возможные чекеры будут определять настоящий ip устройства пользователя, а не ip выхода VPN
Не ошибаюсь ли я?
но это банально не удобно.
во-первых, понятие "ютуб" или понятие "яндекс" включает в себя не один, а десятки доменов.
во-вторых, ну вот Вы настроили ютуб. А Ваша мама/бабушка/жена/ребёнок просит chatgpt. Что делаете? снова точечно настраиваете?
я пробовал этот подход. на третьем сервисе надоедает.
мало того, постоянно случаются выплески "ютуб перестал работать с сегодняшнего дня". Почему? потому что в ютубе добавили узел с ещё одним dns.
В итоге вы подписываетесь на список забаненных ресурсов, которые кто-то майнтенит. И строите таблицу на них. Но этот список запаздывает итп (челфактор) и в моменты запозданий из-за "ютуб нужен сейчас, а не завтра" вы переключаете роутинг на режим полной, а не точечной доставки контента.
Благодарю за исчерпывающий ответ.
в ютубе добавили узел с ещё одним dns.
Потому что надо перенаправлять в общем ASN целиком, а не по-доменно. Сразу 5000 префиксов одним махом: https://bgp.he.net/AS15169 и для этого развивать инструментарий, чтобы было не сложнее добавления следующей строчки домена.
если … настроен на обход исключительно конкретных заблокированных ресурсов
Да, не сможет. Точечный роутинг в сторону ресурсов, которые не будут читать методички сами знаете кого, так не палится.
Я думаю троян будет умнее, он просто запросит резолв какого-нибудь сгенерированного домена, который гарантированно пойдет через DNS-туннеля, и спалит выходной адрес через этот DNS-запрос
Нет, это как раз хорошая логика, точечно в туннель, все остальное напрямую. Если сервер твой, то можно ещё на сервере точечно в интернет, все остально заблокировать. Чтобы если кто-то обойдет правила маршрутизации на устройстве все равно имел затруднения в эксплуатации корявого роутинга.
Только есть ещё нюанс, домены за cf имеют технический эндпоинт, вот такой, на примере chatgpt. Но ты можешь его «примерить» и к другим доменам
https://chatgpt.com/cdn-cgi/trace
И такие технические домены и эндпоинты могут все же попадать в список разрешенного
Нет, это как раз хорошая логика, точечно в туннель, все остальное напрямую.
Вы пробовали так делать? Я пробовал и счёл это крайне трудоёмким.
Например, чтобы сделать себе доступ к grok пришлось писать скрипт, который на тот грок зайдёт и вычленит полный список доменов, которые надо пропустить через vpn. Это было около 10 штук.
Так вот, настроил я себе грок. Он недельку поработал и отвалился. Почему? а они добавили какую-то хрень и её надо было тоже добавлять в список роутов.
И так всё: ютуб - несколько десятков адресов, гугл, грок, чатгпт, итп итд
Для этого есть geosite.dat / geoip.dat
"geosite:youtube",
"geosite:openai",
"geosite:telegram",
"geosite:anthropic",
"geosite:google-gemini",
"geosite:x",
"geosite:xai
И не важно какие там домены у ютюба и чатгпт. Списки обновляются и поддерживаются сообществом. xai — это grok
Например, чтобы сделать себе доступ к grok
Который тоже за cf и может стучать?)
В любом случае это лучший из возможных вариантов логики маршрутизации. Сопровождать только для себя реально только для небольшого набора ресурсов ввиду вышеупомянутой трудоемкости
Он может просто дёрнуть страницу ютюба, где явно указан ip клиента https://redirector.googlevideo.com/report_mapping У chatgpt тоже такая страница есть, выше в комментариях указана. https://chatgpt.com/cdn-cgi/trace
Так что этот способ не панацея.
У chatgpt тоже такая страница
У всех доменов за cf, возможно кроме тех кто использует spectrum без расшифровки TLS на стороне cf. Хотя может быть можно и фаерволом "срезать" доступ к этому эндпоинту, не знаю, но это всё равно должен делать владелец сайта
Скрытый текст
https://www.cloudflare.com/cdn-cgi/trace
https://onlyfans.com/cdn-cgi/trace
https://www.fiverr.com/cdn-cgi/trace
https://www.zoom.com/cdn-cgi/trace
https://www.canva.com/cdn-cgi/trace
https://www.uber.com/cdn-cgi/trace
https://chess.com/cdn-cgi/trace
https://www.shopify.com/cdn-cgi/trace
https://www.quora.com/cdn-cgi/trace
https://example.com/cdn-cgi/trace
Список можно продолжать долго, в конце концов CF очень крупный CDN
А вот https://discord.com/cdn-cgi/trace меня не пустил, сообщил "Forbidden"
Да как не сможет?
РКН просто делает клон ipinfo.io, скажем, на spyipinfo.io, банит его, и далее app госуслуг с вашего телефона стучится по этому адресу.
Но ведь в этой схеме всё равно придётся настраивать, какие приложения идут через впн, а какие нет, что уже слишком сложно для родителей-пенсионеров. А если так, то зачем 3 звена? Достаточно 2 и не пускать spyware в тоннель. Оно будет детектить наличие впн, но не сможет спалить выходной узел. Или я что-то не так понял?
Можно вместо второго внешнего vps пустить трафик через cloudflare warp.
Эта схема будет закрыта если закроют доступ к freedom.vpn1 просто потому что.
но тогда придется закрыть доступ ко всем микросервисам и сервисам граждан
И что? Жалко что ли?
думаю, не жалко
но непросто
Жить без Visa и Mastercard тоже непросто. Но пришлось. И вроде живём дальше. Тяжело, но живём же.
Без визы и мастеркард карточные платежи не остановились, спасибо нспк.
Ну опять 25. Хосподи, всегда интересно, как человек смог карму отрастить до возможности ставить минус, а научиться мыслить не поверхностно так и не смог? Уже не первый раз такое вижу. Да понятное дело, и блокировка ютуба не остановила просмотр и загрузку видосиков, спасибо рутубу. Конечно же я про оплату зарубежных сервисов, поездки за границу. Про удобную оплату, а не про костыли вида "сгонять в Казахстан и за 20к оформить бесплатную для своих карту и молиться что бы не заблокировали"
Если всё правильно настроить и весь исходящий трафик из myvpn направлять в freedom.vpn1, а из freedom.vpn1 в freedom.vpn2, то myvpn и freedom.vpn1 будут "невидимыми", а светится будет только freedom.vpn2 и его заблокируют конечно, но смысла в этом не будет так как на него трафик идет из невидимого freedom.vpn1.
Я чёт все равно не понял как работает защита, предложенная автором статьи. Можете подробнее объяснить?
Клиент - myvpn - free1 - free2 - инет.
Spyware
Делает http запрос к ifconfig.me получает в ответе ip freevpn2. Блокирует его. Все, доступа к заблок ресурсам нету
Всё верно, блокирует. Для прямого доступа из России, IP сервера freevpn2 недоступно. Но сервер freevpn1 находится в Европе, а там правила РКН не действуют и он может свободно обращаться к серверу freevpn2. А поскольку, если все верно настроено, сервера myvpn v freevpn1 вообще невидимы, то блокировка freevon2 ни на что не влияет.
А если у вас на freevpn1 стоит панелька 3xui, то можно вообще обойтись без freevpn2, а настроить на Cloudflare WARP прямо в интерфейсе панельки и таким образом скрыть IP сервера free1.
Можно подробнее про cloudflare warp и 3xui , если не сложно или доку где почитать
Схема дорогая и бесполезная стукач просто фиксирует факт использования VPN не заморачиваясь деталями.
При таком бюджете костыль ввиде двух девайсов "скрепного" и "обычного" более предпочтителен.
На данном этапе пока еще не бесполезная и не совсем дорогая, но при сохранении текущей тенденции к дальнейшему закручиванию гаек, возможно что помимо технических мер начнут применять и юридические. Тогда да, кроме как физически разделять приложения на два разных девайса, другого варианта не останется.
Если стукач триггерится просто на поднятый интерфейс tun0, то действительно никакая многослойность не поможет
Если на пользовательском устройстве трафик шпиена маршрутизируется в впн, то он может сначала определить что есть выход в зону .com, т.е. факт наличия впн к запрещенке, а затем через своего агента в зоне .ru получить адрес MY.VPN и дальше его банить.
но использование VPN пока (пока!) не является преступлением
а даже в нацистской Германии делали вид, изображали законность
Ютуб и телеграм официально не запрещены, но замедлять их это не мешает. Что помешает тоже самое проделать с MY.VPN ?
my.vpn - частный сервер. не принадлежит ООО/ИП.
и не доказывается, что имеет отношение к Телеграм.
Допустим вычислили и замедлили, да, незаконнно это, а дальше какие действия? Хостинг скажет у нас все норм, проблемы в где-то в магистральных каналах с которыми у владельца MY.VPN никаких договоров, т.е. ему там ничем не обязаны, кому претензии направлять? На кого в суд подавать?
ну во-первых без ведома хостинга не заблокируют
во-вторых у хостинга с вами договор
в-третьих хостинг находится в одной с вами правовой юрисдикции
я не говорю, что это непреодолимые преграды, я говорю что сложность с этим работать для большого брата куда выше, а потому год-несколько такая схема поживёт
Не факт что хостинг займет сторону клиента. Раньше практически у всех хостингов был в правилах пункт "нельзя использовать для проксирования трафика", т.е. поднимая ВПН этот пункт нарушается и хостинг ничего не обязан, даже наоборот имеет право выключить виртуалку такому клиенту. Как с этим сегодня дела обстоят выяснить не удалось, те хостинги которыми пользуюсь спрятали эти документы, только общие фразы про рассылку спама и нарушении авторских прав.
Поясните а в чём проблема раздельного тунелирования? На смартфоне можно же указать какие приложения будут иметь доступ к vpn а какие будут ходить напрямую. Получается что приложения типа wb или ozon будут видеть белый ip провайдера, а телега и другие будут ходить через vpn.
С точки зрения разрешений на андроиде, вроде как стороннее проиложение может у системы только спросить используется ли в целом vpn, но не его ip или доступ к нему.
Поясните а в чём проблема раздельного тунелирования? На смартфоне можно же указать какие приложения будут иметь доступ к vpn а какие будут ходить напрямую.
в трудоёмкости администрирования.
Вот допустим Вы сделали VPN-сервер и раздаёте его своей семье:
ребёнку-подростку: "настрой вот так" и заглянете через плечо, чтоб убедиться, что сделал правильно
жене: "настрой вот так, потому что это важно", и заглядывать не будете
и так далее.
И всегда найдутся те, кто сам настроить маршрутизацию не сможет, а вам к нему приехать не получается.
Например, пожилые родители, что живут в другом городе.
И вот в вашем VPN-сегменте уже есть узел (а то и не один) со spyware.
так в конфиг v2ray можно заложить правила трафика по geosite, по домену geoip и т.д. И всё это добро на гитхабах выложено и даже актуализируется. На сколько я понимаю, приложение на уровне клиента уже понимает куда маршрутизировать трафик. И эту историю можно распространять в конфиге.
Плюсом ко всему, там можно "подписать" клиента на конфиги, где он отдельным портом с vps будет получать "обновлённую" версию конфига.
Есть уже правила даже от сообщества, прям в приложении
не знаю, как у вас, а у меня сложности с людьми возникают на уровне "скачай v2rayXXX и вставь в него эту ссылку"
Если у Вас получается, то Вам достаточно двукаскадной версии VPN (каскад в России нужен в любом случае, без него ОПСОСы вычисляют VPN и блочат)
Жена, друзья, родственники справляются, даже дети сами. Я сделал небольшую инструкцию со скриншотами, которую рассылаю в сообщениях в месседжерах. По сути им нужно скачать v2ray и отсканить qr-код. В инструкции для каждого клиента другой qr код меняется и всё.
В любом случае же какой-то клиент на "телефон качать", либо выходить из под домашнего wifi только.
Я не считаю ваш способ плохим, чем больше инструкций на хабре тем лучше. Я спрашивал, потому что думал может вы мой способ уже знаете, или его изьяны, и поэтому не используете.
Для меня ваш способ кажется уязвимым именно перед человеческим фактором.
Как быть с неподготовленными пользователями Вы решили.
Но у меня есть ещё и наоборот: чересчур умные. Те, кто держит на своём телефоне 23 VPN (включая мой), переключает между ними, копирует вставляет между ними ссылки и так далее.
Я даже знаю для каких целей ваш способ хорошь. Когда мобильный трафик за рубеж будут тарифицировать отдельно, можно будет ходить через ру сервер, подключённый проводом к проводному интернету.
Т.е. трафик мобильного интернета будет как бы внутри россии, но ходить до домашнего роутера, который будет будет уже с впн и давать доступ к нужным ресурсам.
Нужен микротик или linux сервер дома и один vps.
Нужен микротик или linux сервер дома и один vps.
ещё дома нужен выделенный IP адрес
ну да, именно так
В минимуме трехкаскадная схема может быть сделана на домашнем роутере и заграничном vpn о двух IP адресах
ещё дома нужен выделенный IP адрес
Это не проблема, у всех провайдеров есть доп.услуга "Постоянный IP", стоит 75-150 р. в месяц.
С сентября домены ru только через госуслуги.
А там тут же вопрос к Вам - зачем Вам белый ИП?
Ответить сможете?
Белый IP чтобы не только из дома в инет лазить, но и из инета домой к файлохранилищу домашнему, к компу. Что в этом криминального?
А домены вообще другая тема, с какого перепугу при подтверждении владения доменом кому-то потребуется знание какой IP у меня дома?
Вот у меня дома постоянно включенный компьютер с Linux и в нём несколько сайтов.
А ещё я ИП, офиса у меня нет, и мне нужен доступ на домашний компьютер, когда я у клиента. Или не ИП, а даже самозанятый.
Такой ответ устроит или "ты, гражданин начальник, липовое дело шьёшь"
Поясните а в чём проблема раздельного тунелирования?
Там другая дыра есть: впн клиенты еще и как прокси работают, куда любое приложение может зайти независимо от того включена для него маршрутизация или нет.
я эту статью тоже читал на хабре, и там же в конце указано что v2rayTun разраб обещал это поправить в ближайшее время. Этот клиент я и использую т.к. он самый удобный.
Плюс мне кажется компании площадки, пока без особого энтузиазма будут выполнять требования минцифры, т.к. для пользователей наличие этих приложений становится проблемой.
Объясняли 100500 раз, это фишка андроида. Любое приложение может запросить наличие tun0. Всё, большего не надо. Неважно куда ведет этот тоннель. Важно его наличие.
И тут внезапно tun0 нет, а есть даже не wg0, а amnwg0 или любое другое имя интерфейса по желанию разработчиков.
И в целом вы ошибаетесь. В свежей методичке РКН предписал разработчикам приложений выяснять точки выхода имеющихся туннелей. Найдите, прочитайте и прослезитесь.
Но ведь в tun0, в рамках описанной в этой статье схеме, будет торчать выходной IP от FREEDOM.VPN2. Пусть его блокируют сколько хотят, это не проблема
Утечка сетевого интерфейса подставляет только тех, у кого входной и выходной IP один и тот же
Вот тут ошибаетесь. Как минимум часть компаний очень даже активно старается строить забор вокруг своего же лагеря. За примерами далеко ходить не надо, Билайн вон от проактивности разве что из штанов не выпрыгивает.
Вот тут доходчиво описано https://habr.com/ru/articles/1023352/
Вообще, пока на VPS в РФ нет анализа трафика датацентров, то все заблок. ресурсы и так отлично работают. А если накатить определенный DNS, то еще и западные сервисы заблоченные для РФ открываются.
а миллиарды на тспу случайно не для затыкания этой дыры выделили?
Вроде нет) Но могу ошибаться. Так ТСПУ следят за сотовыми и домашними провайдерами, но за ЦОДы и за хостингами не следят, там все прямо и открыто. Поэтому и известный сайт с видео работает идеально без средств обхода.
Пояснялось, что для увеличения пропускной способности, потому что такой pps не вывозит уже.
Меняем одного Большого брата на три маленьких мужика (тыща руб.) !
Специально зарегистрировался, чтобы прокомментировать.
Я для себя решаю данную проблему на уровне системы Android. Сперва скрыл информацию на уровне bionic libc, теперь разбираюсь с frameworks, хочу ещё дополнительно на уровне системы скрыть vpn. А далее уже можно любой впн использовать с разделением трафика на ру и остальные сегменты.
Похоже, настала пора доставать вновь кастомные прошивки под Android.
Борьба со шпионами работает (частично) с инструментами app-based-routing:
на смартфонах и прочих Linux при указании, какому приложению дозволено гулять в интерфейс VPN, а какому нет.
в Windows сложнее, ибо там нет нативного механизма app-based-riuting, но есть костыли (например, через QoS назначение DSCP-метки для траффика приложений с заданным именем исполняемого файла, а затем на роутере отлавливание этой метки и дальнейшие операции с траффиком согласно правилам.
Первый пункт спорен, ибо недавно публиковались статьи про то, что в Андроиде (да и на афонах) можно-таки простучать VPN-интерфейс в обход указания утилите, кого пускать а кого нет. И без root-прав нельзя прямо запретить приложениям стучать, ибо доступ к iptables без рута закрыт (АFWall в пролете) - только костыли в виде локального VPN. А рут нонче вообще роскошь, многие конторы не дают разблокировать загрузчик. Как минимум, многие ВВК и Huawei смартфоны в пролёте, увы.
Реализую похожую схему, но на своём железе вместо аренды MY.VPN.
Роутер — GL-MT6000 Flint 2 на OpenWrt, стоит в офисе со статическим IP. К нему прицеплен Raspberry Pi как минисервер: крутит VLESS+Reality как точку входа для мобильников, плюс ноды SimpleX Chat (SMP + XFTP) и coturn для WebRTC звонков. Трафик с RPi идёт напрямую на мой VPS на той стороне через VLESS+Reality.
Для SimpleX отдельная история: ноды подняты с доменами на .ru DNS, так что SimpleX с этими серверами работает без VPN — с любой мобильной сети напрямую. При этом через VPS ноды работают глобально, можно переписываться с кем угодно. Но звонки через coturn идут через российский IP — медиатрафик между теми, у кого подключены эти ноды, за границу не выходит. Используем как корпоративный мессенджер — всё своё, никакой зависимости от сторонних серверов.
Не проще ли через обычный роутинг реализовать схему, когда запросы на все российские подсети идут напрямую, а остальное - через VPS?
Если посмотрите, на схемах роутинг упомянут.
Но что если стукач сделает запрос к https://ifconfig.me?
Ну сделает и получит адрес вашего VPS. Что дальше будет делать с этой информацией?
пойдёт стучать, чтобы этот VPS забанили? и здесь в том и вопрос: как продолжить работу после бана.
Мне кажется, это решается дополнительным IP адресом: на один адрес VPS принимает подключение VPN, а с другого ходит в Интернет.
Мне кажется, это решается дополнительным IP адресом
https://habr.com/ru/articles/1022586/
вот статья как раз на эту тему :)
Почти. В той статье предполагается использование 3 серверов (MY.VPN, FREEDOM.VPN1, FREEDOM.VPN2) - это ж огромная задержка будет. Я же предлагаю обойтись одним, просто докупив дополнительный IP.
Да это оптимизация предложенного варианта. Но при условии того что РКН любит банить подсетями, а то что не каждый провайдер даст два ip из разных подсетей - способ перестраховочный.
Я сперва думал о том, что стоит написать об этом, но когда мне самому провайдер выдал второй ip-адрес в подсети /24 с первым - я решил, что это плохая идея. Хотя, возможно, в статье стоило об этом упомянуть.
Если большой брат начнет банить по DPI сам протокол (например, детектить характерный "почерк" xray), то никакие каскады не помогут, пока не начнется обфускация под обычный HTTPS
Как усложнить себе жизнь за свои же деньги))
Трехкаскадный впн крут на бумаге, но на практике у тебя просто в три раза больше точек отказа, а скорость падает из-за постоянной перешифрации трафика
Падает не скорость, а задержка ухудшается. Throughput != latency. До первого сервера -10% на оверхед, а дальше каналы толстые, что все равно.
У меня сейчас ping до Российского узла 2мс, пинг до европейского - 50. Пинг между двумя европейскими - 1мс.
И вот не вижу я проблемы в последнем раундтрипе
Сейчас в процессе выстраивания такой же цепочки. А можете подсказать по конфигам\слоям между узлами? Т.е. клиент-ру это vless reality безвариантно. А как дальше? ру-евро_впн1 тоже vless-reality, а евро_впн1-евро_впн2 vless-grpc? Или это перебор...
Поделюсь своим вариантом. Не использую режим KVN, только режим proхи. Клиент v2rayng с патчем на настройку авторизации для сокс5. Телега умеет ходить через прокси, для части остального использую web-версии приложений по-максимуму: музыка, банки работают. Для чего-то запрещённограмного использую firefox с foxyproxy. На сервере также стоит геоблок.
Самый надёжный способ скрыть ВПН - не иметь ВПН. А иметь браузер нестандартный/ или с хитрым плугином, например(веб версией телеграмма реально на телефоне пользоваться?).
Или вообще виртуальную машину, а уже внутри неё всё необходимое.
в плагине браузера VPN?
или как браузер достучится до забаненного youtube?
>в плагине браузера VPN?
"VPN"/"прокси"/"сервис сжатия контента" - это вопрос терминологии. главное что никакого tun0, да и для физической проверки не так очевидно
если Вы пользуетесь прокси, размещённом вне Вашего localhost, то это приводит к тому, что такой прокси банится роскомнадзором много, много быстрее, чем рассматриваемые в статье случаи. Ибо Вы предлагаете схему 1, что описана в статье.
Ну, условный Firefox может общаться по зашифрованному каналу с внутрироссийским сервером, который общается с казахским, который выходит в интернет через коммерческий VPN (чтоб не палить его адрес(если случайно перепутаешь и зайдёшь на госуслуги)). В firefox 2 профиля - для всего без ничего, и только для youtube с плагином и с темой другого цвета.
Смысл в том, что умение смотреть youtube спрятано в Firefox и никакому условному Максу его никак не видно.
ЗЫ А вот не связана ли активность по перерезанию каналов с появлением у Антропиков универсального кряка к интернету?
На компьютере можно запретить любой программе обращаться одному к сетевому интерфейсу и разрешить - к другому, но в нерутованном смартфоне такой возможности нет.
Ваше предложение хорошо работает, если альтернативный канал сделан на другом устройстве - например, на сервере или даже на маршрутизаторе. Если вам нужно "ходить на ютуб" со смартфона вне дома, ваше решение не работает.
По итогу самое разумное устанавливать youtub вместе с впн в Shelter( https://f-droid.org/ru/packages/net.typeblog.shelter/ ) - условный гражданин Макс снаружи без предоставления дополнительных прав("Доступ к статистике использования") не сможет увидеть даже само наличие Shelter, звонки вроде работают в обе стороны.
Может проще иметь программку, которая будет разрешать определённым приложениям ходить только по своим адресам?
Такая программа называются firewall и она есть в ядре каждой современной ОС. Но она не поможет, если шпионская программа подключится к сокету устройства tun*.
Почему бы не настроить vless на клиенте так чтобы он проксировал только на выбранные сайты?
Потому что человек - существо странное. Сегодня он хочет ютуб. И вроде достаточно этого ему. А завтра взбредёт ему в голову сходить на chatgpt. А послезавтра посмотреть что там у geminy. И так далее.
Шпионская программа подключится к сокету устройства tun* и узнает выходной узел.
Маршрутизировать трафик можно не только по адресам, но и просто на устройство. Защититься от этого можно, но в андроиде штатной защиты нет.
У меня на компе сокс прокси создает vless. Неужели на Андроиде только через tun работает?
если на андроиде раздавать через сокс, то нужно научить все приложения через него ходить, а они по-дефолту этого не умеют.
потому tun - самый популярный вариант
Лично я не использую VLESS - он на Андроиде дырявый и его детектируют операторы VDS, поэтому могу только с чужих слов.
Люди говорят, что клиенты VLESS на Андроиде создают открытый (без авторизации) сокет SOCKS5. Это дырища. Вроде бы уже есть для неё исправления, но пока выйдут протестированные версии популярных клиентов, могут пройти месяцы.
Не совсем понял важность третьего сервера. В случае блокировки придется также арендовать новый "freedom" VDS, как и в схеме с двумя серверами. Единственный плюс - нельзя понять кто использовал этот сервер внутри суверенного государства. Но разве сейчас блокируют отправителей?
Тут уже написали про ipv6. Его использование между двумя VDS даёт большую экономию.
Схема:
Клиент---VPNoverIPv4---VDS1---VPNoverIPv6---VDS2---Интернет
Внутри VPN ходит IPv4
Единственный недостаток - среди российский хостеров мало кто даёт IPv6, да и среди зарубежных далеко не все его дают на минимальных тарифах. Зато у зарубежных хостеров есть такие, кто даёт VDS с IPv6 дешевле, чем с IPv4

Решил погоду посмотреть. КВН на роутере настроен, не для всего подряд, только для адресов ТГ и Вотсап. Т.е. смотрят тупо на доступность адресов. Как в таком случае помогут все эти каскады серверов?
если приложение отказывается работать только из-за детектирования самого факта использования VPN - придётся с этим жить (выключать VPN когда нужно смотреть погоду)
иначе - можно настраивать роутинг на первом узле каскада
Т.е.? Если адрес назначения ТГ, то... то куда надо отправить? Что-то я не очень понимаю логику. Если тупо проверяется доступность серверов телеги, то какая разница каким маршрутом пройдёт этот запрос?
Если тупо проверяется доступность серверов телеги, то какая разница каким маршрутом пройдёт этот запрос?
ну я так и ответил: если spyware проверяет факт наличия vpn именно по доступности телеги, то она будет считать что vpn включён даже если он выключен, но Вы попали в зону доступности Телеграм (например провайдер такой попался или за бугор выехали). В таком случае у вас нет другого выхода, кроме как выключать временно (пока вам нужна эта программа) VPN (и временно же из-за бугра возвращаться)
первый пункт в моём ответе
давайте ссылку
КВН на роутере настроен, не для всего подряд, только для адресов ТГ и Вотсап
не исключено, что баг в настройке
Что-то я не понимаю проблемы со Spyware :) Да, описанная схема хороша. Но можно сделать несколько проще.
Ставим sing-box на андроид.
Ставим shizuku на андроид. Активируем его по внутренней инструкции.
В sing-box идём в настройки - перезапись профиля.
Включаем там shizuku.
Идём в управление. Выбираем режим прокси - "Включить" (т.е. белый список)
Выбираем приложения, например: ChatGPT, Firefox (не является браузером по умолчанию), Telegram, Youtube. Больше мне ничего не надо.
Настройка самого конфига sing-box: inbound tun, outbound vless + sniff префиксов .ru и прочих наших сайтов + днс-ы для ру + днс для внешки.. ну тут уже была статья по такой настройке на хабре, можно найти, если надо.
Всё.
Проверяем:
В Termux tun0 виден - да и пофиг. curl на запрещёнку не работает - проверял (что очевидно, в принципе)
Приложения шпионы знают про включённый VPN, но в него забраться не могут, и что-то там дёрнуть - тоже. Им sing-box через shizuku запретил. Поэтому все мои банки, пятёрочки, озоны, вб - спокойно загружаются. Единственный кто орет - это Дикси. Но, как выяснилось, он орёт на сам факт VPN, даже если там единственный маршрут 192.168.4.0/24 без выхода наружу через эту подсеть :))
Попытаться дёрнуть браузер - но нужно знать, какой. Браузер по умолчанию - Yandex browser :)
Дёрнуть линки по curl с googlevideo/chatgpt - а толку? Они же не через приложение ChatGPT их дёргают, и не через Firefox.
Вот и как бы всё...
Напишите статью - будет полезно кому-то.
Смысл моей схемы в следующем. Я пользуюсь VPN не один. Сперва подключил к нему жену и детей. Потом пара друзей. Потом родители - теща с тестем. Потом...
Сейчас там сидит 30+ человек самой разной квалификации. Кто-то может по инструкции в своём андроиде что-то сделать, а кто-то может только вкл/выкл VPN.
И вот я искал решение, которое будет работать вне зависимости от действий клиента и наполненности его телефона скамом.
как-то так
Писать статью - это же надо потом на кучу вопросов отвечать... Может кто другой напишет? В принципе, текст выше уже готов.
Я понимаю Ваш подход: минимум телодвижений на клиенте. Как обходной вариант двухкаскадной схемы еще стоит отметить просто смену адреса виртуалки в консоли провайдера, если именно он попал под блок :)
Чуть попозже, думаю, действиями на клиенте уже вообще ничего делать не получится.
вот, например, сегодня, думаю, не ошибусь, если скажу, что на 99% устройств стоит тот или иной виджет погоды. Или отображение часов.
В России здесь наиболее популярна Яндекс-погода.
Так вот, что делать, когда часы или погода откажутся работать при включенном VPN?
ставить версию какого-нибудь Сяоме? Ну, например, время она покажет. А погоду?
Идея отличная. Но мне кажется что в разделе "Снижаем стоимость" можно предложить и другой вариант.
Описанная схема с дополнительным IP, как и сказанно, рискует попать под блокировку всей подсети. Мне кажется что как вариант снижение стоимости можно предложить отказ от узла в суверенном государстве, так как он защищает лишь от двух вещей
1. От потенциального ограничения зарубежного трафика мобильного интернета. На мой взгляд это мало реализуемая и слишком раздутая вещь. У половины страны включены автообновления системы и приложений из Google Play, постоянно идут запросы в Firebase и телеметрия. Упомянутые 15гб трафика могут закончится за пару недель, даже без использования заблокированных ресурсов
2. От потенциальной блокировки входного узла из-за походов на зарубежный сервер. Мне кажется, что качественно настроенный VPN (self steal, firewall и т.д.) вряд-ли даст достаточно оснований для блокировки IP. С точки зрения мобильного провайдера трафик будет идти на условное личное фотохранилище. Понятное дело что на той стороне могут совсем обезуметь и блокировать все подряд без видимой причины, вот тут уже наверное стоит подумать о третьем узле
Плюс не стоит забывать о том, что ТСПУ на VPS в суверенном государстве - дело времени. Также нужно помнить о том, что хостеров в суверенном государстве запросто могут обязать отслеживать следы VPN на их машинах. Сделать это довольно просто, учитывая что файлы, связанные с VPN всем известны.
Я бы предложил к рассмотрению следующую схему:
1. Клиент -> FREEDOM.VPN1 -> FREEDOM.VPN2
2. Маршрутизация на клиенте - список ru-blocked от @runetfreedom - в VPN, остальное - напрямую
3. Маршрутизация на FREEDOM.VPN1 - geoip:ru & geosite:ru - block (мало ли у кого-то слетят настройки на клиенте или кто-то нажмет куда-то не туда), остальное во FREEDOM.VPN2
4. Split-tunneling на клиентах (разумеется обновленных, с защитой от утечки SOCKS5)
P.S. Если возвращаться к изначальной схеме с тремя узлами - можно рассмотреть WARP как финальный узел. На сколько я помню он бесплатный, но открытым остается вопрос что там по задержкам
Перечитал свой комментарий и понял что резюмировать его можно следующим образом.
Мне кажется что риски введения ограничения зарубежного трафика, а также риски блокировки грамотно настроенного VPN меньше, чем риски того, что хостинг провайдеров обяжут установить ТСПУ и через cron искать бинарники того же xray или sing-box
Думаю второй вариант наступит быстрее
Разве что данные от провайдеров и приложений-шпионов не начнут объединять для единой эвристики
1. Провайдер знает что я часто хожу на какой-то европейский сервер (входной узел)
2. Приложение-шпион рассказало что в этот же период времени заметило у меня сетевой интерфейс, где торчал IP выходного узла
Сопоставляем 2x2 и блокируем оба узла
Пожалуйста, РКН, не читайте это
Описанная схема с дополнительным IP, как и сказанно, рискует попать под блокировку всей подсети. Мне кажется что как вариант снижение стоимости можно предложить отказ от узла в суверенном государстве, так как он защищает лишь от двух вещей
В этом месте есть ещё одна вещь, я думал о ней все знают и потому упомянул о ней в статье лишь вскользь:
сейчас у большого брата наблюдение сосредоточено именно у сотовых операторов. Они смотрят за трафиком телефон - забугорье.
Да они не могут понять что это за трафик но триплеты
[IP-адрес, SNI, протокол] вынимать они могут. Далее по критериям:
адрес иностранный
ходят много
случайный клиент (проверке подвергаются не все подряд клиенты)
этот адрес попадает к роботу на рассмотрение. Робот посещает этот сайт и осматривает:
показывает google? - vpn
показывает github или иной популярный сайт? - vpn
забыли настроить заглушку? - vpn
и так далее.
то есть просто уйти от досмотра сотовым оператором - полезно. могут заблокировать не утруждая доказательствами что там 100% vpn.
В целом да, уйти полезно. Только получается что мы уходим от досмотра сотовым оператором, чтобы через время прийти к досмотру хостинг-провайдером
Но соглашусь, реагировать стоит тогда, тогда описанные риски оправдаются, а сейчас чем проще, тем лучше
Выбор финального варианта наверное должен зависеть от среднего количества затраченного мобильного трафика всеми пользователями VPN. У меня даже 20гб в месяц не выходит, так что я отваливаюсь на этапе "ходят много". Но тут у каждого свой случай
В целом да, уйти полезно. Только получается что мы уходим от досмотра сотовым оператором, чтобы через время прийти к досмотру хостинг-провайдером
а здесь фича в том что у хостинг-провайдера все сервисы сегодня - микросервисы. если они не пойдут смотреть ps ax прямо на ваш узел то для них все узлы одинаковы
А я как раз про это. Причем даже не процессы смотреть, а просто в директориях бинарные файлы глянуть. Уже известны прецеденты, когда от хостинга людям приходили письма с требованем удалить "нежелательное ПО"
в европе такое распространено
я как-то скачал большой файл (iso образ linux) rtorrent'ом и забыл об этом
а немцы сделали проверку и забанили мой хост за торренты (за факт наличия rtorrent).
сперва на мыло прислали алерт, да только я его не читал...
потом удалили сервер.
с тех пор я сервера предпочитаю держать в Швейцарии, а не Германии
Что ж, ждем лучшие европейские практики на просторах суверенного государства :)
а проброс фридом1 на второй ip на том же сервере как лучше делать? nat forward?
Я попытался сделать в качестве выхода на промежуточном сервере Warp, и оно вроде как неплохо заработало. Т.е. связка такая: русский вдс - зарубежный вдс - варп. У меня там панель 3x-ui. Но к сожалению, кажись, через этот варп не все гладко. Если я один подключаюсь к аккаунту на русском вдс, то все хорошо. А вот если второе устройство на тот же аккаунт на русском вдс - то уже трафик не идет. Может быть, это и не связано с варпом, однако без него использование одного аккаунта (клиента в инбаунде) на разных устройствах не приводит к проблемам. Так что теперь 1 устройство - 1 клиент.
Описанная схема также не очень устойчива из-за симметрии трафика на MY.VPN - практически весь входящий трафик на один IP будет с него также и уходить. Во-первых, РКН может вычислить симметрию, во-вторых, может увидеть к какому IP обращается MY.VPN. Кроме того, симметрию трафика может определить и сам хостер площадки где расположен MY.VPN - элементарно по своим собственным метрикам.
Более устойчивой схема будет если MY.VPN будет иметь два разных IP, желательно на физически разных каналах. Оптимально - домашний инет, подключение к двум разным операторам, на одном из них должен быть белый IP.
Как это все собрать, пошагово, может кто-то написать инструкцию/ скрипт?
Строим VPN, устойчивый к SpyWare