Как настроить VPN в macOS так, чтобы разные приложения использовали разные VPN‑подключения?

Кратко — встроенного в macOS удобного «per‑app VPN» для произвольных приложений нет. Когда вы подключаете второй системный VPN, он обычно меняет маршруты и может «перекрыть» рабочий. Есть несколько рабочих путей решить вашу задачу; ниже — варианты с плюсами/минусами и шаги.

Вариант A — самый надёжный: запустить личные приложения в виртуальной машине (рекомендую)
- Установите VM (Parallels, VMware Fusion, VirtualBox, UTM).
- В гостевой ОС установите ваш личный VPN‑клиент и подключитесь к нему.
- В гостевой ОС запускайте Telegram, YouTube (браузер) и т. п.
- На хосте оставляйте рабочий VPN для удалённого рабочего стола.
Плюсы: полная сетeвая изоляция, ничего не ломает рабочий VPN. Минусы: ресурсоёмко, нужно лицензия/установить VM.

Вариант B — использовать прокси/SSH туннель + per‑app проксировщик (Proxifier / Proxycap)
- Запустите SOCKS‑прокси, например SSH‑туннель на вашем удалённом сервере:
  ssh -D 1080 -N -C -f user@server
  (это создаст локальный SOCKS5 на 127.0.0.1:1080)
- Установите Proxifier (или Proxycap). Создайте правило: приложения Telegram, браузер → направлять через 127.0.0.1:1080.
- Остальной трафик останется через системный (рабочий) VPN.
Плюсы: лёгкий, не нужно вторую систему‑уровневую VPN. Минусы: нужен внешний сервер или прокси; Proxifier — платный.

Вариант C — использовать VPN‑клиент с поддержкой split‑tunneling / per‑app
- Некоторые провайдеры/клиенты (проверьте ваш провайдер) имеют опцию «split tunneling» или «allow/deny apps». Добавьте в список только те приложения, которые должны идти через личный VPN.
Плюсы: нативно без VM/прокси. Минусы: не у всех провайдеров, и корпоративный VPN может блокировать split‑tunneling по политике.

Вариант D — macOS MDM / Network Extension per‑app VPN (для управляемых устройств)
- Для корпоративных устройств можно настроить «Per‑App VPN» через MDM и специфичные VPN‑решения (Network Extension). Это для инфраструктуры, обычно не для домашнего пользователя.
Плюсы: гибкая, на уровне системы. Минусы: требует MDM/разработки или готового клиентa с такой функцией.

Почему рабочий VPN «отключается» при подключении стороннего
- VPN‑клиенты меняют таблицу маршрутизации и сетевые интерфейсы. Часто второй клиент перезаписывает дефолтный маршрут или использует системный VPN сервис, из‑за чего первый теряет маршрут к корпоративным ресурсам.
- Корпоративные клиенты (AnyConnect/GlobalProtect и пр.) могут специально запрещать одновременные соединения.

Насчёт Telegram: да, Telegram умеет работать через прокси (SOCKS5 или MTProto), поэтому для Telegram можно не ставить системный VPN — достаточно прокси или запустить Telegram в VM/через Proxifier. Но «прокси не нужен» только если вы используете VM или per‑app VPN; иначе без прокси системный VPN будет применяться ко всему трафику.

Рекомендация для простого и безопасного результата
- Если хотите простое и надёжное разделение — поставьте VM и в ней подключайте личный VPN; оставьте рабочий VPN на хосте.
- Если не хотите VM и готовы платить — Proxifier + SSH/SOCKS прокси даст per‑app контроль.
- Если ваш личный VPN‑провайдер поддерживает split‑tunneling на macOS — попробуйте включить и настроить его.

Если хотите — скажите:
- какой рабочий VPN (клиент) вы используете,
- какой личный VPN или возможность иметь SSH‑сервер,
— и я подскажу конкретные шаги для выбранного варианта (команды, настройки Proxifier или шаги по VM).

использовать split tunelling - раздельную маршрутизацию <br/> <br/> умеют например опенвпн (в  конфиге прописывать или маршруты пушить с сервера) <br/> умеет AmneziaWG <br/> умеет sstp (anyconnect) <br/> умеет почти любой клиент vless <br/> <br/> нужное прокидываешь в впн, всё остальное идёт по дефолту <br/> <br/> настройка зависит от клиента и типа ВПН \ прокси

ВПН часто конфигурируется с добавлением маршрута по умолчанию, т.е. весь трафик с компа отправляется в ВПН. <br/> Как правило, для рабочего ВПН этого не нужно. Там обычно достаточно добавить один или несколько маршрутов до локальной офисной сети. Какие именно маршруты добавлять - должны сказать администраторы. Таким образом только трафик до этих внутренних офисных сетей будет идти через ВПН. <br/> Второй ВПН, который для интернета - тут уже может добавляться маршрут по умолчанию и весь остальной трафик будет идти на этот ВПН. <br/> Маршрутов по умолчанию теоретически может быть несколько, но работать будет только 1 с меньшей (или большей, не помню точно) метрикой. <br/> Так что из всего вышесказанного, можно сделать вывод, что ВПНов на компе можно держать подключенными сколько угодно много, но с оговорками: <br/> 1. только 1 ВПН должен изменять маршрут по умолчанию <br/> 2. у всех других ВПНов не должны пересекаться маршруты (адресация внутренних сетей за ВПН сервером), иначе начнется то же самое - будет работать только 1 из них. <br/> В целом все эти проблемы - это не про ВПН, собственно, это про стандартную маршрутизацию IP трафика, которая работает одинаково на всех устройствах, где есть протокол TCP/IP.