Свой VPN для компании на VPS: Remnawave, VLESS и HAPP

Собственный VPN для компании — это обычный виртуальный сервер за рубежом, панель управления пользователями и приложения на рабочих телефонах и компьютерах. Такой вариант даёт бизнесу понятную стоимость, отдельные доступы для сотрудников и возможность позже добавить серверы в других странах, не меняя ссылки подписок.

В этом руководстве соберём практичную схему на Ubuntu 24.04 LTS, Docker, Remnawave и VLESS. Для подключения подойдут HAPP и другие совместимые клиенты на базе Xray. Команды и названия пунктов актуальны на момент публикации, однако перед установкой всегда сверяйтесь с официальной документацией Remnawave: проект развивается быстро.

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

Как устроена схема

Архитектура корпоративного VPN: панель, подписка, узлы и устройства
Одна управляющая панель выдаёт персональные подписки, а один или несколько узлов принимают подключения устройств.

Минимальная рабочая архитектура состоит из пяти частей:

  • VPS с публичным IPv4 и Ubuntu 24.04 LTS;
  • домен и несколько A-записей для панели, подписки и узла;
  • Remnawave Panel для управления пользователями, подписками и статистикой;
  • Remnawave Node с Xray, через который идёт пользовательский трафик;
  • клиентское приложение, например HAPP, куда добавляется ссылка подписки.

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

Какой VPS выбрать

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

Сценарий CPU RAM Диск Рекомендация по сети
1–2 пользователя, несколько устройств 1 vCPU 1–2 ГБ 20 ГБ от 100 Мбит/с
Небольшая компания, 5–15 сотрудников 2 vCPU 2–4 ГБ 30–60 ГБ от 300 Мбит/с, лучше 1 Гбит/с
Компания от 20 сотрудников или дополнительные сервисы 4 vCPU 4–8 ГБ 60+ ГБ 1 Гбит/с и большой пакет трафика

Для небольшой компании разумная стартовая конфигурация — 2 vCPU, 4 ГБ RAM и 40–60 ГБ NVMe. Этого хватит с запасом для панели, базы данных, первого узла и мониторинга. Выбирайте виртуализацию KVM, публичный IPv4, доступ root, возможность переустановить ОС и сделать снимок диска.

Перед оплатой проверьте:

  • страну и репутацию IP-адресов провайдера;
  • скорость порта и месячный лимит трафика;
  • разрешены ли VPN/proxy-сервисы правилами площадки;
  • есть ли резервные копии или snapshots;
  • насколько удобна оплата и быстра ли поддержка;
  • как сервер доступен из офисных сетей и сетей удалённых сотрудников.

Домен и поддомены

Лучше не привязывать пользователей к IP-адресу. Домен позволит получать TLS-сертификаты и заменять сервер без ручной перенастройки всех устройств. Для домена example.com удобно создать такую структуру:

Поддомен Назначение DNS-запись
control.example.com закрытая административная панель A → IP первого VPS
connect.example.com публичные ссылки подписок A → IP первого VPS
nl1.edge.example.com первый VPN-узел A → IP VPS в Нидерландах
de1.edge.example.com будущий второй узел A → IP VPS в Германии

После сохранения записей дождитесь обновления DNS. Проверить результат можно командами nslookup control.example.com на Windows или dig +short control.example.com на Linux/macOS.

Подготовка Ubuntu

Сначала войдите на сервер по SSH. В примерах используется тестовый адрес из специального диапазона документации — замените его на свой:

ssh root@203.0.113.10

Обновите систему, настройте часовой пояс и установите базовые инструменты:

apt update && apt full-upgrade -y
timedatectl set-timezone UTC
apt install -y ca-certificates curl git ufw fail2ban

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

Откройте только необходимые порты:

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status

Порты базы данных, Redis, API панели и метрик нельзя публиковать в интернет. Remnawave отдельно рекомендует привязывать внутренние сервисы только к 127.0.0.1 и отдавать наружу веб-интерфейс через reverse proxy.

Установка Docker

Устанавливайте Docker Engine из официального репозитория. На странице Docker Engine для Ubuntu приведены актуальные команды добавления репозитория и пакетов. После установки проверьте:

docker --version
docker compose version
systemctl status docker --no-pager

Ручная установка отдельного бинарника Compose хуже: такой вариант не получает обычные обновления пакетного менеджера. Официальная документация Docker рекомендует Compose plugin из репозитория.

Установка Remnawave Panel

Remnawave управляет пользователями, нодами, конфигурациями, подписками и статистикой. Общий порядок установки выглядит так:

  1. создать каталог /opt/remnawave;
  2. получить актуальные docker-compose.yml и шаблон .env из официального репозитория;
  3. сгенерировать уникальные JWT-секреты, пароль PostgreSQL, пароль метрик и секрет webhook;
  4. указать домены панели и подписки;
  5. запустить контейнеры через docker compose up -d;
  6. поставить reverse proxy и получить TLS-сертификаты.

