VPN или SSH-туннель: что выбрать для удалённого доступа

Одна и та же задача, два разных инструмента

Задача «получить доступ к сервису, который слушает только на внутреннем интерфейсе сервера и не должен быть открыт наружу» встречается постоянно: административная панель базы данных, внутренний dashboard мониторинга, dev-версия сайта на нестандартном порту. Решить её можно двумя принципиально разными способами — разовым SSH-туннелем или постоянной VPN-сетью, и путаница между ними обычно возникает потому, что оба решают на первый взгляд одну и ту же задачу «безопасный доступ к тому, что не выставлено в открытый интернет».

На деле это инструменты разного масштаба. SSH-туннель — это побочная возможность протокола SSH, который и так почти наверняка уже настроен для администрирования сервера, и туннель можно поднять одной командой в любой момент, когда он нужен, не меняя постоянную конфигурацию сети. VPN — это отдельная, постоянно работающая инфраструктура, требующая собственной настройки на сервере и клиенте, зато дающая полноценную виртуальную сеть, а не доступ к одному конкретному адресу и порту.

Эта статья разбирает три вида проброса портов через SSH с реальными примерами команд, затем показывает, когда этого достаточно, а когда стоит поднимать WireGuard или OpenVPN, и сравнивает оба подхода по накладным расходам и сложности сопровождения.

Local port forwarding: доступ к одному внутреннему сервису

Локальный проброс порта (-L) — самый частый и самый простой случай: сервис слушает на внутреннем адресе сервера, недоступном напрямую с локальной машины, и SSH-туннель делает так, будто этот сервис слушает на localhost клиента.

ssh -L 5433:localhost:5432 user@server.example.com

После выполнения этой команды подключение клиента базы данных к localhost:5433 на локальной машине прозрачно перенаправляется через SSH-туннель на порт 5432 сервера — с точки зрения клиента PostgreSQL база данных выглядит так, будто работает локально, хотя физически трафик идёт зашифрованным через SSH-соединение до сервера. Второй адрес в команде (localhost:5432) указывается с точки зрения самого сервера, а не клиента, что часто становится источником путаницы у тех, кто настраивает это впервые.

ssh -L 8080:internal-app.local:80 user@jump-host.example.com

Local forwarding особенно удобен именно тем, что не требует никакой конфигурации на стороне сервера сверх обычного SSH-доступа — не нужно ничего устанавливать дополнительно, править firewall или менять маршрутизацию, достаточно, чтобы сервис на удалённой стороне уже слушал нужный адрес и порт, а у пользователя был обычный SSH-доступ к машине, которая до этого адреса может достучаться.

Remote port forwarding: обратный случай

Remote forwarding (-R) решает противоположную задачу — сделать локальный сервис клиента доступным со стороны сервера, что типично нужно, например, чтобы показать коллеге локально запущенное веб-приложение через публично доступный сервер, или чтобы дать серверу доступ обратно к ресурсу за NAT, к которому иначе нет прямого пути.

ssh -R 9000:localhost:3000 user@server.example.com

После выполнения этой команды любое обращение к порту 9000 на сервере перенаправляется обратно через тот же SSH-туннель на порт 3000 локальной машины, с которой было инициировано соединение. Важная деталь конфигурации — по умолчанию SSH-демон разрешает remote forwarding слушать только на localhost сервера, а не на всех интерфейсах; чтобы порт был доступен снаружи самого сервера, в sshd_config нужно явно включить GatewayPorts, что стоит делать осознанно и временно, поскольку это расширяет поверхность доступа к машине клиента.

Практическое применение remote forwarding на практике встречается реже, чем local forwarding, и чаще всего используется для отладки — например, чтобы показать вебхук локально работающего приложения внешнему сервису, которому нужен публично доступный URL, без необходимости в отдельном сервисе туннелирования вроде ngrok.

Dynamic forwarding: SOCKS5-прокси через один туннель

Dynamic forwarding (-D) поднимает на локальной машине SOCKS5-прокси, через который любое приложение, поддерживающее настройку прокси (браузер, некоторые CLI-инструменты), может направлять трафик через SSH-туннель к произвольным адресам, доступным с сервера — в отличие от local forwarding, который жёстко привязан к одной паре адрес-порт, заданной заранее.

ssh -D 1080 user@server.example.com

После этого браузер или другое приложение, настроенное на использование SOCKS5-прокси localhost:1080, получает доступ к любому ресурсу, видимому с сервера — это особенно удобно, когда нужен доступ не к одному заранее известному сервису, а к нескольким внутренним ресурсам сразу, без необходимости поднимать отдельный проброс для каждого из них.

