Введение

В последние годы для команд, которые работают с зарубежной инфраструктурой из России, обычный корпоративный VPN перестал быть чем-то, что можно один раз настроить и забыть. OpenVPN, WireGuard, IPsec, различные TLS- и QUIC-обёртки могут работать стабильно месяцами, а потом внезапно начать деградировать: где-то соединение не устанавливается, где-то режется UDP, где-то DPI начинает узнавать сигнатуры, где-то провайдер меняет правила фильтрации.

Для компании это превращается не в техническую мелочь, а в операционный риск. Инженеры не могут попасть на серверы. DevOps не может проверить прод. Администратор не может забрать бэкап. Пентестер не может подключиться к стенду заказчика. При этом инфраструктура может находиться в Европе, США, Азии или у любого другого зарубежного провайдера, а сотрудники — физически находиться в РФ.

В какой-то момент мы пришли к простой мысли: если из корпоративной сети ещё можно установить исходящее SSH-соединение, то можно попробовать использовать сам OpenSSH не только как инструмент администрирования, но и как транспорт для L3-туннеля. В OpenSSH для этого давно существует режим ssh -w, который поднимает туннель через tun-устройство.

Идея статьи не в том, чтобы объявить ssh -w «лучшим VPN на все времена». Это не замена WireGuard для нормальной постоянной инфраструктуры и не серебряная пуля против любых сетевых ограничений. Но это очень полезный аварийный и корпоративный вариант: работает поверх обычного SSH, не требует отдельного VPN-демона на сервере, может быть поднят на дешёвом VPS, использует привычную модель ключей OpenSSH и позволяет строить полноценную маршрутизацию на L3.

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

До этого момента ssh -w может быть хорошим запасным планом.

Что такое ssh -w

Обычно SSH воспринимается как:

• удалённый shell;

• безопасная передача файлов через scp или sftp;

• локальные и обратные TCP-пробросы через -L и -R;

• SOCKS-прокси через -D.

Но у OpenSSH есть ещё один режим — туннелирование сетевого интерфейса:

ssh -w local_tun:remote_tun user@host

Опция -w просит OpenSSH открыть tun-устройство на клиенте и на сервере. В режиме point-to-point это L3-туннель: на обеих сторонах появляются интерфейсы вроде tun0, которым можно назначить IP-адреса, после чего через них можно маршрутизировать трафик.

Упрощённо схема выглядит так:

Дальше мы можем сказать операционной системе:

sudo ip route add 10.10.0.0/16 dev tun0

И с точки зрения приложений это уже не SOCKS-прокси и не порт-форвардинг, а обычная IP-маршрутизация.

Чем L3-туннель лучше SOCKS и port forwarding

Для разовых задач часто хватает обычного SSH:

ssh -L 5432:db.internal:5432 user@bastion
ssh -D 1080 user@bastion

Но у этих режимов есть ограничения.

-L и -R хорошо подходят для конкретных TCP-портов. Например, пробросить PostgreSQL, Redis, админку или RDP. Но если сервисов много, если они появляются динамически, если нужно ходить не только в один порт, решение быстро превращается в набор костылей.

-D поднимает SOCKS-прокси. Это удобно для браузера или отдельных приложений, которые умеют работать через SOCKS. Но не весь корпоративный софт умеет использовать SOCKS. DNS тоже может стать отдельной проблемой. ICMP, UDP и произвольная маршрутизация через SOCKS не превращаются автоматически в нормальный сетевой доступ.

ssh -w даёт другой уровень абстракции. Мы не пробрасываем отдельные хосты и порты, а создаём обычный сетевой интерфейс. После этого рабочая станция начинает работать с удалённой инфраструктурой почти так же, как с обычной сетью: есть IP-маршруты, есть корпоративный DNS, есть доступ к подсетям, а приложениям не нужно знать, что где-то под капотом используется SSH. Например, мы можем настроить так:

Например:

10.10.0.0/16       корпоративная сеть через SSH-туннель
172.20.0.0/16      dev/stage-сегмент через SSH-туннель
192.168.50.0/24    административная сеть через SSH-туннель
corp.example.local корпоративная DNS-зона резолвится через внутренний DNS
локальная сеть     остаётся напрямую
российские сети    остаются напрямую

