Самый простой способ получить удалённый доступ к домашнему серверу - купить у провайдера статический «белый» IP (обычно 100–200 ₽/мес). Если же у вас уже есть арендованный VPS с публичным IP (например, для сайта, VPN или других проектов), его можно использовать как мост для доступа к серверу, сэкономив на покупке статического IP. В этой статье я расскажу, как настроил обратный SSH-туннель через существующий VPS, чтобы стабильно подключаться к своему домашнему серверу, находящемуся за NAT от провайдера.

Проблема - динамический IP и двойной NAT у провайдера

Многие домашние интернет-провайдеры (МТС, Билайн, Ростелеком и др.) выдают абонентам динамические IP-адреса, которые могут меняться при каждом подключении. Это само по себе неудобно для удалённого доступа (нужно узнавать актуальный IP). Но ещё хуже, что всё чаще провайдеры используют NAT операторского уровня (CG-NAT). Ваш роутер получает серый IP из внутреннего диапазона, а один белый внешний IP-адрес разделяется на стороне провайдера между несколькими абонентами. Происходит двойная трансляция адресов, и ваш домашний сервер скрыт сразу за двумя уровнями NAT – на роутере и у провайдера.

Раньше NAT был в твоём роутере - он получал белый IP с выходом в глобальную сеть, и ты спокойно настраивал проброс портов. Теперь же NAT перенесён на сторону провайдера - на уровень дома или района. Твой роутер получает серый IP из внутреннего диапазона, а внешний белый IP, доступный из интернета, остаётся на оборудовании провайдера. Где-то в районе или подъезде стоит общий маршрутизатор с этим белым IP, и уже от него трафик раздаётся абонентам с серыми адресами. В такой схеме DDNS, который автоматически сопоставляет доменное имя с изменяющимся IP-адресом вашего роутера, уже не работает.

При такой проблеме никакие динамические DNS(DDNS), которые автоматически сопоставляли доменное имя с изменяющимся IP-адресом вашего роутера, не помогут. Даже узнав текущий внешний адрес, вы не можете пробросить порты на свой сервер - внешний IP принадлежит провайдеру, а не вашему роутеру. Любой входящий запрос «тонет» на уровне провайдерского NAT.

Варианты решений

Простой, но платный

Заказать у провайдера индивидуальный статический IP-адрес. В этом случае ваш роутер получит белый IP, и тогда можно настроить проброс портов как обычно. Этот путь самый прямой (никаких туннелей не нужно), но ежемесячно придётся платить небольшую сумму (100-200 руб). Если у вас нет VPS и не планируется, то покупка статического IP, пожалуй, оптимальнее.

Обойти NAT через внешние сервисы

Cуществуют решения вроде TeamViewer/AnyDesk для удалённого рабочего стола, P2P VPN-сети типа Tailscale/ZeroTier, или Cloudflare Tunnel для веб-приложений. Они могут выручить в некоторых случаях, но имеют свои ограничения (о них – позже).

Мой подход

Сспользовать уже имеющийся VPS с публичным IP в качестве промежуточного сервера. Идея в том, что домашний сервер сам инициирует подключение к внешнему VPS и держит канал открытым. Через этот канал мы сможем зайти на домашний сервер из любой точки, обходя NAT. Для реализации подойдёт стандартный инструмент SSH (Secure Shell), а именно – обратный SSH-туннель.

Обратный SSH-туннель через VPS

Что мы получаем? Домашний сервер устанавливает SSH-соединение наружу, на VPS, и открывает на нём порт, проброшенный обратно в домашнюю сеть. VPS с белым IP выступает мостом, подключаемся к нему – и попадаем на свой сервер. Схема выглядит так:

• Домашний сервер (за NAT) → исходящее SSH-подключение → VPS (публичный IP)

• На VPS через SSH открывается порт, соединённый туннелем с нашим домашним сервером.

• Клиент (ноутбук, телефон и т.д. в любом месте) подключается по SSH к VPS (на этот открытый порт) и попадает на сервер дома.