Ограничение dynamic forwarding в том, что оно работает только для приложений, явно поддерживающих настройку SOCKS-прокси, и не даёт полной сетевой прозрачности — программы, не умеющие работать через прокси, продолжат обращаться напрямую, минуя туннель. Для полной маршрутизации произвольного трафика через удалённую сеть нужен уже не SSH-туннель, а VPN или SSH с опцией -w, поднимающей tun-интерфейс на уровне IP.

Когда SSH-туннеля действительно достаточно

SSH-туннель — правильный выбор, когда доступ нужен к одному или нескольким конкретным сервисам, задача разовая или нерегулярная, а у пользователя уже есть обычный SSH-доступ к серверу для администрирования — в этом случае туннель не требует вообще никакой дополнительной инфраструктуры и поднимается за секунды прямо в момент необходимости.

Типичные сценарии: разработчик подключается локальным клиентом к базе данных на продакшен-сервере для разовой диагностики; администратор открывает веб-интерфейс мониторинга, который намеренно не выставлен в публичный интернет; нужно показать коллеге локально запущенное приложение через публично доступный адрес сервера. Во всех этих случаях постоянная VPN-инфраструктура была бы явным избытком ради задачи, которая решается одной командой и закрывается простым Ctrl+C.

Единственное неудобство SSH-туннеля — его нужно поднимать заново при каждом разрыве соединения и при каждой новой сессии, если не используется отдельная утилита вроде autossh для автоматического переподключения, а конфигурация мультиплексирования через ControlMaster в SSH-конфиге позволяет переиспользовать уже установленное соединение для новых туннелей без повторной аутентификации.

autossh -M 0 -f -N -L 5433:localhost:5432 user@server.example.com
# в ~/.ssh/config для того же эффекта декларативно:
Host db-tunnel
    HostName server.example.com
    User user
    LocalForward 5433 localhost:5432
    ServerAliveInterval 30
    ServerAliveCountMax 3

Параметры ServerAliveInterval и ServerAliveCountMax важны сами по себе, даже без autossh, — они заставляют SSH-клиент периодически отправлять служебные пакеты для проверки живости соединения и обнаруживать разрыв заметно быстрее, чем стандартный таймаут TCP, что особенно полезно, когда туннель проходит через NAT или другое промежуточное сетевое оборудование, обрывающее долго неактивные соединения по собственной инициативе.

Когда пора переходить на полноценный VPN

VPN становится оправданным выбором, когда доступ нужен не к одному сервису, а к целой внутренней подсети сразу, когда пользователей несколько и им нужен унифицированный, управляемый доступ, или когда доступ должен работать постоянно и прозрачно, а не подниматься вручную перед каждым использованием.

Классический пример — команда из нескольких разработчиков, которым нужен доступ сразу к нескольким внутренним сервисам (базе данных, внутреннему API, панели мониторинга, серверу очередей), расположенным на разных машинах одной внутренней сети. Настройка отдельного SSH-туннеля под каждый сервис для каждого разработчика превращается в комбинаторный кошмар конфигурации и координации локальных портов, тогда как VPN один раз подключает участника ко всей внутренней сети целиком, а дальнейший доступ к конкретным сервисам регулируется обычными правилами firewall внутри этой сети.

Второй типичный сценарий — объединение офиса или нескольких серверов в разных дата-центрах в единую логическую сеть, где важна не разовая точка доступа, а постоянная маршрутизация между площадками. WireGuard в этом сценарии особенно удобен благодаря простоте конфигурации (по сути, пара ключей и один конфигурационный файл на каждую сторону) и низким накладным расходам по сравнению с OpenVPN, что делает его разумным выбором по умолчанию для новых проектов, если только не требуется специфическая совместимость с корпоративной инфраструктурой, ориентированной на OpenVPN.

Минимальный пример конфигурации WireGuard

Чтобы конкретизировать разницу в сложности настройки, стоит увидеть, из чего в реальности состоит минимальная рабочая конфигурация WireGuard — она компактнее, чем можно ожидать, но требует ключей и файла конфигурации на обеих сторонах, в отличие от разовой SSH-команды.

# Сервер: /etc/wireguard/wg0.conf
[Interface]
Address = 10.8.0.1/24
PrivateKey = <приватный_ключ_сервера>
ListenPort = 51820

[Peer]
PublicKey = <публичный_ключ_клиента>
AllowedIPs = 10.8.0.2/32

# Клиент: /etc/wireguard/wg0.conf
[Interface]
Address = 10.8.0.2/24
PrivateKey = <приватный_ключ_клиента>

[Peer]
PublicKey = <публичный_ключ_сервера>
Endpoint = server.example.com:51820
AllowedIPs = 10.8.0.0/24
PersistentKeepalive = 25

После запуска интерфейса командой wg-quick up wg0 на обеих сторонах клиент получает постоянный доступ ко всей подсети 10.8.0.0/24, а не к одному заранее выбранному порту, как в случае SSH-туннеля — именно эта разница в масштабе доступа (один сервис против целой сети) и определяет, какой из двух инструментов подходит для конкретной задачи.

