Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 96
Вероятно, из-за наличия заблокированных иностранных ресурсов всегда можно будет вшить в сайт/приложение ББ запрос к ним, который они вернут к ББ, что раскроет наличие ВПН. Думаю, такие сайты будут устраняться аналогично рекламе, но в режиме "второго шага".
если ваш промежуточный узел будет отвечать нормальным сайтом на запрос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 надо приложить усилия
(усилия не к тому чтоб собрать, а к тому чтоб организовать такую возможность)
а по умолчанию никакой роут не собрать
если vpn строится на общепринятых в настоящее время технологиях (xray), то для того, чтобы показать маршрут tracert надо приложить усилия
Что, тот же LanDroid не сможет выполнить трассировку до хоста, доступного через VPN, при работе VPN через tun?
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-сервер. Деньги на дне бидона. Это может работать.
Берется просто сим-карта с роумингом и не нужен не какой 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 мс. Пруфов не будет (господин жандарм, подите прочь делать сами свою сыскную работу, с вас тошно-с), но проверить мои слова может каждый собственным экспериментом.
А точно ли провайдер не видит квн? У меня есть пример с местным провайдером в одном городе. Вот на какие конфиги хватило фантазии: 1) ru-blocked на свободу, остальное в директ; 2) то же самое, но YouTube отдельно в прокси от byebyedpi (по сути директ с порчей пакетов); 3) ru-blocked на сервер в России (как тут на схемах) и оттуда на свободу, остальное прямо с устройства в директ. Минуту работает YouTube, после чего интернет накрывает белым списком (да-да, проводной!): не работает даже поиск в гугл, но вк без проблем. После перезагрузки роутера интернет опять работает (серый и белый), но стоит загрузить что-нибудь в YouTube - опять белые списки. Пока не могу разгадать, на моем провайдере все три конфига работают. X-ray+VLESS+Reality
Объясните мне зачем городить такой огород? Есть более простыре решения, а именно: раздельное туннелирование на 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/
Я не пойму одного, столько всего городить, а все будет проще, "шпиен" -> "андройд у тебя сетевой интерфейс квн" -> "Да сэр" -> "квн детектед".
Уважаемые коллеги! Вам не приходило в голову, что все эти ваши трёхзвенные схемы легко вскрываются, стоит только заняться анализом статистики соединений? Вы же, наверно, в курсе, что есть такая замечательная вещь, как 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, и ничего Вы с этим сделать не сможете.
Ведь долбитесь же, да? Ага, я так и думал. Так что адрес этого самого FREEDOM.VPN1 вы спалите просто самим фактом постоянного трансграничного трафика между ним и MY.VPN.
Здесь Вы правы и не правы одновременно.
Да факт соединения - спалится. Но что это за соединение? Обычная часть микросервисной архитектуры, где микросервси стучится в другой? Или это VPN?
Было бы можно такое отличить методом анализа трафика, разве стали бы они городить огород со стукачами?
(об этом и в статье написано)
Да факт соединения - спалится. Но что это за соединение? Обычная часть микросервисной архитектуры, где микросервси стучится в другой? Или это VPN?
Было бы можно такое отличить методом анализа трафика, разве стали бы они городить огород со стукачами?
Зачем отличать? Блокируем, а затем внимательно слушаем эфир: если снизу начинают раздаваться действительно массовые злобные истеричные выкрики, слышно, как кто0то швыряет в стену телефонный аппарат, кто-то в сердцах хлопает дверью, а потом нам звонят сверху и вежливым матом объясняют, что мы наступили ногой на горло бизнесу уважаемых людей, и эти уважаемые люди уже вот прям щаз теряют кучу бабок в минуту — значит, мы заблокировали что-то не то. Тут важно, чтобы низы и верхи взбунтовались одновременно. Если бунтуют только низы и в микроскопических объёмах — значит, мы нащупали и пристрелили чей-то микроскопический бизнес по продаже услуг того самого трёхзвенного VPN.
Всё нормально, это древний и весьма уважаемый способ составления правил межсетевого экрана в информационных системах, когда никто из сотрудников уже не в состоянии внятно объяснить, кто и куда должен иметь доступ и по каким протоколам, потому что никто не знает, как и что устроено ввиду того, что критически важные элементы инфраструктуры разрабатывались и внедрялись лет десять тому назад, на коленке и без надлежащего документирования, а кто знает, тот уже не помнит, а кто ещё помнит — те давно релоцировались: редкие счастливчики — в верхние эшелоны мегакорпораций, и теперь им нельзя просто так взять и позвонить, кто на удивительное Бали, кто в психушку (ночные смены и работа по двенадцать часов в сутки, ага), а кто и вообще на кладбище.
Шучу. А может, и не шучу ;)
Да, до некоторых хомячков начала доходить банальность, что вход и выход могут использовать разные IP-адреса (тут самое время задуматься, кстати, почему кое-кому поддерживать IPv6 становится противоестественно — что прямо даёт ответ на вопрос о перспективах развития этого протокола в РФ). По этому поводу пишется мега-портянка с пафосом официального пресс-релиза испанского двора. И да, как справедливо указано выше, корреляцию между трафиком это не решает. Пульс детектируется на выходе из смартфона, даже если он летит не туда, откуда потом прилетает. Усложняет ли это блокировку входного узла — несомненно. Но если система наблюдает, что ваш смартфон долбится в одну дверь, а при этом такой же стук раздаётся на другой, то сопоставление технически реализуемо. Апп-стукач может даже постукивать по шаблону, чтобы повысить шансы на верный детект, без false positives.
Во всех статьях на эту тему не вижу простой мысли. Троян не сможет слить выходной адрес, если 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 не заблокировали.
Тут весь юмор ситуации в том что мне не нужно обходить Российские блокировки, но РКН очень сильно мешает мне обходить западные...
детекторы 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.
В итоге вы подписываетесь на список забаненных ресурсов, которые кто-то майнтенит. И строите таблицу на них. Но этот список запаздывает итп (челфактор) и в моменты запозданий из-за "ютуб нужен сейчас, а не завтра" вы переключаете роутинг на режим полной, а не точечной доставки контента.
если … настроен на обход исключительно конкретных заблокированных ресурсов
Да, не сможет. Точечный роутинг в сторону ресурсов, которые не будут читать методички сами знаете кого, так не палится.
Но ведь в этой схеме всё равно придётся настраивать, какие приложения идут через впн, а какие нет, что уже слишком сложно для родителей-пенсионеров. А если так, то зачем 3 звена? Достаточно 2 и не пускать spyware в тоннель. Оно будет детектить наличие впн, но не сможет спалить выходной узел. Или я что-то не так понял?
Можно вместо второго внешнего vps пустить трафик через cloudflare warp.
Эта схема будет закрыта если закроют доступ к freedom.vpn1 просто потому что.
но тогда придется закрыть доступ ко всем микросервисам и сервисам граждан
Если всё правильно настроить и весь исходящий трафик из myvpn направлять в freedom.vpn1, а из freedom.vpn1 в freedom.vpn2, то myvpn и freedom.vpn1 будут "невидимыми", а светится будет только freedom.vpn2 и его заблокируют конечно, но смысла в этом не будет так как на него трафик идет из невидимого freedom.vpn1.
Схема дорогая и бесполезная стукач просто фиксирует факт использования VPN не заморачиваясь деталями.
При таком бюджете костыль ввиде двух девайсов "скрепного" и "обычного" более предпочтителен.
На данном этапе пока еще не бесполезная и не совсем дорогая, но при сохранении текущей тенденции к дальнейшему закручиванию гаек, возможно что помимо технических мер начнут применять и юридические. Тогда да, кроме как физически разделять приложения на два разных девайса, другого варианта не останется.
Если на пользовательском устройстве трафик шпиена маршрутизируется в впн, то он может сначала определить что есть выход в зону .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.
Поясните а в чём проблема раздельного тунелирования?
Там другая дыра есть: впн клиенты еще и как прокси работают, куда любое приложение может зайти независимо от того включена для него маршрутизация или нет.
я эту статью тоже читал на хабре, и там же в конце указано что v2rayTun разраб обещал это поправить в ближайшее время. Этот клиент я и использую т.к. он самый удобный.
Плюс мне кажется компании площадки, пока без особого энтузиазма будут выполнять требования минцифры, т.к. для пользователей наличие этих приложений становится проблемой.
Вообще, пока на 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 смартфоны в пролёте, увы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Строим VPN, устойчивый к SpyWare