Настройка корпоративного VPN

Remote Access VPN для сотрудников

Remote Access VPN используется, когда отдельные сотрудники должны безопасно подключаться к внутренней инфраструктуре компании.

Схема может выглядеть так:

Сотрудник
    ↓
VPN-клиент
    ↓
VPN Gateway
    ↓
Firewall
    ↓
Разрешенные корпоративные ресурсы

После подключения пользователь не обязательно получает доступ ко всей корпоративной сети.

Например:

• Менеджеры - к CRM.
• Разработчики - к Git и development-среде.
• Администраторы - к серверам и monitoring.
• Подрядчики - только к согласованному сервису.
• Отдельные сотрудники - к файловому хранилищу или внутреннему порталу.

Таким образом VPN становится не общей дверью во внутреннюю сеть, а контролируемой точкой входа.

Site-to-Site VPN для офисов и сетей

Site-to-Site VPN используется, когда требуется постоянное защищенное соединение между двумя или несколькими сетями.

Например:

Офис №1
    ↓
    VPN
    ↓
Центральная инфраструктура
    ↑
    VPN
    ↑
Офис №2

Или:

Облако
   ↓
Site-to-Site VPN
   ↓
Корпоративная сеть
   ↓
Внутренние сервисы

В таком сценарии пользователям обычно не требуется вручную запускать VPN-клиент.

Маршрутизация выполняется между VPN Gateway, маршрутизаторами или firewall соответствующих сетей.

VPN для серверов и облачной инфраструктуры

Корпоративный VPN нужен не только людям.

Через закрытый сетевой контур можно соединить компоненты системы, размещенные у разных провайдеров.

Например:

Web-приложение
      ↓
Private VPN Network
      ↓
Внутренний API
      ↓
Database / Internal Services

Такой подход позволяет не публиковать внутренние сервисы напрямую в интернет только ради взаимодействия между системами.

Закрываем административные интерфейсы от публичного доступа

Один из наиболее практичных сценариев корпоративного VPN - вынести технические интерфейсы из публичного периметра.

Через VPN могут быть доступны:

• Панели управления серверами.
• Системы мониторинга.
• CI/CD.
• Git.
• Административные интерфейсы приложений.
• Внутренние базы данных.
• Служебные API.
• development и staging-среды.
• Другие технические сервисы.

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

Проектируем доступ до настройки VPN

Начинаем не с выбора WireGuard, OpenVPN или IPsec.

Сначала определяем, какую задачу должна решать сеть.

Фиксируем:

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

После этого проектируем VPN Gateway, адресацию, маршруты, firewall и модель доступа.

Разграничиваем права внутри VPN

Сам факт подключения к VPN не должен автоматически означать доступ ко всей инфраструктуре.

Между VPN-сетью и корпоративными ресурсами настраиваем необходимые правила firewall.

В зависимости от выбранной архитектуры доступ может ограничиваться по отдельным подключениям, устройствам, IP-адресам, сетям, портам и правилам firewall. Пользовательские и групповые политики применяются, если выбранное VPN-решение или система управления доступом их поддерживает.

Принцип минимальных прав

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

Например:

Отдел продаж
    ↓
CRM

Разработчики
    ↓
Git + Development

Администраторы
    ↓
Servers + Monitoring

Такая схема проще контролируется и уменьшает область доступа, которую получает отдельная учетная запись.

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

Один общий VPN-ключ на всю компанию удобен только в момент первоначальной настройки.

Для эксплуатации предпочтительнее:

Сотрудник №1 → отдельный доступ
Сотрудник №2 → отдельный доступ
Сотрудник №3 → отдельный доступ
Подрядчик    → отдельный временный доступ

Это позволяет:

• Отозвать доступ конкретного сотрудника.
• Отключить потерянное устройство.
• Завершить доступ подрядчика.
• Изменить права отдельной группы.
• Не перевыпускать доступ всей компании из-за одного пользователя.

Отзыв доступа является частью проекта

Корпоративный доступ должен иметь не только процедуру подключения, но и процедуру отключения.