Актуальные файлы, переменные и команды находятся в официальной инструкции Remnawave Panel. Не копируйте случайные compose-файлы из форумов: переменные и состав контейнеров меняются от версии к версии.

Секреты удобно генерировать локально на сервере:

openssl rand -hex 64
openssl rand -base64 48
openssl rand -hex 24

Каждую команду выполняют отдельно для соответствующей переменной. Содержимое .env, приватные ключи Node и ссылки подписок нельзя отправлять в чаты, публиковать в Git или вставлять в скриншоты.

Reverse proxy и TLS

Панели необходим reverse proxy. Подойдут Caddy или Nginx; оба варианта описаны в документации Remnawave. Caddy удобен для небольшой корпоративной инфраструктуры: он автоматически запрашивает и обновляет сертификаты Let’s Encrypt.

Перед запуском proxy убедитесь, что:

  • оба поддомена уже указывают на VPS;
  • порты 80 и 443 доступны извне;
  • внутренние сервисы Remnawave слушают localhost;
  • панель и подписка разведены по назначенным доменам или маршрутам;
  • страница панели открывается только по HTTPS.

После первого входа зарегистрируйте администратора. Первый созданный аккаунт получает права super-admin. Включите passkey или другой второй фактор, если он доступен в вашей версии панели.

Узел, профиль конфигурации и Host

В Remnawave одного создания Node недостаточно. Рабочая цепочка состоит из связанных объектов:

  1. Config Profile описывает входящее подключение Xray;
  2. Internal Squad определяет доступную пользователям конфигурацию;
  3. Node запускает профиль на конкретном сервере;
  4. Host формирует адрес, который попадёт в подписку;
  5. User получает доступ к нужному Internal Squad.

При создании Node панель выдаст команду или compose-конфигурацию с токеном подключения. Выполняйте её только на нужном сервере. Связь панели с нодами защищается mTLS, а состояние узла должно стать Connected.

Для новых конфигураций выбирайте современный транспорт, поддерживаемый вашими клиентами. В актуальном Xray транспорт WebSocket и поле host внутри headers помечены как устаревающие; сам Xray рекомендует переходить на XHTTP с HTTP/2 или HTTP/3. Если ради совместимости временно используется WebSocket, запланируйте миграцию и обязательно протестируйте HAPP на корпоративных Windows-, Android- и iOS-устройствах до выдачи подписок сотрудникам.

Отдельный пользователь для каждого сотрудника

Учётные записи сотрудников и контроль трафика корпоративного VPN
Персональная подписка позволяет видеть расход трафика, отключать доступ и задавать лимиты независимо для каждого сотрудника.

Оптимальная модель — одна учётная запись на сотрудника, а не одна общая ссылка на отдел или всю компанию. Например: «Иван — разработка», «Мария — продажи», «Анна — бухгалтерия». Рабочий телефон и ноутбук одного сотрудника могут использовать одну персональную ссылку.

Так вы сможете:

  • видеть расход трафика каждого пользователя;
  • задавать отдельные лимиты и срок действия;
  • отключить потерянную или скомпрометированную ссылку;
  • не менять настройки остальных сотрудников;
  • быстро отзывать доступ при увольнении или смене роли;
  • при необходимости ограничить число устройств через HWID.

Функция HWID необязательна и работает только с приложениями, которые передают соответствующий заголовок. Если включить обязательный HWID для несовместимого клиента, сервер вернёт ошибку вместо подписки. Поэтому сначала изучите ограничения HWID и протестируйте устройства.

Ссылка подписки фактически является ключом доступа. Передавайте её сотруднику через защищённый корпоративный канал, не публикуйте в общих чатах и не вставляйте в изображения. Если ссылка утекла, создайте пользователю новый subscription UUID или пересоздайте доступ.

Подключение в HAPP

HAPP доступен для Windows, macOS, Linux, Android и iOS. Приложение работает на базе Xray и поддерживает VLESS, Trojan, VMess, Shadowsocks и правила маршрутизации. Сам HAPP не продаёт VPN: сервер и конфигурацию пользователь предоставляет самостоятельно. Актуальные версии и ссылки на магазины опубликованы в официальном репозитории HAPP.

  1. Откройте созданного пользователя в Remnawave и скопируйте его subscription URL.
  2. В HAPP добавьте подписку из буфера обмена или отсканируйте QR-код.
  3. Обновите профиль и выберите нужный Host.
  4. На компьютере сначала проверьте режим Proxy, затем при необходимости включите TUN.
  5. Откройте сайт проверки IP и убедитесь, что отображается страна VPS.

