Защищённый удалённый доступ для сотрудников нужен компании, когда команда работает из офиса, дома и в поездках, а внутренние сервисы нельзя публиковать в открытом интернете. Собственный шлюз на VPS позволяет централизованно выдавать персональные доступы, ограничивать маршруты и быстро отзывать права при увольнении или потере устройства.
В статье разберём архитектуру такого контура на Ubuntu и Docker. Это не инструкция по обходу сетевых ограничений: задача решения — предоставить авторизованным сотрудникам доступ только к разрешённым корпоративным ресурсам.
Правовая и организационная граница: инфраструктура должна использоваться в соответствии с законодательством РФ, политиками информационной безопасности компании и правилами хостинг-провайдера. Не настраивайте её для доступа к ресурсам, доступ к которым ограничен на территории России. Публичное распространение рабочих конфигураций, ключей и ссылок доступа недопустимо.
Как устроен корпоративный контур доступа
- VPS или сервер компании с публичным IPv4 и поддерживаемой ОС;
- управляющая панель для учётных записей, сроков действия, лимитов и аудита;
- основной и резервный шлюзы;
- корпоративный домен и TLS;
- утверждённое клиентское приложение на управляемых устройствах;
- политики маршрутизации, разрешающие только необходимые корпоративные сети.
Для небольшой команды панель и первый шлюз можно разместить на одном VPS. По мере роста резервный шлюз выносится на отдельный сервер. Пользователь продолжает работать с одним персональным профилем, а переключение между узлами остаётся задачей администратора.
Сначала определите модель угроз
До покупки сервера составьте список ресурсов, к которым нужен удалённый доступ: CRM, Git, внутренние панели, файловое хранилище, мониторинг и тестовые стенды. Для каждого ресурса укажите владельца, группы сотрудников, допустимые устройства и требования к журналированию.
Базовый принцип — запрещено всё, что не разрешено явно. Корпоративный шлюз не должен автоматически перенаправлять через себя весь пользовательский интернет-трафик. Предпочтительна ограниченная маршрутизация только к внутренним IP-диапазонам, доменам и портам компании.
Какой VPS выбрать
Для сервиса важнее стабильность сети, резервное копирование и предсказуемая производительность, чем большой диск.
| Сценарий | CPU | RAM | Диск | Сеть |
|---|---|---|---|---|
| До 5 сотрудников | 1–2 vCPU | 2 ГБ | 20–30 ГБ | от 100 Мбит/с |
| 5–20 сотрудников | 2 vCPU | 4 ГБ | 40–60 ГБ | от 300 Мбит/с |
| Более 20 сотрудников | 4 vCPU | 4–8 ГБ | 60+ ГБ | 1 Гбит/с |
Практичная стартовая конфигурация — 2 vCPU, 4 ГБ RAM и 40–60 ГБ NVMe. Выбирайте KVM, публичный IPv4, снимки диска, резервное копирование и понятную процедуру восстановления. Убедитесь, что сценарий не противоречит правилам провайдера.
Доменная схема без привязки к серверу
Домен упрощает замену сервера и обновление сертификатов.
| Поддомен | Назначение |
|---|---|
control.example.com | закрытая административная панель |
connect.example.com | персональные профили сотрудников |
edge1.access.example.com | основной корпоративный шлюз |
edge2.access.example.com | резервный шлюз |
Административный поддомен дополнительно закройте списком разрешённых адресов, отдельной аутентификацией или доступом только из служебной сети.
Базовая защита Ubuntu
apt update && apt full-upgrade -y
apt install -y ca-certificates curl ufw fail2ban
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw statusСоздайте отдельного администратора, настройте SSH-ключ и только после проверки отключите парольный доступ root. Базы данных, Redis, API панели и метрики не должны слушать публичный адрес. Для контейнеров используйте официальную инструкцию Docker Engine для Ubuntu.
Панель управления и шлюзы
В нашей рабочей схеме Remnawave используется как внутренняя административная панель. Она помогает вести персональные учётные записи, видеть состояние узлов, назначать лимиты и отзывать доступ. При выборе продукта проверяйте лицензию, модель обновлений и требования законодательства.
Панель размещается за reverse proxy и TLS. Внешне открываются только необходимые точки входа, а внутренние компоненты связываются через localhost или закрытую сеть. Секреты, приватные ключи и резервные коды хранятся в защищённом хранилище и никогда не публикуются.
- создайте профиль с разрешёнными корпоративными маршрутами;
- назначьте его основному шлюзу;
- включите в группу только нужные ресурсы;
- добавьте сотрудника в соответствующую группу;
- выдайте персональный профиль со сроком действия;
- проверьте доступ с управляемого рабочего устройства.
Отдельная учётная запись для каждого сотрудника
Не используйте одну общую ссылку на отдел или всю компанию. Персональные записи позволяют предоставлять права по должности, отключать потерянные устройства, отзывать доступ при увольнении и вести минимально необходимый технический аудит.
Живой результат: панель с сотрудниками
Ниже — реальный рабочий экран после настройки. Администратор видит активные записи, последнее подключение, используемый узел, статус и объём служебного трафика. Имена сотрудников на публичном изображении скрыты.
Выдача доступа на рабочее устройство
Клиентское приложение и его версия утверждаются компанией заранее. Персональный профиль передаётся через защищённый канал. Пользователь не должен пересылать его коллегам, хранить в открытых заметках или добавлять на личные неуправляемые устройства.
После подключения проверяют не внешний IP, а доступность конкретных разрешённых корпоративных систем. Обычные сайты и личные приложения должны использовать стандартное соединение устройства. Для чувствительных систем сохраняйте отдельную аутентификацию, MFA и ролевые права.
Основной и резервный шлюзы
Второй VPS нужен для отказоустойчивости, а не для смены географии пользователя. Он настраивается как резервный узел с теми же корпоративными политиками и минимальным набором разрешённых маршрутов. Персональный профиль может содержать основной и резервный адреса, поэтому при аварии не требуется повторно настраивать команду.
Мониторинг и персональные данные
Собирайте только сведения, необходимые для безопасности и эксплуатации: состояние узлов, время последнего подключения, объём служебного трафика и события выдачи или отзыва доступа. Не включайте подробное журналирование пользовательской активности «на всякий случай».
Сотрудники должны быть ознакомлены с правилами, перечнем собираемых технических данных и сроками их хранения. Доступ к статистике предоставляется только ответственным администраторам.
Обновления и резервные копии
- устанавливайте обновления после проверки;
- храните конфигурацию и секреты отдельно от публичного репозитория;
- делайте резервные копии базы панели и reverse proxy;
- создавайте снимок VPS перед крупным обновлением;
- проверяйте восстановление на отдельном узле;
- фиксируйте ответственных и порядок действий при инциденте.
Чек-лист готовности
- описаны корпоративные ресурсы и группы доступа;
- маршрутизация ограничена разрешёнными сетями;
- обычный интернет-трафик не направляется через шлюз;
- Ubuntu обновлена, SSH работает по ключам;
- наружу открыты только необходимые порты;
- панель защищена TLS и дополнительным ограничением;
- каждому сотруднику выдана персональная запись;
- описан порядок выдачи и отзыва прав;
- включена MFA для внутренних систем;
- проверены резервные копии;
- сценарий проверен на соответствие законодательству и правилам провайдера.
Итог
Собственный контур защищённого доступа даёт компании контроль над учётными записями, резервированием и эксплуатацией. Его ценность не в перенаправлении всего интернет-трафика, а в безопасном подключении сотрудников к конкретным рабочим системам. Чем уже разрешённые маршруты и лучше организован жизненный цикл доступов, тем меньше поверхность атаки и проще аудит.