Это важно при:

• Увольнении сотрудника.
• Смене должности.
• Завершении работы подрядчика.
• Потере устройства.
• Компрометации учетных данных.
• Изменении структуры сети.

Маршрутизация VPN-трафика

Не всегда имеет смысл отправлять через корпоративный VPN весь интернет-трафик пользователя.

В зависимости от задачи маршрутизируем только необходимые сети.

Например:

Корпоративные сети
        ↓
       VPN

Обычный интернет-трафик
        ↓
Локальное подключение пользователя

В других проектах, наоборот, может требоваться иная схема.

Маршрутизация определяется архитектурой инфраструктуры и требованиями заказчика, а не включается по универсальному шаблону.

Выбираем протокол под инфраструктуру

Конкретную VPN-технологию выбираем после понимания сетевой схемы, клиентских устройств и существующего оборудования.

WireGuard

Может использоваться для удаленного доступа сотрудников, соединения серверов и Site-to-Site сценариев.

Подходит для инфраструктуры, где требуется относительно компактная и понятная VPN-схема.

OpenVPN

Используется там, где важна совместимость с существующими клиентами и уже применяемой инфраструктурой.

IPsec / IKEv2

Часто используется при соединении офисных сетей, маршрутизаторов, firewall и корпоративного сетевого оборудования.

Мы не выбираем протокол только потому, что он популярнее.

Решение должно подходить под конкретные точки подключения, маршрутизацию и дальнейшую эксплуатацию.

VPN Gateway в инфраструктуре заказчика

VPN может быть развернут:

• На VPS/VDS.
• На выделенном сервере.
• На виртуальной машине.
• В существующей корпоративной инфраструктуре.
• На подходящем сетевом оборудовании.

Компания сохраняет контроль над собственной сетевой схемой, учетными данными, маршрутами и правилами доступа.

Если для VPN требуется сначала подготовить отдельный VPS/VDS и полноценное серверное окружение, это может пересекаться с услугой настройки VPS/VDS сервера и хостинга.

Настраиваем firewall вместе с VPN

VPN-туннель сам по себе не определяет, к каким системам пользователь имеет право обращаться.

Поэтому вместе с маршрутизацией проектируем правила сетевого доступа.

Проверяем:

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

Защищаем сам VPN Gateway

VPN Gateway является частью внешнего периметра компании, поэтому его также необходимо нормально эксплуатировать.

В зависимости от инфраструктуры предусматриваем:

• Ограничение административного доступа.
• firewall.
• Контроль пользовательских ключей и учетных данных.
• Системные обновления.
• Мониторинг доступности.
• Сохранение конфигурации.

Если сервер уже существует, не перестраиваем весь VPS в рамках VPN-задачи без необходимости.

Если требуется полноценное обновление существующей ОС и серверных компонентов, используется отдельная услуга обновления ОС сервера.

Логирование и мониторинг

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

В зависимости от требований контролируем:

• Доступность VPN Gateway.
• Состояние сетевого интерфейса.
• Ошибки подключения.
• Количество активных соединений.
• Серверные ресурсы.
• Критичные системные ошибки.

Глубина журналирования определяется задачами эксплуатации и требованиями заказчика к обработке данных.

Отказоустойчивость VPN

Если через VPN работает несколько администраторов, временный отказ одного Gateway может быть приемлем.

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

Для таких проектов можно предусмотреть резервный Gateway и сценарий восстановления.

Основной VPN Gateway
        ↓ отказ
Резервный VPN Gateway

Необходимость резервирования определяем по допустимому времени недоступности, а не добавляем второй сервер формально.

Какие устройства можно подключить

Конкретная поддержка зависит от выбранного протокола, но корпоративный VPN может использоваться для:

• Windows.
• Linux.
• macOS.
• Android.
• iOS.
• Серверов.
• Маршрутизаторов.
• firewall и сетевых шлюзов.

Как проходит настройка корпоративного VPN

1. Разбираем задачу

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

2. Фиксируем схему сети

Проверяем:

