Удалённый доступ к домашним сервисам: как сделать его по-настоящему защищённым — и когда это вырастает в корпоративный VPN

Дома у меня стоит сервер. На нём не «умный дом ради хайпа», а обычный набор: NAS с фото и бэкапами, медиатека, синхронизация файлов, пара внутренних сервисов, к которым я привык. До всего этого нужно добираться извне — с ноутбука в поездке, с телефона, иногда из офиса.

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

Значит, вопрос звучит так: можно ли сделать удалённый доступ действительно защищённым? И что менять, если завтра тот же доступ понадобится не только мне, но и небольшой компании.

Дальше — разбор без обещаний «непробиваемости».

«Максимально защищённый» — это вообще возможно?

Короткий ответ: абсолютной защиты не бывает, и любой, кто обещает обратное, продаёт вам что-то не то. Правильный вопрос звучит не «как сделать максимально защищённо», а «от кого мы защищаемся». В домашнем контуре угрозы выглядят так:

Из этой таблицы есть практический вывод, который важнее выбора любого софта: наружу не должен смотреть ни один сервис. Единственная открытая дверь — VPN, и она узкая. Всё остальное — домашние админки, NAS, медиасерверы — доступно только через неё.

Это и есть «максимально защищённо» в разумной трактовке: не «взломать невозможно», а «поверхность атаки минимальна, и каждый вход логируется».

Сервисы спрятаны за периметром, наружу смотрит единственный шлюз — VPN.

Три варианта архитектуры — честно, с плюсами и минусами

Выбор начинается не с софта, а с топологии. И тут есть неприятная деталь: домашний интернет всё чаще за CGNAT, то есть публичного IP у вас нет вообще. Вариантов от этого три.

A. Публичный IP у дома → VPN стоит на домашнем сервере

Классика: у вас есть публичный адрес (или провайдер даёт его за доплату), вы пробрасываете наружу только один порт — VPN, а все сервисы спрятаны за ним.

• Плюсы: полный контроль, данные не покидают дом, сервисы физически рядом с вами.

• Минусы: домашний канал становится узким местом и точкой отказа; отключили свет или упал интернет — доступа нет; следить за обновлениями нужно самому.

B. Публичного IP нет (CGNAT) → точка входа на VPS

Вы арендуете недорогой VPS на KVM (не OpenVZ — на нём часто нет модуля tun, нужного OpenVPN), он держит публичный адрес и принимает VPN-подключения, а домашняя сеть подключается к нему туннелем. Машина с обычным клиентом — лишь часть схемы; для связки «площадок» в Pritunl есть отдельный механизм Link, но важно понимать: pritunl-link — это отдельный компонент, который нельзя запускать на том же сервере, где стоит сам Pritunl (так написано в документации, и это не мелочь, а дополнительный хост).

• Плюсы: стабильный публичный адрес, независимость от домашнего канала ISP, удобно масштабируется до нескольких площадок.

• Минусы: платите за VPS, схема сложнее, добавляется второй узел, который тоже надо обновлять.

C. Mesh-VPN (Tailscale, ZeroTier и подобные)

Самый быстрый путь для дома: агент ставится на сервер и на клиентов, они находят друг друга сами, проброс портов не нужен.

• Плюсы: настраивается за десять минут, работает за CGNAT, меньше инфраструктуры.

• Минусы: координацию и маршрутизацию обеспечивает третья сторона; вы зависите от её доступности и политики; «своего контура» в строгом смысле не получается.

Для сценария «домашний сервер с 2–3 сервисами, всё для себя» вариант C часто рациональнее — и это нормальный выбор, а не «неправильный». Варианты A и B выбирают, когда нужен свой контур, полный контроль и задел на то, чтобы завтра подключить к этому сотрудников.

Три схемы слева направо: прямой вход через публичный адрес, вход через VPS-релей, распределённая mesh-сеть.

Базовая гигиена: важнее, чем выбор софта

Пока это не сделано, любой VPN и любая панель — украшение. Список короткий, но его надо выполнить весь.