В результате пользователю не нужно думать, какой порт у какого сервиса и какой ssh -L для него поднять. Он просто открывает внутренний GitLab, Grafana, Kubernetes API, PostgreSQL, RDP, SSH до внутренних серверов или любой другой корпоративный ресурс так, как будто находится внутри офисной или облачной сети.

Отдельно важно, что это не proxy-only модель. Мы получаем именно L3-доступ: маршрутизация работает на уровне IP, а не на уровне конкретного приложения. Поэтому можно использовать корпоративный DNS, обращаться к сервисам по внутренним именам, не описывать каждый хост вручную и не собирать из порт-форвардов хрупкую конструкцию, которая ломается при каждом изменении инфраструктуры.

Именно это делает подход похожим не на «SSH-костыль», а на нормальный корпоративный сетевой доступ.

Почему выбор пал именно на OpenSSH

Главные причины:

1. OpenSSH уже почти везде установлен. На Linux-серверах он обычно есть из коробки. На macOS клиент уже есть. На Windows современный OpenSSH (как в последствие оказалось, windows версия не умеет в ssh -w).

2. SSH часто разрешён там, где другие протоколы уже режутся. Для многих компаний исходящий SSH до серверов, bastion-хостов, Git, CI/CD и облачной инфраструктуры всё ещё является рабочей необходимостью.

3. Не нужен отдельный VPN-сервер. На VPS достаточно настроить sshd, включить PermitTunnel, поднять NAT/маршрутизацию и выдать пользователю ключ.

4. Безопасность наследуется от OpenSSH. Можно использовать ключи, OpenSSH certificates, authorized_keys, TrustedUserCAKeys, ограничения по пользователям, группам, forced command, запрет shell, запрет TCP-forwarding, запрет X11, отдельные пользователи под каждого сотрудника.

5. Простая диагностика. Если не работает, можно смотреть обычные SSH-логи, journalctl -u ssh, ss -tnp, ip addr, ip route, tcpdump.

6. Дешёвый вход. Для MVP достаточно любого недорогого VPS с Linux и публичным IP.

Где это уместно

Такой подход хорошо подходит для:

• аварийного доступа к зарубежной инфраструктуре;

• доступа сотрудников к корпоративным подсетям;

• временных стендов;

• пентестов и аудитов, когда нужно быстро выдать L3-доступ к тестовой зоне;

• небольших команд;

• ситуаций, где WireGuard/OpenVPN/IPsec нестабильны или блокируются;

• сценариев, где нужен именно IP-маршрут, а не SOCKS-прокси.

Где это не лучший вариант:

• высоконагруженный публичный VPN на тысячb пользователей;

• permanent site-to-site между дата-центрами;

• сценарии с большим UDP-трафиком;

• задачи, где важна максимальная производительность и минимальная задержка.

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

Базовая схема MVP

В первой версии мы хотим получить консольную утилиту (скрипт), которая умеет:

• принимать адрес сервера;

• принимать имя пользователя;

• принимать порт SSH;

• принимать приватный ключ или пароль;

• поднимать ssh -w;

• назначать IP на локальный tun;

• добавлять маршруты;

• читать файл исключений подсетей;

• корректно отключаться и откатывать маршруты.

Архитектура MVP:

Для примера возьмём:

SSH server:       203.0.113.10
SSH port:         22
SSH user:         alice
Tunnel ID:        100
Server tun IP:    10.255.100.1
Client tun IP:    10.255.100.2

Настройка сервера: минимальный вариант

Для первого теста можно использовать root-доступ. Это проще всего для проверки идеи, но не лучший production-вариант.

На сервере:

apt update
apt install -y openssh-server iproute2 iptables-persistent

#Включаем IP forwarding:
cat >/etc/sysctl.d/99-ssh-tun.conf <<'EOF'
net.ipv4.ip_forward=1
EOF
sysctl --system
#Включаем туннели в OpenSSH:
cat >/etc/ssh/sshd_config.d/50-ssh-tun.conf <<'EOF'
PermitTunnel point-to-point
EOF
sshd -t
systemctl reload ssh

Добавляем NAT для клиентов туннеля. В примере внешний интерфейс — eth0, но на реальном VPS он может называться ens3, ens18, enp1s0 и так далее.

WAN_IF="eth0"
iptables -t nat -A POSTROUTING -s 10.255.0.0/16 -o "$WAN_IF" -j MASQUERADE
iptables -A FORWARD -i tun+ -o "$WAN_IF" -j ACCEPT
iptables -A FORWARD -i "$WAN_IF" -o tun+ -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
netfilter-persistent save