Режим Proxy перенаправляет трафик приложений, которые используют системный прокси. TUN создаёт виртуальный сетевой интерфейс и охватывает больше программ, но может конфликтовать с другим VPN, корпоративным антивирусом, Hyper-V или сетевыми фильтрами. Не запускайте одновременно два TUN-VPN.

Почему HAPP иногда показывает «Ошибка запуска ядра»

Окно HAPP выводит журнал Xray целиком, поэтому предупреждение иногда выглядит как фатальная ошибка. Сообщения вроде WebSocket transport is deprecated и host in headers is deprecated означают, что конфигурация пока распознана, но использует устаревающие параметры. Они не всегда являются непосредственной причиной остановки.

Для диагностики:

  1. прокрутите или скопируйте лог до последней строки и найдите failed, fatal, bind или permission denied;
  2. полностью закройте второй VPN и старый процесс Xray;
  3. перезапустите HAPP от имени администратора, если используется TUN;
  4. обновите подписку и ядро приложения;
  5. проверьте сначала Proxy, затем TUN;
  6. если ошибка повторяется, временно отключите только проблемный Host и сравните конфигурации.

На сервере одновременно смотрите статус контейнеров и последние журналы:

cd /opt/remnawave
docker compose ps
docker compose logs --tail=200
journalctl -u caddy --since "15 minutes ago" --no-pager

Если подключение есть, а интернета нет

Проверяйте цепочку сверху вниз, меняя за раз только один параметр:

  • DNS поддомена возвращает правильный IP;
  • порт 443 доступен извне;
  • TLS-сертификат действителен и соответствует домену;
  • Node имеет статус Connected;
  • профиль назначен Node и содержит нужный inbound;
  • Internal Squad включает этот inbound;
  • User добавлен в Squad;
  • Host связан с тем же inbound и правильным доменом;
  • подписка обновлена в приложении после изменений;
  • на устройстве не работает параллельно другой VPN или Private DNS с конфликтующей политикой.

Если ошибка наблюдается только в конкретной офисной или домашней Wi‑Fi-сети сотрудника, сравните подключение через мобильный интернет. Если проблема только у одного оператора, проверьте другой современный транспорт и настройки TLS, не меняя сразу всю схему.

Как добавить второй VPS и оставить одну ссылку

Именно для этого панель отделена от узлов. Допустим, первый сервер находится в Нидерландах, а второй вы купили в Германии:

  1. создайте A-запись de1.edge.example.com на IP второго VPS;
  2. подготовьте Ubuntu, Docker и firewall;
  3. в панели создайте второй Node и установите выданную конфигурацию на новый VPS;
  4. назначьте ему подходящий Config Profile;
  5. создайте новый Host «Germany» и свяжите с нужным inbound;
  6. добавьте Host в ту же выдачу подписки;
  7. обновите существующую подписку в HAPP.

Пользователь продолжит использовать одну ссылку connect.example.com/..., но увидит два варианта: Netherlands и Germany. Если управляющий VPS недоступен, уже полученные клиентом конфигурации могут продолжить работать некоторое время, однако обновление подписки и управление пользователями будут недоступны. Для серьёзной отказоустойчивости панель, базу и резервные копии проектируют отдельно.

Обновления, резервные копии и контроль трафика

Раз в неделю проверяйте обновления ОС и контейнеров, но не обновляйте критическую инфраструктуру прямо перед поездкой. Сначала сохраните:

  • каталог проекта Remnawave и файл .env в зашифрованном хранилище;
  • резервную копию PostgreSQL;
  • конфигурацию reverse proxy;
  • список DNS-записей;
  • снимок VPS перед крупным обновлением.

В Remnawave доступны статистика пользователей, трафик по нодам, online-соединения и лимиты. Не стоит включать подробное журналирование пользовательского трафика «на всякий случай»: собирайте только те технические данные, которые действительно нужны для эксплуатации.

Короткий чек-лист готовности

  • VPS имеет KVM, публичный IPv4 и достаточный пакет трафика;
  • Ubuntu обновлена, SSH работает по ключам;
  • наружу открыты только необходимые порты;
  • панель, подписка и edge-узел используют отдельные поддомены;
  • все публичные точки работают по TLS;
  • Node подключён, а Profile, Squad, Host и User связаны между собой;
  • каждому сотруднику выдана персональная ссылка;
  • описан порядок выдачи и отзыва доступа при приёме и увольнении;
  • проверены Proxy и TUN на разных устройствах и сетях;
  • создана резервная копия и записан порядок восстановления;
  • есть план миграции с устаревающего WebSocket на XHTTP.

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