1. Ни одного сервиса наружу. Наружу — только VPN-порт (и 80/443 для сертификата). Всё остальное — изнутри туннеля.

2. Второй фактор. Для VPN это TOTP в клиенте (или SSO), для админок — тоже. Пароль без второго фактора в 2026-м не считается защитой.

3. Обновления. Контейнеры и ОС. Зафиксированные версии — это не «поставил и забыл», а «обновляю осознанно и знаю, что обновляю».

4. Сегментация. Сервисы — в отдельной подсети. Даже если один сервис скомпрометирован, он не должен видеть всё остальное.

5. Изоляция контейнеров. Минимум прав у VPN-контейнера: NET_ADMIN и доступ к /dev/net/tun, без privileged.

6. Бэкапы. От опечатки, от шифровальщика, от «диск умер». Бэкап на том же диске не считается бэкапом.

7. Журнал входов. Кто и когда подключился. Это и безопасность, и диагностика: «интернет медленный» часто оказывается чьим-то забытым подключением.

8. Split-tunnel там, где он уместен. Для дома это критично: через VPN должен идти трафик только к домашней подсети, а не весь интернет. Иначе вы собственноручно сделаете себе «медленный интернет».

Как это выглядит в командах

Схема для варианта A (публичный адрес) или B (VPS как точка входа) одинаковая: reverse-proxy с автоматическим HTTPS, VPN-сервер и база для его настроек.

Проверить, что железо вообще подходит, стоит до всего остального — модуль tun нужен OpenVPN, и на OpenVZ-хостингах его часто нет:

lsmod | grep -E '^tun|^wireguard'

Минимальная подготовка:

sudo apt update && sudo apt install -y docker.io docker-compose-plugin

sudo ufw default deny incoming
sudo ufw allow 22/tcp      # SSH
sudo ufw allow 80/tcp      # проверка домена для сертификата
sudo ufw allow 443/tcp     # панель управления
sudo ufw allow 1194/udp    # VPN
sudo ufw enable

Обратите внимание, чего в списке нет: порта веб-панели Pritunl (9700). Он не должен быть открыт наружу ни при каком варианте.

