Как SSH-туннелирование помогает обходить блокировки
SSH-туннель - это зашифрованный TCP-канал между клиентом и сервером, через который можно пробрасывать трафик к целевым ресурсам. Трафик шифруется на всём пути, а для внешнего наблюдателя выглядит как обычное SSH-соединение с удалённым хостом. Туннель работает поверх стандартного демона OpenSSH, который уже установлен на любом Linux-сервере. Главное преимущество метода: на удалённой стороне не требуется разворачивать VPN-сервер или ставить дополнительное ПО. Достаточно работающего sshd и учётной записи с правом входа.
SSH-туннелирование решает три практические задачи. Первая - доступ к веб-сайту, заблокированному на уровне провайдера или корпоративного файрвола. Вторая - безопасный серфинг через публичные Wi-Fi-сети, где трафик могут перехватывать. Третья - обход ограничений по IP-адресу для внутренних сервисов компании. В отличие от VPN, SSH-туннель не поднимает виртуальный сетевой интерфейс, не меняет таблицу маршрутизации и работает только с TCP-протоколом. Накладные расходы на шифрование минимальны, а настройка сводится к одной команде. Подробнее о сравнении технологий обхода блокировок смотрите в руководстве по диагностике проблем VPN.
SSH-туннель работает в двух режимах. Локальный проброс портов (флаг -L) перенаправляет трафик с локального порта на указанный хост через удалённый сервер. Динамический проброс (флаг -D) поднимает SOCKS5-прокси на локальной машине, через который можно направить трафик любого приложения, поддерживающего прокси-серверы. Оба режима используют исходящее SSH-соединение, поэтому туннель проходит через большинство файрволов, которые не блокируют порт 22.
Подготовка внешнего сервера для SSH-туннеля
Для туннеля нужен VPS за пределами зоны блокировок. Минимальные требования: 128 МБ ОЗУ, одно ядро, любой современный дистрибутив Linux. Подойдёт Debian 12, Ubuntu 24.04 LTS или AlmaLinux 9. Сервер должен иметь публичный IP-адрес и работающий демон SSH. Если у вас ещё нет подходящего сервера, присмотритесь к облачным VDS от Timeweb Cloud - они предоставляют готовые виртуальные машины с предустановленным Linux и возможностью гибкого масштабирования ресурсов.
После создания сервера выполните базовую настройку. Обновите пакеты и убедитесь, что SSH-демон запущен:
apt update && apt upgrade -y
systemctl status sshdРекомендую сменить стандартный порт 22 на значение выше 1024 - это отсечёт большую часть автоматических сканеров и ботов. Отредактируйте /etc/ssh/sshd_config:
Port 2222Перезапустите демон: systemctl restart sshd. Проверьте, что новый порт слушается: ss -tulpn | grep 2222. Не закрывайте текущую сессию до тех пор, пока не убедитесь, что новое подключение по нестандартному порту работает.
Усиление безопасности: генерация SSH-ключей и отключение парольной аутентификации
Парольная аутентификация - главный вектор атак на SSH. Боты перебирают типовые учётные записи круглосуточно. Решение - переход на вход по ключам с полным отключением паролей. На клиентской машине сгенерируйте ключевую пару Ed25519 - этот алгоритм быстрее RSA и устойчив к атакам на стороне канала:
ssh-keygen -t ed25519 -C "your_email@example.com"Утилита предложит задать парольную фразу для ключа. Парольная фраза добавляет второй фактор: даже если ключ украдут, без неё злоумышленник не сможет подключиться. Для автоматизированных туннелей фразу можно оставить пустой, но тогда защита ключа ложится на права файловой системы.
Скопируйте публичный ключ на сервер:
ssh-copy-id -p 2222 user@your_server_ipПосле успешного копирования подключитесь по ключу и отредактируйте /etc/ssh/sshd_config на сервере:
PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yesПроверьте синтаксис конфигурации командой sshd -t и перезагрузите демон: systemctl reload sshd. Критически важно: перед отключением парольной аутентификации протестируйте вход по ключу в новой терминальной сессии. Если ключ не работает, а пароль уже отключён, вы потеряете доступ к серверу. Детально настройка аутентификации разобрана в руководстве по защите веб-интерфейсов сервера.
Создание SOCKS5-прокси через SSH
Динамический проброс портов - самый универсальный режим. Он поднимает SOCKS5-прокси на локальной машине и пропускает через туннель трафик любого приложения, умеющего работать с прокси. Команда для запуска:
ssh -D 1080 -f -C -q -N -p 2222 user@your_server_ipРазбор флагов:
-D 1080- открыть SOCKS5-прокси на локальном порту 1080. Порт можно выбрать любой свободный выше 1024.-f- отправить процесс в фон после аутентификации.-C- включить сжатие данных. Полезно для медленных каналов, но добавляет нагрузку на процессор.-q- тихий режим, подавляет диагностические сообщения.-N- не выполнять удалённые команды, только проброс портов.-p 2222- порт SSH-демона, если он отличается от стандартного.
После запуска настройте браузер на использование прокси. В Firefox: Настройки → Основные → Параметры сети → Настроить прокси-сервер вручную. Укажите SOCKS-хост 127.0.0.1, порт 1080, версия SOCKS5. Отметьте опцию «Проксировать DNS-запросы через SOCKS5» - это предотвратит утечку DNS-запросов через локального провайдера. В Chrome прокси настраивается через системные параметры или расширения вроде FoxyProxy, которое позволяет переключать прокси одним кликом.
Проверьте, что трафик идёт через туннель: откройте любой сервис определения IP-адреса. Внешний IP должен совпадать с IP вашего VPS. Если адрес не изменился, проверьте настройки прокси в браузере и убедитесь, что SSH-процесс запущен: ps aux | grep "ssh -D".
Локальный проброс портов для отдельных ресурсов
Когда нужен доступ только к одному сайту или сервису, поднимать полноценный SOCKS5-прокси избыточно. Локальный проброс перенаправляет конкретный порт на вашей машине на целевой хост через SSH-сервер. Синтаксис:
ssh -L локальный_порт:целевой_хост:целевой_порт пользователь@серверПример: внутренний корпоративный портал доступен только с IP-адресов офисной сети и висит на хосте internal.example.com порт 80. SSH-сервер находится в офисной сети и имеет доступ к порталу. Пробрасываем доступ на локальный порт 8080:
ssh -L 8080:internal.example.com:80 -p 2222 user@office_gatewayПосле выполнения команды откройте браузер и перейдите по адресу http://localhost:8080. Трафик пойдёт по цепочке: браузер → localhost:8080 → SSH-клиент → зашифрованный туннель → SSH-сервер → internal.example.com:80. Для внешнего наблюдателя соединение выглядит как SSH-трафик между вашей машиной и сервером-шлюзом.
Важный нюанс: SSH-сервер должен иметь сетевой доступ к целевому хосту. Если сервер не может разрешить DNS-имя internal.example.com, используйте IP-адрес. При конфликте локальных портов выберите другой свободный порт - проверка занятых портов выполняется командой ss -tulpn | grep ПОРТ.
Настройка SSH-туннеля в Windows через PuTTY
В Windows 10/11 встроенный OpenSSH-клиент доступен через PowerShell или Windows Terminal, и команды из предыдущих разделов работают без изменений. Однако многие администраторы предпочитают графический инструмент PuTTY для наглядной настройки и сохранения профилей подключений.
Создание SOCKS5-прокси в PuTTY:
- Запустите PuTTY, введите IP-адрес сервера и порт SSH в разделе Session.
- В дереве слева перейдите: Connection → SSH → Tunnels.
- В поле Source port введите
1080. - Отметьте опцию Dynamic.
- Нажмите Add - в списке появится запись
D1080.
Для локального проброса порта:
- В поле Source port введите
8080. - В поле Destination введите
internal.example.com:80. - Отметьте опцию Local.
- Нажмите Add - появится запись
L8080 internal.example.com:80.
Вернитесь в раздел Session, введите имя профиля и нажмите Save. При следующем запуске достаточно выбрать сохранённую сессию и нажать Load. После подключения туннель работает точно так же, как при использовании консольного клиента - браузер настраивается на 127.0.0.1:1080 или открывается http://localhost:8080.
Диагностика и решение типичных проблем
Connection refused - сервер отклонил входящее соединение. Причины: SSH-демон не слушает указанный порт, файрвол блокирует подключение, сервер физически недоступен. Проверьте, что порт открыт на сервере: ss -tulpn | grep ПОРТ. Убедитесь, что правило файрвола разрешает входящие соединения: iptables -L -n | grep ПОРТ или firewall-cmd --list-ports. Для диагностики сетевой доступности используйте telnet server_ip порт с клиентской машины.
Permission denied (publickey) - сервер отклонил аутентификацию по ключу. Проверьте права доступа к файлам ключей на клиенте: приватный ключ должен иметь права 600 (chmod 600 ~/.ssh/id_ed25519), каталог .ssh - права 700. Убедитесь, что публичный ключ добавлен в ~/.ssh/authorized_keys на сервере и права на этот файл - 600. Проверьте, что в sshd_config не запрещена аутентификация по ключам (PubkeyAuthentication yes).
Туннель работает, но сайт не открывается - проблема на стороне SSH-сервера. Сервер не может разрешить DNS-имя целевого хоста. Решение: используйте IP-адрес вместо домена в команде проброса. Проверьте разрешение имён на сервере: nslookup target_host. Если DNS не работает, настройте публичные резолверы в /etc/resolv.conf.
Обрыв соединения при неактивности - SSH-сессия разрывается по таймауту на стороне сервера или клиента. На сервере в /etc/ssh/sshd_config добавьте:
ClientAliveInterval 60
ClientAliveCountMax 3На клиенте в ~/.ssh/config пропишите для целевого хоста:
Host your_server
ServerAliveInterval 60
ServerAliveCountMax 3Эти опции заставляют стороны обмениваться keepalive-пакетами каждые 60 секунд и разрывать соединение после трёх неудачных попыток.
Автоматизация и поддержание туннеля активным
Для продакшен-сценариев ручной запуск туннеля не подходит. Соединение может оборваться из-за нестабильности сети, перезагрузки сервера или таймаута. Инструмент autossh отслеживает состояние туннеля и автоматически переподключается при обрыве. Установите autossh: apt install autossh (Debian/Ubuntu) или yum install autossh (RHEL/AlmaLinux).
Базовая команда для постоянного SOCKS5-прокси:
autossh -M 0 -D 1080 -f -C -q -N -p 2222 user@your_server_ipФлаг -M 0 отключает мониторинг-порт autossh и полагается на встроенный механизм проверки соединения через дочерний процесс ssh. Это надёжнее и не требует дополнительного открытого порта.
Для запуска туннеля при загрузке системы создайте systemd-сервис. Файл /etc/systemd/system/ssh-tunnel.service:
[Unit]
Description=SSH Tunnel SOCKS5 Proxy
After=network-online.target
Wants=network-online.target
[Service]
User=your_local_user
ExecStart=/usr/bin/autossh -M 0 -D 1080 -N -p 2222 user@your_server_ip
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.targetАктивируйте сервис:
systemctl daemon-reload
systemctl enable --now ssh-tunnel.service
systemctl status ssh-tunnel.serviceОбязательное условие для бесперебойной работы: аутентификация должна выполняться по ключу без парольной фразы. Если ключ защищён фразой, systemd-сервис не сможет её ввести и туннель не поднимется. Создайте отдельную ключевую пару специально для туннеля и ограничьте её использование командой command="/bin/false" в authorized_keys на сервере - это запретит выполнение любых команд при компрометации ключа. Подробнее о настройке безопасного доступа читайте в руководстве по раздельному туннелированию VPN.
Для мониторинга состояния туннеля достаточно простого скрипта, который проверяет доступность SOCKS-порта:
#!/bin/bash
if ss -tulpn | grep -q 1080; then
echo "Tunnel is active"
else
echo "Tunnel is down, restarting..."
systemctl restart ssh-tunnel.service
fiДобавьте скрипт в cron с интервалом в 5 минут, и туннель будет восстанавливаться даже при падении systemd-сервиса.
SSH-туннелирование - проверенный инструмент, который работает на любом Linux-сервере без дополнительного ПО. Настроенный один раз туннель с autossh и systemd-сервисом обеспечивает стабильный обход блокировок на месяцы вперёд. Для задач, требующих обхода глубокой инспекции пакетов (DPI), SSH-туннеля может быть недостаточно - в таких случаях обратитесь к руководству по VPN-маршрутизации с маскировкой трафика, где разобраны методы обхода DPI с помощью VLESS и Shadowsocks.