Для MVP этого достаточно.

Тестируем концепт: L3-туннель поверх обычного SSH

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

Минимальная ручная команда выглядит так:

sudo ssh root@46.224.191.37 \
  -p 22 \
  -i /home/kleimer/.ssh/tmp/vpn \
  -w 100:100 \
  -o Tunnel=point-to-point \
  -o ExitOnForwardFailure=yes \
  -N -vvv

Ключевая опция здесь — -w 100:100. Она говорит OpenSSH создать tun100 на клиенте и tun100 на сервере. После успешного подключения на клиентской машине действительно появляется новый интерфейс:

В моём случае tun100 поднялся, то есть базовый концепт подтвердился: OpenSSH умеет создавать L3-туннель без дополнительного транспорта.

Дальше стало понятно, что одной команды ssh -w недостаточно. Сам интерфейс появляется, но его ещё нужно правильно настроить: назначить IP-адреса на обеих сторонах, поднять интерфейс, включить маршрутизацию, добавить NAT на сервере и аккуратно почистить следы после завершения сессии.

Поэтому с помощью ИИ был быстро собран небольшой bash-скрипт, который автоматизирует подключение. После нескольких итераций он стал делать всё необходимое:

• выбирает свободный tun из пула;

• поднимает SSH-сессию;

• настраивает клиентский tun;

• в режиме root на сервере выполняет remote setup: IP на серверном tun, ip_forward, NAT;

• добавляет маршруты для full-tunnel;

• настраивает DNS;

• блокирует IPv6-маршрут, чтобы не было утечки мимо туннеля;

• при остановке удаляет маршруты, DNS-настройки и старые tun-интерфейсы.

Итоговая команда запуска получилась такой:

udo bash ./sshtun_pool_client1.sh start --host 46.224.191.37 --user root --key ~/.ssh/tmp/vpn --port 22 --ask-passphrase

После ввода passphrase скрипт поднимает временный ssh-agent, загружает ключ, выбирает интерфейс из пула и настраивает туннель. В моём тесте был выбран tun104:

Проверка внешнего IP после подключения:

curl 2ip.ru

То есть трафик действительно пошёл через удалённый сервер.

Что со скоростью

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

После подключения через SSH-TUN:

Это не лабораторный benchmark, а обычный бытовой замер через браузер, поэтому делать строгие выводы по одному прогону нельзя. Но для проверки концепта результат важный: существенной деградации скорости не видно. В конкретном тесте download даже оказался выше, а upload остался практически на том же уровне.

Главный вывод этого этапа: сама технология рабочая. OpenSSH действительно можно использовать как транспорт для L3-туннеля, а поверх него уже строить более удобный клиент, пул интерфейсов, автоподключение, очистку состояния и маршрутизацию.

Делаем подключение безопаснее

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

Но MVP был именно MVP. Для проверки концепта я подключался под root, использовал стандартный SSH-порт 22 и руками/скриптом донастраивал серверную сторону. Для эксперимента это нормально, но для нормального использования такой подход оставлять нельзя.

Следующая задача — превратить рабочий прототип в более безопасную схему подключения.

Главная идея простая: пользователь не должен получать обычный shell-доступ к серверу. Ему нужен только сетевой туннель. Значит, SSH должен быть настроен так, чтобы разрешать tun, но запрещать всё лишнее: интерактивную консоль, TCP-forwarding, agent-forwarding, X11, root-login и вход по паролю.

обычный SSH админа      -> port 22     -> системный sshd
SSH-TUN для клиентов    -> port 65523  -> отдельный sshtun-pool-sshd

Это важно: даже если мы экспериментируем с туннелями, мы не ломаем основной административный доступ к серверу. Что запрещаем В конфигурации туннельного SSH-сервиса отключается всё, что не нужно клиенту:

PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

PermitRootLogin no
AllowUsers sshvpn

AllowTcpForwarding no
GatewayPorts no
PermitListen none
PermitOpen none

PermitTTY no
X11Forwarding no
AllowAgentForwarding no
AllowStreamLocalForwarding no
PermitUserEnvironment no
ForceCommand /bin/false

То есть пользователь может пройти аутентификацию только по ключу, только как sshvpn, не может получить shell, не может открыть TCP-пробросы, не может пробросить агент, не может использовать X11 и не может выполнять произвольные команды на сервере. При этом остаётся включённым только то, ради чего всё и делалось:

