Вместо одного VPN на всё — Ubuntu VM с корпоративным VPN внутри плюс SSH SOCKS5-туннель с хоста. Firefox и Git ходят через туннель в корп-сеть, Chrome остаётся в личной сети. Никаких ручных переключений.

Контекст

Если вы работаете в большой компании и одновременно живёте там, где есть какие-то региональные ограничения на сервисы, у вас почти наверняка две VPN-конфигурации:

• рабочая — для доступа к внутренним ресурсам (GitLab, Jira, Confluence и т.д.)

• личная — для личных целей

И постоянное переключение между ними — это, мягко говоря, неудобно. Особенно когда:

1. забыл переключить — и push в GitLab падает по таймауту

2. переключил — и YouTube перестаёт работать

3. маршруты двух VPN конфликтуют и не работает ничего

Я долго пытался «сделать один VPN, который умеет всё». В какой-то момент понял, что борюсь не с той проблемой.

Идея

Вместо того чтобы пихать всё в один VPN, я разделил сети по приложениям:

• Рабочая среда живёт внутри виртуальной машины (Ubuntu), и корпоративный VPN поднят только там.

• Личная среда живёт на хосте напрямую (плюс личный VPN при необходимости).

• Связь между хостом и VM — SSH SOCKS5-туннель.

Подход полностью кросс-платформенный: работает на Mac, Windows и Linux.

Архитектура

На хосте VPN не стоит вообще. На VM поднят один корпоративный VPN, и он там просто всегда работает.

Как это работает

Git

Хост → SSH → Ubuntu VM → корпоративный VPN → GitLab

git push с хоста идёт через SSH в VM, оттуда через корпоративный VPN — в GitLab. Хост в этой цепочке ничего не знает про VPN. Push и pull работают стабильно, даже если хост переподключается к другому Wi-Fi.

Firefox (рабочий браузер)

Firefox → SOCKS5 (localhost) → Ubuntu VM → VPN → корпоративные сервисы

Firefox настроен ходить через SOCKS5-прокси на 127.0.0.1:1080. Прокси «слушает» SSH-туннель и пересылает трафик через VM. Jira, Confluence, GitLab открываются только в Firefox.

Chrome (личный браузер)

Chrome ходит напрямую через интернет хоста (или через личный VPN, если нужно). Никакого взаимодействия с рабочей средой.

Реализация

1. Виртуальная машина

Ubuntu в любой системе виртуализации:

• macOS: UTM, Parallels, VirtualBox

• Windows: Hyper-V, VirtualBox, либо WSL2 (с оговорками — WSL это не полноценная VM, но в большинстве сценариев подходит)

• Linux: KVM, VirtualBox

Внутри VM настраиваем корпоративный VPN — так, как требует корпоративная инструкция. Обычно это OpenVPN, WireGuard или Cisco AnyConnect. Главное — чтобы VPN был активен и стабильно держался. Удобно настроить автозапуск VPN при старте VM, чтобы туда вообще не лезть руками.

2. SSH-туннель с хоста в VM

На любой ОС с OpenSSH (macOS — из коробки, Windows 10/11 — встроенный OpenSSH доступен в PowerShell, Linux — само собой):

ssh -N -D 1080 user@ubuntu-vm

Что делают флаги:

• -N — не запускать удалённую команду (нам нужен только туннель)

• -D 1080 — поднять локальный SOCKS5-прокси на порту 1080

После выполнения этой команды на 127.0.0.1:1080 доступен SOCKS5-прокси, который пересылает любой трафик через VM.

Для удобства можно завернуть это в autossh, который автоматически переподключается при разрыве:

autossh -M 0 -f -N -D 1080 \
  -o "ServerAliveInterval 30" \
  -o "ServerAliveCountMax 3" \
  user@ubuntu-vm

На Windows autossh менее распространён, но можно использовать связку OpenSSH + Task Scheduler, или WSL2 с тем же autossh внутри.

3. Firefox