Преимущество подхода – соединение устойчиво, даже если домашний IP изменится, сервер сам переподключится. Внешне мы всегда коннектимся на постоянный адрес VPS. Разумеется, VPS должен быть онлайн 24/7, но если вы и так арендуете VPS для других задач, это не проблема.

Далее подробно рассмотрим настройку.

Шаг 1: Настройка SSH на VPS

На VPS (под управлением Linux) нужно убедиться, что SSH-сервер допускает обратный туннель на внешний интерфейс. Откроем конфиг /etc/ssh/sshd_config и добавим (или изменим) несколько параметров:

Port 2222 # на ваш выбор
GatewayPorts yes
ListenAddress 0.0.0.0
ListenAddress ::

• Port 2222 – используем нестандартный порт для SSH на самом VPS (можно оставить 22, но я выбрал 2222 для изоляции). Не забудьте открыть этот порт в фаерволе VPS.

• GatewayPorts yes – ключевой параметр, разрешающий SSH-туннелю слушать на всех интерфейсах. Без него удалённый порт по умолчанию открывается только на localhost самого VPS, и внешние подключения не будут проходить.

• ListenAddress 0.0.0.0 / :: – явно указываем, что SSH-сервер принимает подключения на всех сетевых интерфейсах (и по IPv4, и по IPv6). После правки конфига применяем изменения:

sudo systemctl restart sshd

Теперь SSH на VPS запущен на порту 2222 и готов принимать обратные туннели, делая их доступными извне.

Шаг 2: Обратный SSH-туннель с домашнего сервера

Далее настроим сам туннель. Удостоверьтесь, что на домашнем сервере запущен SSH-клиент и имеется доступ в интернет. Для начала можно попробовать вручную открыть туннель командой:

ssh -N -R 2223:localhost:22 <user>@<vps-api> -p 2222

Где <user> - имя пользователя на VPS (под которым разрешён вход по SSH), <vps-api> – публичный IP-адрес вашего VPS. Параметры этой команды:

• -R 2223:localhost:22 говорит SSH создать reverse-перенаправление: открыть на удалённой машине (VPS) порт 2223 и слать всё, что на него придёт, на localhost:22 со стороны инициатора (т.е. нашего домашнего сервера).

• -N означает не выполнять удалённых команд (SSH-сессия будет использоваться только для туннеля).

• Опция -p 2222 указывает нестандартный порт SSH на VPS (который мы задали в шаге 1). Запустив эту команду, проверьте на VPS, что порт 2223 открылся (например, через ss -tnlp или netstat). Если всё сделано правильно, на VPS должно слушаться соединение на 0.0.0.0:2223 (благодаря GatewayPorts yes).

Шаг 3: Настройка autossh для удержания обратного SSH-туннеля

Конечно, запускать такой туннель вручную каждый раз неудобно. Кроме того, соединение может разорваться, например, при потере связи, и нужно автоматически восстанавливать туннель. Для этого используется утилита autossh, которая будет перезапускать SSH-туннель в случае сбоев. Мы создадим сервис systemd для автоматического поднятия туннеля при старте системы и поддержки его в рабочем состоянии.

Настройка autossh на домашнем сервере:

1. Установка autossh:

   sudo apt install autossh

   (В дистрибутивах на базе Debian/Ubuntu.)

2. Создание сервиса: Откройте новый файл сервиса:

   sudo nano /etc/systemd/system/autossh-tunnel.service

   Заполните его следующим содержимым:

   конфигурация

   [Unit]
   Description=Autossh reverse tunnel service
   After=network.target
   
   [Service]
   User=<имя_пользователя_на_домашнем_сервере>
   Environment="AUTOSSH_GATETIME=0"
   ExecStart=/usr/bin/autossh -M 0 -N \
       -o "ServerAliveInterval 30" \
       -o "ServerAliveCountMax 3" \
       -R 2223:localhost:22 \
     <user>@<vps-api> -p 2222
   Restart=always
   RestartSec=10
   
   [Install]
   WantedBy=multi-user.target

   Здесь <user>@<vps-api> аналогично предыдущей команде – учётная запись на VPS и его адрес. Параметры ServerAliveInterval и ServerAliveCountMax нужны для контроля соединения: если в течение 30×3=90 секунд не будет ответа от VPS, туннель перезапустится. Опция -M 0 отключает выделение отдельного порта мониторинга (autossh будет полагаться на keep-alive пакеты). Переменная окружения AUTOSSH_GATETIME=0 позволяет не ждать перед перезапуском при обрыве (по умолчанию autossh делает паузу перед повторным стартом).