PermitTunnel point-to-point

Это уже гораздо ближе к production-подходу: SSH используется как транспорт для L3-туннеля, но не как полноценная удалённая консоль.

Пул tun-интерфейсов

Ещё одна проблема MVP — ручной выбор интерфейса. В тесте я явно указывал -w 100:100, и на клиенте появлялся tun100. Для одного теста этого достаточно, но для нескольких клиентов или нескольких устройств одного пользователя нужно что-то удобнее.

В серверном install-скрипте используется пул интерфейсов: по умолчанию tun100…tun200. Клиент выбирает свободный номер из пула и подключается через ssh -w N:N. Адресация строится предсказуемыми парами внутри 10.250.0.0/16: например, tun100 получает пару 10.250.0.1/10.250.0.2, tun101 — следующую пару, и так далее.

Схематично это выглядит так:

tun100: server 10.250.0.1   <-> client 10.250.0.2
tun101: server 10.250.0.5   <-> client 10.250.0.6
tun102: server 10.250.0.9   <-> client 10.250.0.10
...

За счёт этого не нужно заранее закреплять за каждым пользователем конкретный tun. Один и тот же ключ может использоваться с разных устройств, а клиент просто выбирает свободный интерфейс из пула. Сетевая часть Отдельный systemd-сервис готовит сетевую часть: создаёт tun-интерфейсы, назначает им IP-адреса, включает IPv4 forwarding и добавляет минимальные правила NAT. Скрипт не устанавливает большой firewall с множеством цепочек и rate-limit-правил, а делает только то, что необходимо для работы туннеля: MASQUERADE для подсети 10.250.0.0/16 и минимальные FORWARD-правила для исходящего трафика и обратных established-соединений. То есть серверная часть после установки уже готова принимать SSH-TUN-клиентов:

client -> sshvpn@server:65523 -> tunN -> NAT -> Internet

Как теперь выглядит подключение После установки серверной части пользовательский ключ добавляется в:

/opt/sshtun_pool/authorized_keys

Рекомендуемая строка ключа дополнительно ограничивается на уровне authorized_keys:

no-pty,no-agent-forwarding,no-X11-forwarding,no-port-forwarding,no-user-rc ssh-ed25519 AAAAC3... user-device

После этого клиент подключается уже не под root, а под ограниченным пользователем sshvpn.

С точки зрения пользователя всё остаётся просто: он запускает клиент, получает tun-интерфейс, маршруты и DNS-настройки. Но с точки зрения безопасности разница большая: теперь у него нет административного доступа к серверу, нет shell-доступа, нет возможности использовать SSH как универсальный прокси или командный канал.

Управляем маршрутизацией: что отправлять в туннель, а что оставить напрямую

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

В MVP-режиме мы использовали full-tunnel: клиент добавлял два маршрута 0.0.0.0/1 и 128.0.0.0/1, и фактически весь IPv4-трафик уходил через удалённый сервер. Для проверки концепта это удобно: подключился, открыл 2ip.ru, увидел IP сервера — значит, туннель работает.

Но в реальной жизни этого недостаточно. Иногда нужно наоборот:

отправлять через туннель только определённые подсети; исключать локальные сети, чтобы не ломался доступ к роутеру, принтерам, NAS и внутренним ресурсам; исключать крупные списки адресов, например национальные CIDR-диапазоны; комбинировать full-tunnel с исключениями.

Поэтому в клиентский скрипт был добавлен отдельный слой управления маршрутизацией.

Теперь можно явно указать, какие сети должны идти через туннель:

sudo ./sshtun_pool_client.sh start \
  --host SERVER_IP \
  --user sshvpn \
  --port 65523 \
  --key ./id_ed25519 \
  --no-full-tunnel \
  --route 10.10.0.0/16 \
  --route 172.20.0.0/16

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

Обратный сценарий — full-tunnel с исключениями. Например, весь трафик отправляем через туннель, но локальные сети оставляем напрямую:

sudo ./sshtun_pool_client.sh start \
  --host SERVER_IP \
  --user sshvpn \
  --port 65523 \
  --key ./id_ed25519 \
  --exclude 192.168.0.0/16 \
  --exclude 10.0.0.0/8 \
  --exclude 172.16.0.0/12

