Как настроить VPN между офисом и облаком без дорогого оборудования

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

Когда бизнесу нужен VPN до облака?

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

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

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

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

Как спланировать сеть офиса и облака?

Сначала определите две подсети, которые не пересекаются. Например, офис может использовать диапазон 192.168.10.0/24, а облачная сеть — 10.20.0.0/24. Эти адреса приведены как пример схемы, их нужно заменить на реальные диапазоны вашей инфраструктуры. Если офис и облако используют одну и ту же подсеть, маршрутизатор не поймёт, куда отправлять пакет.

• Офисная подсеть: адреса компьютеров, принтеров и локальных сервисов.
• Облачная подсеть: VPS, базы данных и внутренние приложения.
• VPN-подсеть: отдельный диапазон для служебных адресов туннеля.
• Адрес шлюза: маршрутизатор в офисе и виртуальный маршрутизатор в облаке.

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

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

Какой тип VPN выбрать для небольшой компании?

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

Название протокола не определяет безопасность само по себе. Защиту задают актуальное программное обеспечение, закрытые ключи, правила firewall и ограниченный список доступных подсетей. Если VPN работает на Linux, обновления и резервную копию конфигурации нужно включить в обычное обслуживание сервера.

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

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

Как настроить Site-to-Site VPN по шагам?

1. Подготовьте узлы. На офисном шлюзе и облачном маршрутизаторе создайте резервные копии текущих настроек. Зафиксируйте внешние адреса, локальные подсети и список сервисов, которые должны быть доступны.
2. Установите VPN-протокол. На обоих узлах включите один и тот же вариант VPN. Для WireGuard создайте отдельную пару ключей на каждом узле. Приватный ключ не передают в чаты, заявки и общие документы.
3. Настройте адреса туннеля. Назначьте каждому узлу свой адрес из отдельной VPN-подсети. Этот диапазон не должен совпадать с офисной или облачной сетью.
4. Опишите разрешённые сети. В конфигурации укажите, какие подсети находятся за каждым узлом. Для офиса это локальный диапазон, для облака — диапазон виртуальной сети. Чем уже список, тем проще контролировать доступ.
5. Добавьте маршруты. Офисный шлюз должен отправлять трафик к облачной подсети через VPN. Облачный маршрутизатор должен знать обратный маршрут к офисной сети. Без обратного маршрута запрос уйдёт, но ответ не вернётся.
6. Настройте firewall. Разрешите сам VPN-трафик на внешнем интерфейсе, а внутри туннеля откройте только нужные порты. Если серверу нужен SSH, база данных или веб-интерфейс, не следует автоматически открывать всю облачную подсеть.
7. Проверьте DNS. Если сотрудники обращаются к сервисам по именам, настройте разрешение внутренних доменов или временно используйте записи в локальном DNS. Проверка по IP отдельно от проверки по имени помогает найти источник ошибки.
8. Проверьте отказоустойчивость. Перезапустите VPN-службу, отключите внешний канал на короткое время и убедитесь, что после восстановления туннель поднимается сам. Результат проверки запишите в инструкцию.

Технические параметры зависят от маршрутизатора и облачной платформы, поэтому готовую конфигурацию из случайного примера нельзя переносить без проверки. Особенно внимательно проверьте NAT: если офисный шлюз маскирует трафик внутри туннеля, сервер в облаке может видеть только адрес шлюза, а правила доступа по адресам офиса перестанут работать.

Как проверить VPN и найти неисправность?

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

Для диагностики сохраняйте время сбоя и направление запроса. Запись «не работает облако» мало помогает, а формулировка «из офисной подсети сервер отвечает на ping, но порт приложения закрыт» сразу сужает поиск. Журналы VPN, firewall и самого сервера нужно сравнивать за один и тот же период.

Какие ошибки чаще всего ломают туннель?

• Одинаковые подсети. Офис и облако используют один диапазон адресов, поэтому маршрутизация становится неоднозначной.
• Забытый обратный маршрут. Сервер получает запрос, но отправляет ответ через другой шлюз.
• Открытый VPN без ограничения сетей. Туннель работает, но через него разрешён лишний доступ к инфраструктуре.
• Проверка только с одного устройства. Администратор тестирует маршрутизатор, хотя ошибка находится в firewall конкретного сервера.
• Отсутствие резервной копии. После сброса оборудования настройки приходится восстанавливать по памяти.
• Нет контроля после изменений. Обновление маршрутизатора или перенос VPS меняет адреса и правила, но это не отражают в схеме.

Для малого бизнеса разумная схема часто состоит из офисного шлюза, облачного маршрутизатора и чётко ограниченных маршрутов. Дорогой специализированный комплекс для этого не обязателен, но понадобится устройство с поддержкой нужного VPN, статических маршрутов, firewall и автоматического восстановления соединения. Если собственных ИТ-ресурсов не хватает, проектирование туннеля можно включить в работы по оптимизации IT и облачной инфраструктуре.