Двухсерверный homelab: VPN как основа закрытой инфраструктуры

Домашний сервер быстро перестаёт быть игрушкой, когда на нём появляются Nextcloud, Vaultwarden, медиатека, DNS-фильтрация, мониторинг и личные панели управления. Главная инженерная задача в такой схеме — безопасно связать домашнее железо с внешним интернетом и сохранить контроль над тем, какие сервисы видны снаружи. Практичный вариант для homelab — разделить роли между недорогим VPS и домашним мини-ПК, а связующим слоем сделать VPN.

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

Почему простого туннеля хватает только на старте

Для первых экспериментов часто достаточно готового туннельного сервиса или reverse proxy. Такие решения удобны: запускаешь контейнер, указываешь токен, получаешь домен и проброс до локального Nginx. Проблема проявляется позже, когда инфраструктура становится личной платформой, а не набором тестовых контейнеров.

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

Следующий шаг — свой VPS и L4-проброс через FRP или похожий инструмент. Удалённый сервер пересылает TCP-потоки, локальный Nginx завершает TLS и маршрутизирует запросы в Docker-сеть. Реальные IP сохраняются через proxy protocol, а один маленький VPS заменяет набор внешних услуг.

Когда VPN становится правильным фундаментом

Reverse proxy решает задачу доставки трафика, но оставляет часть внутренних ресурсов в зоне публичного доступа. Даже если поверх стоит HTTPS, basic auth или дополнительная авторизация, порты всё равно видны сканерам, а ошибки конфигурации быстро становятся риском. VPN меняет модель доступа: участники становятся узлами одной приватной сети, а веб-приложения можно публиковать только для адресов из внутреннего диапазона.

Для homelab подходит WireGuard или совместимые реализации вроде AmneziaWG. На VPS поднимается управляющий узел, например wg-easy, а домашний сервер подключается как клиент. В результате появляется подсеть вида 10.8.0.0/24, где VPS, домашний сервер и пользовательские устройства общаются напрямую.

Важная деталь — фиксировать версии контейнеров. Тег latest для сетевой инфраструктуры опасен: он может указывать на старую ветку, менять поведение после обновления или не содержать нужных возможностей. Для WireGuard-панели, reverse proxy, DNS и мониторинга лучше использовать конкретные версии и обновлять их осознанно.

Nginx как контролируемый вход в сервисы

После появления VPN Nginx перестаёт быть просто публичным прокси. Он становится пограничным контроллером доступа. На VPS можно принять HTTPS, сохранить реальный адрес клиента, затем отправить трафик по туннелю на домашний сервер. Локальный Nginx проверяет диапазоны адресов и пропускает запросы только из доверенной подсети.

Базовая логика выглядит так:

публичный DNS указывает на VPS;
TLS-сертификаты обслуживаются на внешнем узле или передаются дальше по выбранной схеме;
запросы к приватным приложениям проходят через VPN;
локальный reverse proxy разрешает 10.8.0.0/24, loopback и служебные Docker-сети;
остальные обращения получают отказ ещё до приложения.

Такой слой особенно полезен для Vaultwarden, Nextcloud, AdGuard Home, Grafana, Portainer и панелей управления. Сами сервисы остаются в обычных Docker-контейнерах, но наружу попадает только контролируемый маршрутизированный вход.

Сертификаты без открытого HTTP-порта

Для закрытой инфраструктуры удобно выпускать wildcard-сертификат через DNS-01 challenge. Домен может указывать на внутренний VPN-адрес, а порт 80 не требуется открывать в интернет. Certbot обновляет TXT-записи через API DNS-провайдера и получает сертификат для домена и поддоменов.

Пользователь заходит на vault.example.com, браузер видит нормальный сертификат, а маршрут фактически проходит через VPN. Для мобильных клиентов это удобнее самоподписанных сертификатов и ручной установки локального CA.

Декларативное развертывание вместо ручных скриптов

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

Ansible лучше подходит для такой инфраструктуры. В плейбуках описывается желаемое состояние: системные пакеты, пользователи, Docker, директории, шаблоны Nginx, .env, сертификаты, systemd-юниты и конфигурации приложений. Повторный запуск становится нормальным рабочим сценарием: выполненные шаги пропускаются, изменённые шаблоны обновляются, сервисы перезапускаются только при необходимости.

Секреты стоит держать отдельно: пароли, токены и ключи подставляются в шаблоны Jinja2 во время деплоя. Для миграции полезна понятная структура apps-data: перенос сводится к копированию директории с данными и повторному запуску плейбука.

Бэкапы и консистентность контейнеров

Личный сервер без бэкапов — отложенная авария. Для homelab хорошо подходит Borgmatic поверх Borg: дедупликация, шифрование, политика хранения и автоматизация через systemd timer. В копию попадают конфигурации, базы данных, файлы Nextcloud, медиатека и документы.

Частая ошибка — копировать живые директории баз данных без подготовки. Если контейнер активно пишет в PostgreSQL, SQLite или файловое хранилище, архив может получиться неконсистентным. Надёжная схема включает хуки: перед архивом остановить контейнеры, после завершения поднять их обратно.

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

Наблюдаемость для маленькой инфраструктуры

Homelab тоже нуждается в мониторинге. Если домашний сервер упал, локальный мониторинг на этом же сервере не отправит уведомление. Поэтому внешний сторож лучше держать на VPS. Gatus удобен тем, что описывает проверки в YAML: HTTP health-check домашнего сервера, доступность VPS, срок действия сертификата, статусы ключевых приложений. Уведомления можно отправлять в Telegram.

Для метрик достаточно связки node-exporter, cAdvisor, Prometheus и Grafana. Она покажет загрузку CPU, память, диски, контейнеры и сетевые симптомы. Для логов хорошо работает Loki с Grafana Alloy: агент читает Docker-логи, добавляет метки сервера и контейнера, отправляет события в централизованное хранилище. После этого ошибки Nginx, падения приложений и проблемы фоновых задач можно искать через LogQL, а не через SSH на каждый узел.

Практичная схема для развития

Хорошая двухсерверная homelab-архитектура строится вокруг нескольких принципов: публичный IP остаётся на VPS, данные живут дома, доступ к сервисам идёт через VPN, конфигурация описана декларативно, бэкапы проверяются, мониторинг расположен вне основной точки отказа. Такая схема требует больше времени на стартовую настройку, зато даёт предсказуемость и ясные границы.

Дальше можно добавить SSO, отдельное хранилище секретов, регулярные restore-тесты и GitOps для конфигураций. Основа остаётся простой: один VPS, один домашний сервер, закрытая VPN-сеть, аккуратный reverse proxy и автоматизированный деплой.