Такой режим нужен, чтобы после подключения не отваливался доступ к домашней сети, локальному роутеру, Docker-сетям или внутренним адресам, которые должны оставаться доступными мимо туннеля.

Для больших списков маршрутов добавлена загрузка из файла:

sudo ./sshtun_pool_client.sh start 
 –host SERVER_IP 
 –user sshvpn 
 –port 65523 
 –key ./id_ed25519 
 –exclude-file ./ru-cidrs.txt

Файл ru-cidrs.txt может выглядеть так:

5.255.192.0/18
37.140.192.0/18
77.88.0.0/18

Это важный момент: если список содержит сотни или тысячи подсетей, его не нужно держать внутри основного конфига клиента. Такой список можно обновлять отдельно, генерировать автоматически и подключать как внешний файл.

Также добавлен противоположный вариант — список сетей, которые точно надо маршрутизировать через туннель:

sudo ./sshtun_pool_client.sh start \
  --host SERVER_IP \
  --user sshvpn \
  --port 65523 \
  --key ./id_ed25519 \
  --no-full-tunnel \
  --route-file ./corp-cidrs.txt

sudo ./sshtun_pool_client.sh start \
  --host SERVER_IP \
  --user sshvpn \
  --port 65523 \
  --key ./id_ed25519 \
  --no-full-tunnel \
  --route-file ./corp-cidrs.txt

Таким образом, появились две базовые модели:

Full-tunnel:
  весь трафик через SSH-TUN
  исключения — напрямую

Split-tunnel:
  весь трафик напрямую
  выбранные сети — через SSH-TUN

Ещё одна важная доработка — аккуратный cleanup. Скрипт должен не просто добавить маршруты при старте, но и убрать только свои изменения при остановке. Иначе после нескольких тестов можно получить хаос в таблице маршрутизации: старые tun-интерфейсы, неактуальные маршруты, DNS-настройки и blackhole для IPv6.

Поэтому логика остановки стала такой: удалить маршруты, добавленные клиентом, вернуть DNS, убрать временный tun и подчистить старые управляемые интерфейсы. Это особенно важно для тестового стенда, где подключение часто перезапускается десятки раз подряд.

В итоге клиент стал ближе к реальному продукту. Он уже не просто «поднимает туннель», а позволяет управлять политикой маршрутизации: что направлять через SSH-TUN, что оставлять напрямую и как безопасно возвращать систему в исходное состояние после отключения.

Windows-клиент: от bash-скрипта к нормальной утилите

Если не интересно читать ниже есть ссылка на github

После Linux-прототипа стало понятно, что сам подход работает: серверная часть с отдельным sshd, пулом tun-интерфейсов и NAT уже готова принимать клиентов. Но для Windows просто повторить Linux-скрипт не получится.

На Linux всю тяжёлую работу делает стандартный OpenSSH:

ssh -w 100:100 -o Tunnel=point-to-point ...

Он сам создаёт локальный tun, открывает tun@openssh.com-канал и передаёт IP-пакеты в нужном формате. На Windows такой модели из коробки нет (как оказалось), поэтому клиент пришлось делать иначе: отдельная утилита на Go + локальный виртуальный адаптер через wintun.dll.

Архитектура получилась такой:

То есть локально клиент создаёт Windows-сетевой адаптер, назначает ему IP-адрес из той же схемы, что и Linux-клиент, выбирает свободный tun из пула и открывает SSH-канал к серверу.

Например, если выбран tun132, адреса будут такими:

server: 10.250.0.129
client: 10.250.0.130

Дальше Windows добавляет маршруты, DNS, route-bypass до самого SSH-сервера и начинает гонять IP-пакеты между Wintun-адаптером и SSH-каналом.

Почему пришлось повозиться

Самая интересная проблема была не в маршрутах и не в NAT. Linux-клиент с этим же сервером работал, значит серверная часть была исправна. Проблема оказалась в реализации OpenSSH tunnel framing.

Сначала я пробовал отправлять в SSH-канал просто сырой IP-пакет. Потом пробовал заворачивать его как packet_length + packet, потом как packet_length + address_family + packet. Все эти варианты выглядели логично, но не совпадали с тем, как фактически работает tun@openssh.com в OpenSSH.

Рабочий формат оказался таким:

uint32 address_family
raw IP packet

Для IPv4 используется AF_INET = 2. То есть клиент должен отправлять в SSH-канал не просто IP-пакет, а небольшой префикс с типом адресного семейства, а затем сам пакет.

