Почему подключение VPN для одной программы снимает ограничение у всей сети?
Я пользуюсь домашним интернетом на своем ПК. Как-то раз решил включить десктопный VPN, чтобы скачать файлы через одну конкретную программу (в VPN настроен tunnel - он работает только для одной программы).
Пока качался файл, я запустил браузер и открыл заблокированный сайт. Когда сайт открылся, я внезапно понял, что забыл активировать браузерное расширение, а сайт все равно открылся. Я перепроверил IP - у браузера он не менялся. Один тот факт, что VPN просто запущен для другой программы, повлиял на всю сеть (хотя повторюсь - IP в браузере не менялся, расширение не активировано).
У меня мало знаний в этой области, но есть подозрение, что это как-то связано с DNS. Припоминаю, что слышал что-то еще о маршрутизации, но ответа в поисковике так и не нашел.
Итак, вопрос: почему включенный VPN для одной конкретной программы снимает ограничения на доступ к некоторым заблокированным сайтам для всей сети ПК?
Ziptar, правильно ли я понял: VPN работает на более низком уровне (L3) и влияет на сетевую маршрутизацию (и, получается, DNS), независимо от настроек программ (L7). То есть запросы к DNS-серверам стали проходить через VPN, даже если сам трафик браузера шел напрямую?
Qeinzo, DNS это тоже L7. И это не то, что является для тебя проблемой в данном случае. Маршрутизация с DNS связаны... косвенно.
Я почитал комменты ниже - Split Tunneling это надстройка, и работает она там же - на L7, как её реализует софт каждого конкретного сервиса - это вопросы к этому конкретному сервису с его софтом. А реализован он может быть очень по-разному, и в режиме сплиттинга для отдельных приложений вообще не факт, что тут хоть как-то задействована DNS.
Нет вы ошибаетесь, VPN это инкапсуляция и не более, реализация зависит от ос
В Линукс есть namespaces, множественные таблицы маршрутизации, модули ядра, которые могут направлять или маршрутизировать трафик в зависимости от пользователя, под которым запущено приложение
Это стандартная функция для Android и Windows, где файрволлы для приложений были ещё в 200х
Нет вы ошибаетесь, VPN это инкапсуляция и не более, реализация зависит от ос
Инкапсуляция - это очень общее понятие, проходящие насквозь через всю модель OSI, начиная с физического уровня. TCP инкапсулирован в IP, IP инкапсулирован в Ethernet-фрейм, между ними вланы, l2/l3 туннели, и прочее и прочее.
VPN - это именно что технология, предоставляющая L2 или L3 коммуникацию поверх существующих L2 или L3 сетей.
В Линукс есть namespaces, множественные таблицы маршрутизации, модули ядра, которые могут направлять или маршрутизировать трафик в зависимости от пользователя, под которым запущено приложение
Только работает она на L7.
Это стандартная функция для Android и Windows, где файрволлы для приложений были ещё в 200х
Любой фаервол работает на L7.
Ты плохо понимаешь концепцию. Более низкие уровни по OSI ничего не знают о более высоких, но более высокие прекрасно осведомлены о более низких, и могут влиять на их работу так или иначе.
Сам по себе VPN - это технология, работающая на L2 или L3 с предоставлением L2 или L3 сервисов. Не выше, и не ниже. Всё прочее - надстройки с более высоких уровней, преимущественно с прикладного, включая и DNS, и даже DHCP, и тем более фаерволы, работающие с приложениями, и прочие средства L7 фильтрации.
Жаль, что вы не понимаете ни меня, ни автора вопроса. А именно того, что технологии per app маршрутизации (и последующего заворачивания куда угодно, в тч в тоннель на любом L) существуют штатно и в Android, и в Windows
Петровский, говоря о технологиях per app маршрутизации вы говорите не про VPN, только и всего. Я буду учить вас правильно использовать термины, и правильно понимать, как что устроено, а не плодить ментальные шорткаты, приводящие к ошибкам.
в тч в тоннель на любом L) существуют штатно
Туннель на l7 - это ssh туннель, например. Никакого отношения к технологии VPN это не имеет.
В частности под Android существуют многочисленные тн non root firewall, которые через штатное API поднимают "VPN" (с точки зрения API) до localhost, а затем разруливают трафик так, как хочет пользователь
Только как это отвечает на вопросы Опа, неясно, а именно «почему»
Именно что отвечает - vpn тут ни при чём, сама технология работает точно так, как должна. Вопросы к надстройкам, в данном случае к split tunneling, который реализует кто как хочет. Вот там и решать - у тех, кто реализовывал. Никаких других ответов тут быть не может.
Петровский, если технология не предоставляет L2 или L3 сервисов - это не VPN. Если технология предоставляет что-то помимо L2 и L3 сервисов - впн заканчивается на них, а всё прочее - надстройки, не имеющие отношения к VPN.
Вопрос о каналах связи, по которым идёт туннель - дискуссионный.
Если человек задаёт вопрос про VPN - он по-умолчанию говорит об этом общепринятом стандартном определении, а не о самопальных надстройках различных сервисов.
На этом всё.
Так и решайте, помогите ОПу
Я не работаю ни в одном из впн-сервисов, которые колхозят свои сплит-туннелинги. При чём тут я?
> Если человек задаёт вопрос про VPN - он по-умолчанию говорит
По умолчанию человек хочет обойти блокировки с раздельной маршрутизацией, per app или по домену, а не слушать вот это вот
Я - нет. А вот ты упорно пытаешься смешать и без того не всегда чёткое разделение различных уровней OSI в одну общую кашу.
По умолчанию человек хочет обойти блокировки
И при чём тут обход блокировок?
с раздельной маршрутизацией
Маршрутизация per se работает на l3, она кроме IP-адресов ничего не знает в принципе. То, что различные надстройки могут менять банальную, тупую, примитивную таблицу маршрутизации по любым мыслимым критериям - это не меняет ни того, что маршрутизация продолжает работать на l3, ни саму её суть.
а не слушать вот это вот
Не слушать "вот это" - гулять в сторону ответов мейл ру.
В очередной раз повторяю: с проблемами split-tunneling - в саппорт конкретного используемого сервиса. Никаких общих ответов и решений тут быть не может.
> и без того не всегда чёткое разделение различных уровней OSI
Поэтому просто забудьте о ней, на Cisco не работает vless, тут не об этом
>Маршрутизация per se работает на l3,
Маршрутизация работает вообще везде, на уровне конфигов nginx, на уровне эндпойнтов API , на уровне общения, где угодно
Поэтому просто забудьте о ней, на Cisco не работает vless, тут не об этом
А в тайге не живут кашалоты. При чём тут это? И нет, я не собираюсь "забывать" о модели OSI, которая не всегда чётко, но всё ещё отлично работает, и помогает понимать, что к чему относится, и как это что-то соотносится друг с другом.
Маршрутизация работает вообще везде, на уровне конфигов nginx, на уровне эндпойнтов API , на уровне общения, где угодно
Сетевая, она же IP маршрутизация, работает ТОЛЬКО на l3.
> ТОЛЬКО на l3
Маршрутизация это широкая концепция и работает где угодно. IP маршрутизация работает на l3, но не обязательно маршрутизировать именно ip
Конкретное приложение использует стандартные функции per app маршрутизации трафика конкретных ОС
Да неужели? А в винде эти стандартные функции где? А ты уверен, что они используют стандартные функции? А если проблема в них - то может проблема таки в, например, namespaces, а не в vpn? А не зная, как конкретный велосипед namespaces задействует - ты как собираешь проблемы с ним решать?
Это так не работает.
---
лирическое отступление
чем дальше в лес - тем толще партизаны
чем выше уровень по OSI - тем сложнее решать проблемы, потому что каждый лепит во что горазд; на l2-l3-l4 можно найти common ответы на вопросы по технологии, на l7 это уже становится роскошью, когда речь идёт не об общепринятых и общеиспользуемых приложениях, являющихся гласным или негласным стандартом. Сплит туннелинг велосипеды к таким не относятся, увы. Вот если бы автор делал самостоятельную реализацию общедоступными инструментами - тогда да. А так нет. Но проблема самостоятельной реализации в том, что она достаточно трудоёмка и её нужно регулярно корректировать под меняющиеся реалии.
---
Без электричества проскочить тоже не в состоянии, однако это не повод обсуждать состояние батарейки пользователя
namespaces это просто пример для вас. Как конкретно это реализуется в Android я не знаю. Но предполагаю, что есть комплекс вызовов API для того, чтобы организовать "VPN" -- полный перехват всего трафика, и соответствующие высокоуровневые разрешения для таких приложений
Файрволлы в Винде показывают окошко: приложение какое-то хочет обратиться к такому адресу (или даже домену) по такому -то порту. Причём делают это в userspace конкретного пользователя
>как собираешь проблемы с ним решать?
Поскольку у меня свой VPN (l2-3-7, я хз), я не собираюсь. Но мониторю темы, и вот ответил вам
Также на постоянной основе использую маршрутизацию на основе SNI
namespaces это просто пример для вас. Как конкретно это реализуется в Android я не знаю. Но предполагаю, что есть комплекс вызовов API для того, чтобы организовать "VPN" -- полный перехват всего трафика, и соответствующие высокоуровневые разрешения для таких приложений
Зуб даю, что без рута андроид тебе такого не позволит.
Файрволлы в Винде показывают окошко: приложение какое-то хочет обратиться к такому адресу (или даже домену) по такому -то порту. Причём делают это в userspace конкретного пользователя
То, что окошко, будучи запущенным с системными привилегиями, можно показать любому пользователю в любой сессии - не новость. Не уверен, можно ли получить список соединений без повышенных привилегий, но без них точно даже блокировать соединения нельзя. А уж чтобы назначить кастомную таблицу маршрутизации для конкретного приложения - про такое уже винда не в курсе, и это всё собственные велосипеды.
Поскольку у меня свой VPN (l2-3-7, я хз), я не собираюсь. Но мониторю темы, и вот ответил вам
К сожалению, ответ не демонстрирует понимания вещей.
Также на постоянной основе использую маршрутизацию на основе SNI
А вот тут мне уже интересно. Чисто по SNI, или с использованием списков ip-адресов? По логике вещей нельзя сменить маршрут для https соединения, которое уже пытается стабилизироваться, но я читал байки о том, что всё-таки можно.
>Зуб даю, что без рута андроид тебе такого не позволит.
И Android, и iOS позволяют такое без рута
>К сожалению, ответ не демонстрирует понимания вещей.
Ну почему же? От awg до набора китайских говнопротоколов, каждый из которых работает на хз каком уровне, но, вероятно, представляет tun. Вникать желания нет
>Чисто по SNI
Конечно, caddy стоит и раскидывает по хостам входящие вопросы
>не демонстрирует понимания вещей.
Зря вы так агрессивно, мы же тут удовольствие получаем от помощи людям, а не сремся друг с другом
Ну почему же? От awg до набора китайских говнопротоколов, каждый из которых работает на хз каком уровне, но, вероятно, представляет tun. Вникать желания нет
Я уже сказал всё на эту тему. Как правило, если предоставляет вирутальный интерфейс - значит предоставляет l2/l3 сервис, значит подходит под определение vpn. Но, снова, это не значит, что к технологии относятся надстройки вроде сплит туннелинг.
Конечно, caddy стоит и раскидывает по хостам входящие вопросы
Caddy is an extensible, cross-platform, open-source web server
Какое нахрен sni, это банальный прокси. "Маршрутизация на основе sni" - это не пропускание соединений через прокси, а чтение sni из пакета l7 фильтром, и назначение соответствующего маршрута. К сожалению, по логике вещей, опять же, напрямую это не работает, только во второй и последующих итерациях, когда можно назначить маршрут уже по ip.
Зря вы так агрессивно, мы же тут удовольствие получаем от помощи людям, а не сремся друг с другом
К истине ведёт только срач, а не удовольствия от помощи или общения.
> Туннелирование отдельных приложений?
Полный перехват всего трафика, с получением информации об источнике
>Как правило, если предоставляет вирутальный интерфейс - значит предоставляет l2/l3 сервис,
А socks2tun?
Это вообще несвязанные вещи, tun это элементы внутреннего устройства ос, не имеющие отношения к собственно сети
>банальный прокси
Так прокси это и есть маршрутизатор :-D
Полный перехват всего трафика, с получением информации об источнике
Ну может быть, про телефоны не очень в курсе.
Это вообще несвязанные вещи, tun это элементы внутреннего устройства ос, не имеющие отношения к собственно сети
Tun и tap это буквально драйверы виртуальных сетевых интерфейсов. Tap для l2, Tun для l3.
А socks2tun?
Это хреновина, которая предоставляет конечному пользователю функционал прокси сервера, имея под капотом нормальный впн с l3 сервисами? Чисто технически это впн, но чисто практически - с переломанными ногами.
Да вот так - нет, это не маршрутизатор. Маршрутизатор, применительно к сетевому трафику - это то, что маршрутизирует сетевой трафик. Это определение касается l3 таблицы маршрутизации, и больше ничего. Прокси трафик не маршрутизирует, в лучшем случае показывает пальцем сетевой подсистеме направлять вот этот конкретный трафик согласно той таблице маршрутизации или согласно этой таблице маршрутизации. А маршрутизирует его уже сетевая подсистема.
Петровский, потому что это разные функции. Машрутизация работает даже без знания о существовании каких-то там прокси, а прокси не может работать без маршрутизации. То, что для конечного пользователя это выглядит таким образом, что это прокси маршрутизирует его трафик - это не значит, что это так работает. Прокси в этом конкретном применении работает как сложный фильтр, но непосредственно маршрутизацией сетевых пакетов, из которых и строится сетевой трафик, не занимается. Точно так же маршрутизацией не занимается линуксовый connection manager, хотя он занимает ключевую роль в сетевой инфраструктуре ядра линукс. У него другая функция, нежели определять куда какой пакет должен пойти. Хотя он часть этой системы, бтв.
Петровский, такси не является частью сетевого трафика. А http/s соединение является. Я, собственно, согласился сузить понятие до маршрутизации сетевого трафика в интернете. А она сводится на l3, и мимо не проходит никак. В одном l2 сегменте или с использованием адресации, отличной от IP оно может иметь и другое понимание, но мы не о таких случаях говорим.
Извини, бро, ты бредишь :) Прокси - это прокси, все что он делает, это принимает соединение от клиента и устанавливает соединение от себя с нужным сервером.
Модель OSI является образовательной, не более. Это попытка описания работы мира в целом
Математика является образовательной, не более. Это попытка описания работы мира в целом
Прокси маршрутизирует сетевой трафик и ничем не отличается от ip-маршрутизатора, как и доставка товаров в пятерочку
Прокси не маршрутизироет сетевой трафик. У него нет ни таких задач, ни такого функционала.
Это и есть маршрутизация, бро
Маршрутизация - это поиск маршрута из точки а в точку б. Это НЕ установка соединения, пакеты вообще о соединениях не знают нихрена, это не нахождение точки б, точку б тебе указывают другие функции, например, тот же прокси.
ВПН соединение всегда доступно для всего ПК, так как маршруты общие для всех и не видят, какая программа их использует. Очень любопытно каким способом вы его ограничивали только для одной программы?
Для одной программы можно использовать прокси сервер, настроив его в ней, тогда другие программы не будут иметь никакой информации о таком подключении
Очень любопытно каким способом вы его ограничивали только для одной программы?
Уточню, я пользуюсь готовыми решениями. Ограничения можно задавать благодаря функции Split Tunneling, которая есть во многих популярных VPN. Например, это есть в Windscribe, Proton, Hideme.
Qeinzo, Split Tunneling - это не ограничение впн для какого либо приложения, а настройка впн для определенного списка веб сайтов, чтоб весь трафик не заворачивался в впн туннель, и без разницы какое приложение туда хочет заглянуть, все они пойдут через впн.
Вы пишите про маршрутизацию трафика к веб-сайтам, а я про Per-app split tunneling. Возможно, вы подразумеваете функцию "исключения" или "белых списков", которые есть в некоторых VPN-клиентах. Изначально же Split Tunneling задумывался для разделения трафика приложений.
нда... и этот народ не хочет читать про сети...
хотя бы СДСМ... более серьезное даже рекомендовать не буду.
Наличие VPN соединения в системе позволяет использовать это соединение любой программе. В общем случае. Варианты с namespace (в линухе) не рассматриваем, это не настолько распространено.
Далее путь трафика определяется таблицей маршрутизации.
Split tunneling фактически либо включает перенаправление default route на vpn туннель или не включает, тогда только явно указанные маршруты пойдут через vpn...
Петровский, можно пример? Вот никак не могу придумать как приложению в винде запретить использовать маршруты прописанные в системе (впн клиентом или ручками).
Петровский, А вы сейчас на фаерволы в винде посмотрите... Сильной разницы не заметите.
Винда уступает по сетевым возможностям линуху. Ну не нужно ей это )
Руслан Федосеев, я не видел коммерческие файрволлы на Винде с момента появления роутеров. Но не думаю, что уступает. В частности , в Винде есть тесная связь между userspace и kernelspace, отсюда возможность пользователю увидеть в виде окошка, какое приложение отправляет запрос на какой хост и порт
Простой