3. Включение и запуск сервиса: Сохраните файл и выйдите из редактора. Активируем сервис и запускаем:

   sudo systemctl daemon-reload
   sudo systemctl enable autossh-tunnel.service
   sudo systemctl start autossh-tunnel.service

   Теперь обратный туннель будет подниматься автоматически при загрузке домашнего сервера и восстанавливаться при разрывах связи. Для уверенности можно перезагрузить машину и убедиться, что порт на VPS снова открылся.

? Совет по безопасности: Настройте вход по SSH-ключам между домашним сервером и VPS. Сервис autossh подразумевает автоматическое подключение, и использование ключа (без парольной фразы или с фразой, подключённой через ssh-agent) избавит от необходимости ввода пароля вручную. Также можно завести на VPS отдельного пользователя с ограниченными правами, предназначенного только для туннеля.

Шаг 4: Подключение к домашнему серверу через VPS

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

ssh -p 2223 <user>@<vps-api>

Порт 2223 указан, потому что SSH на VPS слушает туннель именно там и пробрасывает на порт 22 нашего сервера. При подключении вы фактически проходите через VPS и авторизуетесь уже на своём домашнем сервере (введите его пароль или настройте авторизацию по ключу).

Для удобства можно добавить соответствующий alias/настройку в SSH-конфиг на ваших клиентских машинах. Например, добавьте в ~/.ssh/config такой блок:

Host home-server
    HostName <vps-api>
    Port 2223
    User <user_ot_home>

После этого подключаться будет проще командой ssh home-server. Аналогично можно прописать alias для SCP/RSYNC, если планируете копировать файлы на сервер.

Альтернативы и размышления

На встрече питонистов в баре (да, даже там обсуждаем сети!) я поделился этой задачей – как попасть на домашний сервер за NAT. Вспоминали университетский курс по сетям и разбирались, почему простой динамический DNS не спасает.

Мы обсудили и другие способы. Одно из современных решений - Cloudflare Tunnel от Cloudflare. Оно позволяет поднять исходящее соединение с домашнего сервера к облаку Cloudflare и тем самым открыть доступ извне через специально сгенерированный адрес (можно подвязать и свой домен). Плюс в том, что не нужен ни белый IP, ни свой VPS - трафик идёт через инфраструктуру Cloudflare. К сожалению, для моего сценария этот вариант не подошёл, бесплатный Cloudflare Tunnel имеет ограничение на размер передаваемых файлов около 100 МБ. Этого хватит, чтобы удалённо управлять сервером или хостить небольшой веб-сайт, но для резервного копирования фотографий и видео уже мало. В платных планах лимиты больше, однако тогда проще вернуться к идее собственного VPS или статического IP.

Итоги

Проделанная настройка показала себя отлично - VPS теперь служит надежным мостом для доступа к домашнему серверу, спрятанному за NAT. Туннель держится автоматически (спасибо autossh), и я могу в любой момент подключиться по SSH к своим данным и приложениям из любой точки мира.

Важно подчеркнуть - если у вас уже есть VPS, который вы собираетесь арендовать и дальше (например, он нужен для веб-сайта, почтового сервера, VPN и т.п.), то использовать его же для доступа к домашнему серверу – логично и не требует дополнительных трат. Вы убиваете двух зайцев одним выстрелом. Однако если никакого VPS у вас нет и заводить его ради этой цели не планируется, зачастую проще оформить статический IP у провайдера (или поискать альтернативные облачные сервисы). Каждый должен оценить, что выгоднее и удобнее в его случае.

На этом всё. Надеюсь, статья была полезной. Если будут вопросы или идеи, то добро пожаловать в комментарии.

Спасибо за внимание и стабильного вам коннекта! ✌️

Контакты для связи:
Тг: https://t.me/Mihey_83
Тг канал: https://t.me/miheev_83