Вместо одного VPN на всё — Ubuntu VM с корпоративным VPN внутри плюс SSH SOCKS5-туннель с хоста. Firefox и Git ходят через туннель в корп-сеть, Chrome остаётся в личной сети. Никаких ручных переключений.
Контекст
Если вы работаете в большой компании и одновременно живёте там, где есть какие-то региональные ограничения на сервисы, у вас почти наверняка две VPN-конфигурации:
рабочая — для доступа к внутренним ресурсам (GitLab, Jira, Confluence и т.д.)
личная — для личных целей
И постоянное переключение между ними — это, мягко говоря, неудобно. Особенно когда:
забыл переключить — и push в GitLab падает по таймауту
переключил — и YouTube перестаёт работать
маршруты двух VPN конфликтуют и не работает ничего
Я долго пытался «сделать один VPN, который умеет всё». В какой-то момент понял, что борюсь не с той проблемой.
Идея
Вместо того чтобы пихать всё в один VPN, я разделил сети по приложениям:
Рабочая среда живёт внутри виртуальной машины (Ubuntu), и корпоративный VPN поднят только там.
Личная среда живёт на хосте напрямую (плюс личный VPN при необходимости).
Связь между хостом и VM — SSH SOCKS5-туннель.
Подход полностью кросс-платформенный: работает на Mac, Windows и Linux.
Архитектура
На хосте VPN не стоит вообще. На VM поднят один корпоративный VPN, и он там просто всегда работает.
Как это работает
Git
Хост → SSH → Ubuntu VM → корпоративный VPN → GitLabgit 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.1Port:
1080SOCKS v5
✅ Proxy DNS when using SOCKS v5
Последний пункт — критичный. Без него DNS-запросы идут с хоста напрямую, мимо туннеля. Это значит:
Внутренние корпоративные домены не резолвятся (хост о них ничего не знает).
Происходит утечка 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/configWindows:
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