Условно:

binary.BigEndian.PutUint32(frame[0:4], 2) // AF_INET
copy(frame[4:], ipv4Packet)
sshChannel.Write(frame)

После этого обратный трафик наконец пошёл, ssh->tun начал идти, и Windows-клиент стал реально работать.

Маршруты и DNS

По поведению Windows-клиент старается повторять Linux-скрипт.

Обычный full-tunnel режим добавляет два маршрута:

0.0.0.0/1     -> через SSH-TUN
128.0.0.0/1   -> через SSH-TUN

А до самого SSH-сервера добавляется отдельный маршрут через старый gateway, чтобы управляющее SSH-соединение не завернулось внутрь собственного туннеля:

SERVER_IP/32 -> original gateway

Также клиент умеет исключать подсети из туннеля:

.\sshtun_pool_client.exe start `
  --host 46.224.191.37 `
  --key .\sshvpn `
  --exclude-private

Или, наоборот, работать в split-tunnel режиме:

.\sshtun_pool_client.exe start `
  --host 46.224.191.37 `
  --key .\sshvpn `
  --no-full-tunnel `
  --route 10.10.0.0/16

Списки маршрутов можно передавать файлами:

.\sshtun_pool_client.exe start `
  --host 46.224.191.37 `
  --key .\sshvpn `
  --exclude-file .\routes-exclude.txt

Это важно для сценариев, где нужно держать большие списки исключений отдельно от основного клиента.

Поднимаем свой инстанс

После того как Linux и Windows клиенты заработали, проект можно попробовать уже не как лабораторный эксперимент, а как самостоятельный инстанс. Я выложил код в GitHub: там лежит серверный установщик, Linux-клиент и Windows-клиент на Go/Wintun. Проект реализует L3-туннель поверх обычного SSH: сервер поднимает пул tun-интерфейсов, клиент выбирает свободный tunN, подключается по SSH и отправляет трафик через зашифрованный SSH-канал.

Минимальная схема выглядит так:

1. Покупаем VPS

Для тестового инстанса достаточно обычного Linux VPS с публичным IPv4. Нужны root-доступ, systemd, OpenSSH server, iproute2, iptables и доступный TCP-порт. По умолчанию проект использует порт 65523, пользователя sshvpn, пул tun100..tun200, сеть 10.250.0.0/16 и MTU 1400.

После покупки сервера заходим на него по SSH и клонируем репозиторий:

git clone https://github.com/kleimer/vpn_over_ssh.git
cd vpn_over_ssh

2. Устанавливаем серверную часть

На сервере запускаем установщик:

sudo bash install_server.sh

Скрипт создаёт отдельного системного пользователя sshvpn, отдельный конфиг SSHD в /opt/sshtun_pool/sshd_config, отдельный systemd-сервис sshtun-pool-sshd.service, сетевой сервис sshtun-pool-network.service, отдельный host key, включает IPv4 forwarding, поднимает пул tun100…tun200 и добавляет минимальный NAT/forwarding. Важно, что это отдельный SSHD-инстанс на отдельном порту, а не изменение основного SSH на 22/tcp.

Проверяем сервисы:

systemctl status sshtun-pool-sshd.service --no-pager
systemctl status sshtun-pool-network.service --no-pager

Проверяем, что порт слушает:

ss -lntp | grep 65523

3. Генерируем пользовательский SSH-ключ

На клиентской машине или на админской машине генерируем ключ:

ssh-keygen -t ed25519 -f ./id_ed25519 -N "" -C "user-device"

Публичный ключ нужно добавить на сервер в файл:

/opt/sshtun_pool/authorized_keys

Рекомендуемый формат строки:

no-pty,no-agent-forwarding,no-X11-forwarding,no-port-forwarding,no-user-rc ssh-ed25519 AAAAC3... user-device

Для random pool mode не нужно добавлять tunnel="N" в authorized_keys, иначе ключ будет привязан к конкретному номеру tun, и несколько устройств с одним ключом начнут конфликтовать.

После изменения файла проверяем права:

chown root:sshvpn /opt/sshtun_pool/authorized_keys
chmod 640 /opt/sshtun_pool/authorized_keys

4. Подключаемся с Linux