Дальше — стек: nginxproxy/nginx-proxy + nginxproxy/acme-companion (не устаревшие jwilder/* и jrcs/*), Pritunl и MongoDB. База — обязательно с паролем:

openssl rand -hex 24   # пароль без @ : / ?, иначе он ломает строку подключения

Первый вход в панель — по ключу из контейнера:

docker compose exec pritunl pritunl setup-key

И самая важная настройка после — маршруты. Для дома в маршруты добавляется только домашняя подсеть (например, 192.168.1.0/24), а не 0.0.0.0/0. Для компании — рабочие подсети по списку.

Проверка, что панель отдаётся через прокси (а не напрямую по IP):

curl -sI -H 'Host: vpn.example.com' http://127.0.0.1/ | head -1
curl -sk -o /dev/null -w '%{http_code}\n' -H 'Host: vpn.example.com' https://127.0.0.1/login

Пять мест, где на этой схеме теряют время

Набор типовой, я собрал его сам, по одному пункту за вечер.

1. proxy_pass указывает на контейнер, которого нет → 503 при живом бэкенде. Причина обычно в copy-paste: container_name и хост в proxy_pass должны совпадать буква в букву.

2. Двойное проксирование — внешний прокси, потом промежуточный nginx, потом приложение. Лишний слой и лишняя точка отказа. Настройки промежуточного слоя переносятся в конфиги reverse-proxy.

3. Смонтирован каталог /etc/nginx/conf.d → read-only file system, прокси не может сгенерировать свой конфиг. Монтировать нужно отдельный файл, а не каталог.

4. База на bind-mount с «ненастоящей» файловой системы (сетевой диск, эмуляция поверх Windows) → WiredTiger: Operation not permitted. Движку нужна нормальная ФС; для данных подходит docker volume, а бэкап всё равно делать дампом.

5. HTTPS не открывается, потому что сертификата ещё нет. До выпуска сертификата nginx отвечает ssl_reject_handshake, браузер показывает ошибку, curl возвращает 000. Это не поломка: смотрите логи acme-контейнера и проверяйте, что домен резолвится на ваш сервер.

OpenVPN или WireGuard

Оба варианта поддерживаются Pritunl, и выбор не такой очевидный, как «WireGuard быстрее, значит он».

WireGuard быстрее, экономнее по батарее, лучше ведёт себя при переключении сетей у мобильного клиента. Но у него есть особенность: клиенту нужен доступ к HTTPS-порту сервера, потому что подключение аутентифицируется через веб-сервис. В схеме, где HTTPS терминируется на reverse-proxy, это добавляет настроек и ограничений. Если вы поднимаете WireGuard «напрямую» — всё просто; если за прокси — придётся аккуратнее.

OpenVPN медленнее, зато предсказуемее и совместимее: любой клиент, любая ОС, никаких объяснений «почему у тебя не тот клиент». Для домашнего контура, который вы настраиваете один раз и редко трогаете, это весомый аргумент.

Разумный компромисс: начать с OpenVPN и включить WireGuard, когда появится реальная потребность в скорости, а не из принципа.

Чего эта схема не решает

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

• Уязвимость в самом сервисе. VPN не исправит дыру в вашем веб-приложении. Он лишь не даёт добраться до него снаружи.

• Утёкший пароль от VPN. Второй фактор снижает риск, но не отменяет его полностью (фишинг, перехват кода).

• Компрометация сервера. Если злоумышленник уже внутри, наличие VPN на этом же хосте ничего не добавит. Отсюда сегментация и бэкапы.

• Отказ канала и железа. Домашний интернет упал — доступа нет. Для компании это уже вопрос резервирования.

• Ошибки конфигурации. «Временный» проброс порта, забытое правило файрвола, сервис, который сам поднялся на 0.0.0.0. Защита — это процесс и регулярный аудит, а не одна галочка.

Что меняется, когда это нужно компании

Хорошая новость: база остаётся той же — Pritunl не переписывают под масштаб, он изначально сделан под него. Меняется обвязка и требования.

И отдельно — правовая часть: VPN для доступа к собственным ресурсам организации законен. А если вы начнёте предоставлять доступ третьим лицам как услугу связи, включаются требования к операторам связи и лицензированию. Это тот случай, когда дешевле один раз спросить юриста, чем потом объясняться.

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

Сколько это стоит

На 25 человек, для сравнения:

У своего контура главная цена — не деньги, а время: вечер внимательной настройки и потом периодическое обслуживание. Если это время дороже денег — покупать готовое рационально, это не «слабость».

Если нужен готовый контур, а не вечер с YAML

Всё, что описано выше, я собрал и проверил на практике в продукте VPN-in-a-Box — это тот же подход A/B, доведённый до состояния «скопировал .env, запустил, работает»:

• актуальные nginx-proxy и acme-companion вместо устаревших образов, версии зафиксированы;

• одноуровневое проксирование без лишнего звена;

• MongoDB с аутентификацией и в изолированной сети, данные — в docker volume (это та самая грабля №4 из списка выше);

• контейнер VPN без privileged: только NET_ADMIN и /dev/net/tun;

• healthcheck, чтобы «контейнер запущен» не означало «сервис работает»;

• скрипт бэкапа с автоочисткой и описанием восстановления;

• README на 15 разделов: от первого запуска до разбора ошибок вида «панель отдаёт 503»;

• лицензионный комплект — чтобы использовать в компании без вопросов.

Это тот же стек, который при необходимости растёт до корпоративного: организации, SSO, аудит, несколько площадок. Карточка продукта — в каталоге.

И честно про альтернативу: если ваша ситуация — один домашний сервер и пара сервисов, а возиться не хочется, mesh-VPN из варианта C закроет задачу за десять минут. Это нормальное решение, и оно не требует ничего покупать.

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