Settings → Network Settings → Manual proxy configuration:

• SOCKS host: 127.0.0.1

• Port: 1080

• SOCKS v5

• ✅ Proxy DNS when using SOCKS v5

Последний пункт — критичный. Без него DNS-запросы идут с хоста напрямую, мимо туннеля. Это значит:

1. Внутренние корпоративные домены не резолвятся (хост о них ничего не знает).

2. Происходит утечка DNS — провайдер видит, что вы стучитесь во внутренние корп-ресурсы.

С включённой опцией DNS-запросы тоже инкапсулируются в SOCKS5 и резолвятся уже в VM, где они идут через корпоративный VPN.

4. Git

Здесь два варианта, в зависимости от того, как у вас настроен доступ к репозиториям.

Вариант А: HTTPS-репозитории. Прописываем SOCKS-прокси в git config:

git config --global http.proxy socks5h://127.0.0.1:1080
git config --global https.proxy socks5h://127.0.0.1:1080

Обратите внимание на socks5h (с буквой h). Это указывает libcurl резолвить DNS на стороне прокси, а не локально. Без h будет та же проблема с DNS, что и в Firefox: если корпоративный GitLab сидит за корп-VPN на внутреннем домене — ничего не заработает.

Вариант Б: SSH-репозитории. Настраиваем ProxyJump в SSH-конфиге.

• macOS/Linux: ~/.ssh/config

• Windows: C:\Users\<имя>\.ssh\config

Host gitlab.corp
  HostName gitlab.internal.example.com
  User git
  ProxyJump user@ubuntu-vm

После этого git clone git@gitlab.corp:team/repo.git сам прыгает через VM как через jump-host. VPN на VM делает остальное.

Почему это лучше, чем «просто VPN на хосте»

Обычная схема:

• всё через один VPN

• постоянные переключения

• конфликты маршрутов и DNS

• при разрыве VPN падает вообще весь интернет

• личные сервисы и рабочие смешаны на уровне маршрутизации

Архитектурное разделение:

• сети разделены по приложениям

• ничего не конфликтует

• VPN на хосте можно вообще не трогать или не ставить

• VPN внутри VM поднимается один раз и живёт сам

• если корпоративный VPN падает — личный интернет не страдает

• легко иметь несколько рабочих окружений (для разных проектов или клиентов) в виде разных VM

Подводные камни

SSH-туннель может разрываться при смене сети (Wi-Fi → 4G). Решение — autossh с ServerAliveInterval.

Производительность. Весь рабочий трафик проходит SOCKS5-обёртку и виртуализацию. На современном железе это незаметно, но для пиковых задач (тяжёлые CI-артефакты, передача больших файлов) может быть чуть медленнее, чем прямой VPN.

SOCKS5 не покрывает всё. Если рабочее ПО на хосте (например, тяжёлый IDE с интеграциями в Jira) не умеет SOCKS — нужно либо запускать его внутри VM, либо оборачивать трафик через proxychains (Linux/Mac).

DNS — главный источник граблей. Если что-то не резолвится — почти всегда дело в том, что DNS пошёл мимо прокси. Проверяйте опции socks5h, «Proxy DNS over SOCKS» и при необходимости настройки resolv.conf внутри VM.

Корпоративные политики. Стоит свериться с политикой безопасности — некоторые компании отдельно регламентируют доступ к VPN из вложенных окружений. Юридически это обычно не запрещено, но лучше уточнить, чем потом объясняться.

Итого

Я перестал пытаться «сделать один идеальный VPN», который умел бы и работу, и личное. Вместо этого:

разделил интернет как архитектурную систему.

Work и personal интернет у меня разделены не VPN-ами, а маршрутами приложений. Один раз настроил — и забыл.

Если есть вопросы или свой опыт похожих конфигураций — пишите в комментариях. Интересно посмотреть какие есть еще варианты по организации работы и личного пространства на одном устройстве

Мой телеграм канал - https://t.me/aleksandr_frontend