ProxyJump и bastion-хост: SSH-туннели через промежуточный сервер

Во многих инфраструктурах внутренние серверы намеренно не имеют прямого SSH-доступа из интернета, и единственный способ до них добраться — через отдельный, специально выделенный публичный сервер-бастион (jump host), на котором аутентификация и логирование доступа настроены особенно тщательно. Современный SSH-клиент решает эту задачу конфигурационной директивой ProxyJump, не требуя ручного построения цепочки из двух отдельных подключений.

ssh -J user@bastion.example.com user@internal-server.local
# или в ~/.ssh/config:
Host internal
    HostName internal-server.local
    User user
    ProxyJump user@bastion.example.com

С точки зрения задачи «SSH-туннель против VPN» bastion-хост занимает промежуточное положение: он не даёт полноценного сетевого доступа ко всей внутренней инфраструктуре, как VPN, но и не ограничивается одним портом, как обычный local forwarding — через ProxyJump можно так же пробросить порт до любого сервиса за бастионом командой -L, скомбинировав оба механизма в одной команде. Это удобный средний вариант для инфраструктур, где полноценный VPN избыточен, но доступ нужен не к одному, а к нескольким внутренним серверам через единую контролируемую точку входа.

Именно через bastion-хост часто реализуется требование аудита безопасности «весь доступ к внутренним серверам должен проходить через одну точку с полным логированием» — вместо того чтобы разрешать прямой SSH-доступ к каждому внутреннему серверу с десятков разных клиентских машин, все подключения идут через единственный bastion, на котором централизованно настроены и мониторинг, и двухфакторная аутентификация, и ограничение по IP.

Комбинированный подход: VPN для сети, SSH-туннель для конкретной задачи

На практике VPN и SSH-туннель не всегда взаимоисключающий выбор — в зрелой инфраструктуре они часто сосуществуют, решая разные по масштабу задачи одновременно. Типичная схема: команда подключена к внутренней сети через постоянный VPN, дающий базовый сетевой доступ к нужным подсетям и хостам, а отдельные разовые или нестандартные задачи — например, доступ к сервису на машине, которая по каким-то причинам не входит в маршрутизацию VPN, — решаются точечным SSH-туннелем поверх уже установленного VPN-соединения.

Обратный сценарий также распространён: VPN используется только для доступа отдельных внешних партнёров или подрядчиков к строго ограниченному сегменту сети (через отдельный профиль с узким AllowedIPs в терминах WireGuard), тогда как основная команда администраторов продолжает пользоваться прямыми SSH-туннелями для повседневной работы, не тратя ресурсы на постоянное VPN-подключение, которое им не нужно на постоянной основе.

Практический вывод — не стоит воспринимать выбор между SSH-туннелем и VPN как универсальное решение на всю инфраструктуру целиком: разумнее анализировать каждый конкретный сценарий доступа отдельно и выбирать для него наиболее подходящий по масштабу инструмент, помня, что оба механизма используют одинаково надёжное современное шифрование и различаются в первую очередь удобством, гибкостью и постоянством, а не криптографической стойкостью.

Накладные расходы и сложность сопровождения

С точки зрения производительности разница между SSH-туннелем и VPN в подавляющем большинстве практических сценариев незначительна для типичной нагрузки вроде доступа к веб-интерфейсу или базе данных — оба добавляют накладные расходы на шифрование, но современные процессоры с аппаратным ускорением AES справляются с этим без заметной просадки. Разница становится ощутимой при передаче больших объёмов данных или при работе с задержкочувствительными протоколами, где WireGuard благодаря более простой архитектуре и работе в пространстве ядра обычно показывает меньшие накладные расходы, чем OpenVPN.

Сложность сопровождения — куда более важный практический фактор при выборе. SSH-туннель не требует отдельного сопровождения вовсе: он существует ровно столько, сколько длится сессия, и не оставляет постоянной инфраструктуры, за которой нужно следить, обновлять и мониторить. VPN, напротив, — это постоянно работающий сервис со своим жизненным циклом: нужно управлять ключами и их отзывом при уходе сотрудников, следить за обновлениями самого VPN-ПО, мониторить состояние туннелей между площадками и продумывать резервный канал доступа на случай, если сам VPN-сервер станет недоступен.

Практический ориентир для выбора: если открыть блокнот и написать список всех сервисов, к которым нужен доступ, и всех людей, которым он нужен, получившийся список из одного пункта в каждой категории почти всегда означает, что SSH-туннеля достаточно, а список из нескольких пунктов в обеих категориях — сигнал, что пора инвестировать время в постоянную VPN-инфраструктуру.