• IP-сети.
• Текущую маршрутизацию.
• firewall.
• Публичные адреса.
• Сетевое оборудование.
• Расположение корпоративных сервисов.
• Возможные пересечения адресных пространств.

3. Проектируем модель доступа

Определяем:

• Какие пользователи подключаются.
• Какие сети доступны каждой группе.
• Какие сервисы остаются закрытыми.
• Как выдаются и отзываются доступы.
• Какая маршрутизация требуется.

4. Выбираем VPN-архитектуру

Выбираем Remote Access, Site-to-Site или комбинированную схему и подходящий протокол.

5. Настраиваем VPN Gateway

Разворачиваем VPN, сетевые интерфейсы, необходимые маршруты и серверные параметры.

6. Настраиваем firewall

Разрешаем только необходимые взаимодействия между VPN-сетью и корпоративными ресурсами.

7. Создаем доступы

Формируем отдельные пользовательские или сервисные подключения.

8. Настраиваем клиенты

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

9. Тестируем

Проверяем не только факт установки туннеля, но и реальную матрицу доступа.

10. Передаем рабочую конфигурацию

Фиксируем основные параметры, порядок подключения и особенности дальнейшего управления доступами.

Как тестируем VPN

Подключение

• Клиент устанавливает VPN-соединение.
• Получает предусмотренную адресацию.
• Маршруты применяются корректно.
• Соединение восстанавливается после повторного подключения.

Разрешенные ресурсы

• CRM доступна нужной группе.
• Администратор подключается к серверам.
• Разработчик получает доступ к development-среде.
• site-to-site сети видят необходимые сервисы.

Запрещенные ресурсы

Проверяем не только то, что должно открываться, но и то, что открываться не должно.

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

Отзыв доступа

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

Когда корпоративный VPN считается настроенным

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

Для приемки проверяем:

• VPN gateway доступен.
• Необходимые пользователи и сети подключаются.
• Маршрутизация соответствует согласованной схеме.
• Разрешенные ресурсы доступны.
• Запрещенные ресурсы остаются закрытыми.
• firewall применяет необходимые ограничения.
• У пользователей отдельные доступы.
• Доступ отдельного пользователя можно отозвать.
• Административные сервисы не опубликованы шире необходимого.
• VPN можно диагностировать при проблеме.
• Основные параметры подключения зафиксированы.

Когда VPN может быть не лучшим решением

VPN не нужно устанавливать только потому, что требуется закрыть один веб-интерфейс.

В зависимости от задачи могут быть уместнее:

• reverse proxy с отдельной аутентификацией.
• identity-aware proxy.
• bastion host.
• Ограничение доступа по IP.
• Другой механизм контролируемого доступа.

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

Границы услуги

Корпоративный VPN решает задачу защищенного сетевого доступа сотрудников, офисов и информационных систем.

Он не заменяет:

• Полноценный аудит безопасности.
• Защиту рабочих устройств сотрудников.
• Управление правами внутри самих приложений.
• Резервное копирование инфраструктуры.
• Постоянное системное администрирование.
• Другие меры информационной безопасности.

Также это не публичный VPN-сервис. Мы настраиваем корпоративный сетевой доступ к инфраструктуре, которую заказчик имеет право использовать.

Что потребуется для старта

Для первичной оценки достаточно предоставить:

• Описание задачи.
• Количество сотрудников или групп.
• Список офисов или сетей, которые требуется соединить.
• Перечень внутренних ресурсов.
• Информацию о существующем сервере или VPS/VDS.
• Сведения о firewall и маршрутизаторах.
• Требования к удаленному доступу.
• Информацию о текущей сетевой схеме, если она есть.

Если готовой сетевой схемы нет, начинаем с инвентаризации доступных сетей, сервисов и пользователей.

Хорошо настроенный корпоративный VPN - это не туннель, через который "видно всю сеть". Это управляемая точка доступа, где каждому пользователю, офису или серверу доступны только необходимые ресурсы, а доступ можно контролировать, диагностировать и отозвать без перестройки всей инфраструктуры.