Для Linux используется sshtun_pool_client.sh. Он поддерживает full-tunnel, split-tunnel, include/exclude маршруты, route-файлы, DNS через resolvectl, IPv6 blackhole, lock от параллельных запусков, cleanup старых tunN, passphrase-ключи через ssh-agent или --ask-passphrase, а также команды status, doctor, cleanup.

Обычное подключение:

sudo bash sshtun_pool_client.sh start --host SERVER_IP --key ./id_ed25519

Остановка:

sudo bash sshtun_pool_client.sh stop

Диагностика:

sudo bash sshtun_pool_client.sh status
sudo bash sshtun_pool_client.sh doctor
sudo bash sshtun_pool_client.sh cleanup

5. Собираем Windows-клиент

Windows-клиент лежит в каталоге sshtun_pool_windows_client. Он написан на Go, использует Wintun, собирается в sshtun_pool_client.exe и поддерживает ту же CLI-логику: start, stop, status, doctor, cleanup. Состояние хранится в C:\ProgramData\sshtun_pool_client\state.json, а runtime-лог — в C:\ProgramData\sshtun_pool_client\sshtun.log.

Для сборки нужен Go и PowerShell:

cd sshtun_pool_windows_client
Set-ExecutionPolicy -Scope Process Bypass -Force
.\build.ps1

Скрипт сборки скачает wintun.dll, подтянет Go-модули и соберёт(уже собраный берем тут):

dist\sshtun_pool_client.exe
dist\wintun.dll

Запускать PowerShell нужно от имени администратора:

.\dist\sshtun_pool_client.exe start --host SERVER_IP --key .\id_ed25519

Остановка и диагностика:

.\dist\sshtun_pool_client.exe status
.\dist\sshtun_pool_client.exe doctor
.\dist\sshtun_pool_client.exe stop
.\dist\sshtun_pool_client.exe cleanup

6. Выбираем режим маршрутизации

По умолчанию используется full-tunnel: весь IPv4-трафик уходит через туннель. Для этого клиент добавляет два маршрута 0.0.0.0/1 и 128.0.0.0/1, а до реального IP сервера добавляет отдельный bypass-route через исходный gateway.

Full-tunnel с исключением локальных сетей:

6. Выбираем режим маршрутизации

По умолчанию используется full-tunnel: весь IPv4-трафик уходит через туннель. Для этого клиент добавляет два маршрута 0.0.0.0/1 и 128.0.0.0/1, а до реального IP сервера добавляет отдельный bypass-route через исходный gateway.

Full-tunnel с исключением локальных сетей:

sudo bash sshtun_pool_client.sh start --host SERVER_IP --key ./id_ed25519 --exclude 10.0.0.0/8 --exclude 172.16.0.0/12 --exclude 192.168.0.0/16

На Windows есть короткий вариант:

.\dist\sshtun_pool_client.exe start --host SERVER_IP --key .\id_ed25519 --exclude-private

Split-tunnel, когда через туннель идут только указанные сети:

sudo bash sshtun_pool_client.sh start --host SERVER_IP --key ./id_ed25519 --no-full-tunnel --route 10.10.0.0/16 --route 172.20.0.0/16

Маршруты можно вынести в отдельный файл:

sudo bash sshtun_pool_client.sh start --host SERVER_IP --key ./id_ed25519 --exclude-file ./ru-cidrs.txt

Вместо вывода

В итоге из простой идеи - «а можно ли поднять L3-туннель поверх обычного SSH?» - получился рабочий MVP. Мы проверили ручной ssh -w, вынесли серверную часть в отдельный безопасный SSH-инстанс, добавили пул tun-интерфейсов, NAT, Linux-клиент, Windows-клиент на Go/Wintun, маршрутизацию, исключения подсетей и нормальные команды start, stop, status, cleanup. Важный результат: для такого туннеля не нужен отдельный VPN-сервер - достаточно OpenSSH, правильно настроенного PermitTunnel и аккуратной клиентской логики.

Об авторе:

Я занимаюсь информационной безопасностью более 10 лет, основной профиль — практическое тестирование на проникновение (pentest), расследование инцидентов и анализ защищённости инфраструктур.

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

Код проекта я выложил на GitHub: https://github.com/kleimer/vpn_over_ssh

Если хотите обсудить идею, предложить улучшения, прислать багрепорт или просто написать по теме — можно найти меня в Telegram или в Delta Chat

Проект в статусе MVP: дальнейшая разработка пока не планируется.