Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 51
А можно имя tun интерфейса генерировать случайное? Не tun0 а какой-нибудь xyq0? Шпиён конечно все равно список интерфейсов может получить, но так вроде меньше палимся...
Зарегистрировался на Хабре только для того, чтобы выразить свой респект
Куда копать дальше? Думаю что все просто, куда душа хочет, туда и лопату втыкай =) Проект же для души, а не для отчетности. Можно порыться в DNS утечках возможных, пошукать kill switch, чтобы если что "тушило свет и топтало фазу".
В любом случае, спасибо за опенсорс, без попыток срубить денег на каждом чихе.
А этот клиент умеет сам разворачиваться на сервере (как Amnezia VPN)?
В sing-box похожего можно добиться через правила маршрутизации с версии 1.14.0 https://sing-box.sagernet.org/configuration/route/rule/#package_name_regex
{
"package_name_regex": [
"^"
],
"invert": true,
"action": "route",
"outbound": "block"
}Правило сработает, если не удается распознать имя приложения (при SO_BINDTODEVICE).
Интересно, спасибо за ваш труд. Скажите, в чём идея маршрутизации по GeoIP/GeoSite? На первый взгляд кажется, что это задача самого xray-core.
Амнезия бы прикрутила такую же логику проверки UID приложения.
Получается проблема касается только тех впн-серверов, где inbound и outbound адреса одинаковы? Если используются каскады впн, то входящий адрес сервера не опрелить через эту уязвимость?
Определится любой сервер, через который выпустили ваш пакет в мир
Учитывая, что чаще всего это российские пакеты через сервер внутри страны и иностранные где-то ещё, у нас есть обоснованное предположение, что пакет либо будет выходить сразу, либо будет маршрутизироваться таким образом. Остальное - как крокодил в Москве, существует в паре зоопарков и у некоторых любителей.
Поэтому мы проверяем ip через амазон, проверяем через яндекс либо своё что-то - и имеем либо один, либо два адреса, которые с огромной вероятностью принадлежат впн серверам. Увернуться от такого поможет только намного более нестандартная конфигурация
Достаточно иметь 3 хоста - один в России, два в другой стране (или там один хост, но с двумя IP адресами).
На хосте в России стоит проброс трафика на внешний хост1 (хоть через iptables, хоть через прокси типа haproxy).
На внешнем хосте1 стоит аналогичный проброс трафика на внешний хост2.
На внешнем хосте2 стоит VPN сервер.
Самая простая и надёжная конфигурация.
Если хочется посложнее и выпускать часть трафика в России - нужен второй хост в России, т.к. IP адрес хоста1 РФ будет уже засвечен и для трансграничной передачи его использовать нельзя.
Итоговая схема будет клиент => [хост 1 в России, он же выпускает часть трафика в России] => хост2 в России => хост1 вне РФ => хост2 вне РФ => выход в интернет
На хосте в России стоит проброс трафика на внешний хост1 (хоть через iptables, хоть через прокси типа haproxy).На внешнем хосте1 стоит аналогичный проброс трафика на внешний хост2.На внешнем хосте2 стоит VPN сервер.
Зачем в вашей схеме на последнем хосте (внешнем хосте2) VPN сервер?
В точке выхода нужно обратиться по целевому адресу и в обратную сторону прислать ответ. Организация такого взаимодействия с помощью ВПН и производится.
Вы же не просто до внешнего хоста2 хотите дойти, а выйти через него дальше в интернет.
del
Мы же до точки выхода как-то без использования ВПН дошли, зачем нам для обратной стороны нужен ВПН?
Или вы имеете ввиду, что напрямую мы идём через несколько хостов через iptables/haproxy, а обратку мы через ВПН получаем?
Или я не могу сообразить ничего)
Просто выглядит так, что у нас на последнем хосте стоит ВПН, а до него мы же как-то добрались и без ВПН (судя по "схеме", на других серваках его нет), соответственно, этому последнему серваку не нужен ВПН, чтобы запросить веб-контент и отдать его нам обратно.
Либо в этой схеме что-то не так, о чём я изначально и думаю
У вас на начальном устройстве стоит ВПН и он "заворачивает" все ваши сетевые запросы (ну или часть) в адрес первого сервера, а там сетевой туннель, который проходит через несколько хостов и приходит в конечный хост, на котором ВПН сервер. Этот ВПН "разворачивает" ваш оригинальный запрос и от своего адреса шлет по назначению. Ответы в обратную сторону так же проходят.
Не знаю как еще пояснить.
Ну в вашем описании всё понятно, да. Но в комментарии, на который я отвечал - этого не было. Там нигде не сказано, что на начальном устройстве стоит ВПН. Там сказано:
На хосте в России стоит проброс трафика на внешний хост1 (хоть через iptables, хоть через прокси типа haproxy)
На внешнем хосте1 стоит аналогичный проброс трафика на внешний хост2.
А сам ВПН упоминается только на последнем звене цепочки.
Не знаю, как-то надо чётче формулировать карту сети...
В схеме с VPN в первую очередь палятся 2 IP адреса: входная точка (её можно определить даже по подозрительно высокой активности на уровне пользователя) и exit нода (её точно поймают).
Наличие одновременно IP адреса exit ноды + сессии с подозрительным адресом входной точки сразу же идентифицирует VPN.
Именно поэтому нам нужно сделать так, чтобы точка входа и exit node'а не были связаны напрямую. Самое простое - VPN сервер поставить на exit node'е, а транзит пускать через цепочку хостов iptables/haproxy, примерно так:
клиент ==> [входная точка, iptables NAT на host2] ==> [host2: iptables NAT на ext1] ==> [ext1: iptables NAT на exit] ==> [exit: VPN сервер] ==> интернет
Это не самая обычная. Самая обычная - это 1, в крайнем случае 2 хопа. А эту я имела в виду, но так и сказала, что она редка как крокодил в Москве - потому что стоит раза в два дороже и не все смогут настроить даже из тех, кто сам впн себе ставит
Любой пакет, чей UID нам не подошел или который мы вообще не смогли определить, безжалостно дропается.
Интересно посмотреть лог и посмотреть на список тех приложений, которые стучаться через SO_BINDTODEVICE. И удивиться, если там будут не только российские приложения.
Заметил, что teams игнорит сплит туннелинг и идёт в лоб, даже если стоит в исключениях на впн. Видать тоже что-то подобное задействуется, когда он сам выбирает, через какой интерфейс выходить в интернет
А можно попросить добавить поддержку ByeByeDPI для избранных приложений? :)
Появится удобная возможность в режиме split tunnel добавить youtube в один список (bye bye), другие приложения в другой (vless).
Любой пакет, чей UID нам не подошел или который мы вообще не смогли определить, безжалостно дропается.
Зачем? Просто выводите его напрямую с IP девайса.
Шпион пробует выйти в инет именно через tun-девайс. Даже если пакет отрероутить в обычный интернет - прога может передать ГэБисту, что “tun есть, но работает только для списка приложений, а нас, хороших собачек, выплёвывает в обход его”, а пользователю выдать “ой вей, ви таки используити запрещённые средства обхода, отключити их!” и повиснуть. (Привет сберу и, внезапно, магниту, и запомните — Yggdrasil это не ВПН, гады, задрали уже! Нехрен блокировать работу, если зачесалась правая пятка на левой верхней ноге, псы, tun0 это не обязательно впн!)
Я понимаю, через что пытается выйти шпион. Нет причин просто не перенаправить его через родной IP, вместо роутинга дальше на VPN. Это незначительно больше усилий в коде.
tun есть, но работает только для списка приложений, а нас, хороших собачек, выплёвывает в обход его
Позвольте, а чем дроп подключения лучше? "Ой, tun есть, но ничего не открывается через него - НАВЕРНОЕ ПОКАЗАЛОСЬ" - так чтоли? :)
А почему там в tun что-то должно быть? Может там контент фильтр для ребенка, а может там антивирус, а может там служебный корпоративный ВПН через который не работает интернет и т.д.
А почему там в tun что-то должно быть?
Потому что в отличие от винды и линукса, где сетевые девайсы светят голой жопой на всю систему просто прикола ради (привет сотне veth* в ip a), на Android живой tun подразумевает включенный в системе VPN?
Может там контент фильтр для ребенка
Отбивающий все запросы? Интересный фильтр.
а может там антивирус
И что антивирус имеет против сервиса для проверки IP? Или тем более против сервиса VK? Может, это вражеский антивирус?
а может там служебный корпоративный ВПН через который не работает интернет и т.д.
Тогда подключение просто упадет по таймауту скорее всего.
В любом случае, РКН нелояльно относится к трафику, который льется на сайты, где "ничего нет", и которые его отбивают. Не сомневайтесь, с не пускающими их никуда tun интерфейсами у них разговор будет такой же короткий.
Если ваш tun ведет себе нестандартно (а не пускать через себя - это нестандартно настолько, что даже не все впн клиенты научились так делать!), значит что-то тут нечисто.
Android живой tun подразумевает включенный в системе VPN
Нет. Лишь виртуальный сетевой интерфейс, который можно использовать хоть для чего. Хоть адблок, хоть антизапрет, хоть докер, хоть для отладки юзаю)
Отбивающий все запросы? Интересный фильтр.
Да. Разрешающий лишь условно 2 сайта и пару часов в день.
И что антивирус имеет против сервиса для проверки IP? Или тем более против сервиса VK? Может, это вражеский антивирус?
Может потому что он не разрешил всем подряд в себя лазить?
Тогда подключение просто упадет по таймауту скорее всего.
Именно так и произойдет
Ну смотрите, я вам сказал, что висящий бесхозный tun подозрительнее интерфейса, который просто выпускает запрос сразу напрямую - дальше дело ваше. :)
Завершите пожалуйста мысль) "висящий бесхозный....сразу напрямую-дальше дело ваше". Я правда ничего не понял)
У вас есть два варианта: либо tun куда-то ведет (как буквально все vpn-ы, которые не патчили), либо никуда не ведет (человек сидит со включенным впн без интернета, или специально пропатчил впн клиент).
Вы выбрали самый подозрительный вариант :)
С опозданием, но всё-таки я попробую немного раскрыть мысль предыдущего комментатора. Ключевой момент: вы оба по-своему правы) Есть два разных взгляда на вопрос:
1. Связка "список сетевых интерфейсов с наличием в нём tun0 + отлуп при попытке использования этого tun0" однозначно дают понять, что тут дело нечисто, возможно кто-то пытается противодействовать телеметрии.
2. Пункт 1 неактуален, поскольку на интерфейсе tun0 может также висеть условный Adguard или какой-нибудь firewall при отсутствии root доступа.
Решение: в качестве компромиссного варианта предлагаю отправленный в tun0 пакет из "неправильного" приложения не дропать, а перенаправлять на _случайный_ ip (возможно ip + порт) или какой-нибудь публичный пул прокси. Такое поведение с одной стороны отменит фактор риска из п.1 с недоступностью tun0 для приложения, а с другой - равномерно "размоет" ответы от левых адресов до уровня шума, на который нейросеть заинтересованных лиц никогда не сработает по чисто статистическим причинам.
Решение было придумано за 2 минуты буквально на коленке, поэтому требуется дополнительная проверка его эффективности и не является какой бы то ни было технической или любой иной рекомендацией (на всякий случай). Ну и да, сразу извиняюсь за длиннотекст и некрокомментарий.
Есть ли поддержка обычного socks5?
Пользуюсь. Приложение кайфовое, спасибо вам!
Попробовал, при подключении отваливается частный DNS сервер, почему? Тот же Happ или Exclave нормально работает с частным DNS сервером
А я все ждал - когда же подобное появится в клиентах или статья про это)
Я сделал подобное у себя в клиенте примерно недели 2 назад, внеся патч в hev-socks5-tunnel:
https://github.com/derundevu/yaxc
с UDP не стал даже разбираться, оставил чисто TCP
Оно давно появилось, просто статья появилась лишь сейчас. https://habr.com/ru/articles/1022422/#comment_29831814
А почему с UDP игнорируете? это ведь и quic, и аудио\видео связь, и гейминг и многое другое.
Как Вы и сказали, "с UDP все намного сложнее". Нет особо времени, чтобы заниматься этим сейчас, надеюсь, руки дойдут.
Посмотрел коммент по ссылке, я позже добавил – 20 апреля.
Я немного удивлен, что этого еще нет в популярных клиентах. Но радует, что есть уже решения, которые закрывают дыру, и что про них узнают люди) Звезду поставил, может, поможет продвижению клиента и статьи вверх
Роскомнадзору надо премию Сахарова за этот год дать. За вклад в развитие гражданского общества) Столько людей в едином порыве обходы блокировок пилят!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда пет-проект выходит из-под контроля: пишем свой tun2socks и закрываем дыры в Android VPN