Перенос сервера в дата-центр решает вопросы с электропитанием, охлаждением и физическим размещением оборудования. Но после переезда появляется новая задача: как безопасно связать удалённый сервер с офисной сетью и сохранить привычный доступ к корпоративным системам.
Публиковать внутренние сервисы напрямую в интернете рискованно. Открытые административные интерфейсы, RDP, SSH и другие служебные порты регулярно проверяют автоматические сканеры. Кроме того, многие корпоративные приложения рассчитаны на работу внутри локальной сети.
В этом проекте клиент арендовал физический сервер в дата-центре Москвы. Основная инфраструктура оставалась в офисе в Санкт-Петербурге и была построена на оборудовании MikroTik.
Нам требовалось объединить две площадки в управляемый корпоративный контур, обеспечить доступ к серверным ресурсам и сохранить возможность развивать инфраструктуру в дальнейшем.
Задача
В рамках проекта необходимо было:
- развернуть на сервере среду виртуализации VMware ESXi;
- организовать сетевой шлюз на стороне дата-центра;
- связать дата-центр с существующей сетью офиса;
- закрыть внутренние сервисы от прямого доступа из интернета;
- предусмотреть подключение удалённых сотрудников;
- организовать резервное копирование на отдельный VDS-сервер;
- подготовить инфраструктуру к размещению новых виртуальных машин.
VMware ESXi и pfSense были пожеланиями заказчика, поэтому архитектуру проектировали на основе этих решений.
Как построили инфраструктуру в дата-центре
На физическом сервере установили VMware ESXi. Гипервизор позволил разместить на одном оборудовании несколько отдельных виртуальных машин и создать для них внутреннюю серверную сеть.
Сетевой шлюз на pfSense развернули в отдельной виртуальной машине. Один его интерфейс был подключён к внешней сети дата-центра, второй — к внутреннему сегменту с виртуальными серверами.
Прикладным системам не потребовалось предоставлять прямой доступ из интернета. Входящий и исходящий трафик проходил через pfSense, где применялись правила маршрутизации и межсетевого экрана.
Сетевые и прикладные функции были разделены: pfSense отвечал за VPN, маршрутизацию и фильтрацию трафика, а остальные виртуальные машины — за корпоративные сервисы.
Административные интерфейсы гипервизора и сетевого шлюза не предназначались для свободного доступа из интернета. Подключение к ним ограничили разрешёнными сетями и учётными записями с соответствующими правами.
Почему использовали pfSense
В других проектах мы часто применяем MikroTik CHR — виртуальную версию RouterOS. Она подходит для маршрутизации, VPN и фильтрации трафика и также могла рассматриваться для этой задачи.
Однако в данном проекте использование pfSense, как и VMware ESXi, было пожеланием заказчика. Мы развернули его в роли виртуального шлюза на стороне дата-центра и интегрировали с уже работающим MikroTik в офисе.
Использование разных платформ не создало ограничений: связь между площадками строилась на стандартном site-to-site VPN. Поэтому заменять существующий офисный маршрутизатор не потребовалось.
Выбор pfSense в этом случае определялся согласованной с заказчиком архитектурой, а не недостатками MikroTik CHR.
Как связали офис и дата-центр
Между офисным MikroTik и pfSense в дата-центре настроили постоянный site-to-site VPN. Он объединил локальную сеть Санкт-Петербурга и серверный сегмент в Москве через защищённый канал.
Туннель устанавливается непосредственно между сетевыми шлюзами. Сотрудникам в офисе не нужно запускать отдельный VPN-клиент: разрешённые серверные ресурсы доступны по внутренним IP-адресам.
Для работы соединения использовали непересекающиеся диапазоны адресов и настроили маршрутизацию между площадками.
При этом мы не открывали полный доступ между всеми устройствами. Правила межсетевого экрана разрешали только необходимые соединения. Например, пользователи могли обращаться к корпоративному приложению, но не получали доступ к интерфейсам управления VMware ESXi и pfSense.
Таким образом, VPN выполнял не только функцию шифрования трафика, но и стал частью общей системы разграничения доступа.
Доступ удалённых сотрудников
Архитектура также предусматривала отдельное VPN-подключение для сотрудников, работающих вне офиса.
После авторизации пользователь получал доступ только к необходимым корпоративным ресурсам. Внутренние сервисы при этом не требовалось публиковать напрямую в интернете.
Для разных категорий пользователей можно применять отдельные правила. Сотруднику предоставляется доступ к рабочему приложению или серверу, а административные интерфейсы остаются доступны только ИТ-специалистам.
Использование индивидуальных учётных записей упрощает управление доступом: права конкретного пользователя можно изменить или отозвать, не затрагивая остальных сотрудников.
Резервное копирование на VDS
Размещение сервера в дата-центре не защищает данные от случайного удаления, программных сбоев или повреждения основного хранилища. Поэтому резервные копии размещались на отдельном VDS-сервере.
Это позволило отделить резервные данные от рабочих виртуальных машин и снизить риск их одновременной потери при проблемах с основным сервером.
При этом само наличие резервной копии ещё не гарантирует восстановление. Необходимо контролировать успешность заданий, свободное место и сроки хранения, а также периодически проверять восстановление данных.
Возможности для развития
VMware ESXi позволил подготовить площадку не только под текущие задачи.
По мере развития инфраструктуры на сервере можно создавать дополнительные виртуальные машины: файловые серверы, контроллеры домена, серверы приложений, системы мониторинга и другие корпоративные сервисы.
Для новых систем можно выделять отдельные сетевые сегменты и задавать собственные правила доступа. Это позволяет расширять инфраструктуру постепенно, без полной перестройки площадки при появлении каждой новой задачи.
Ограничением остаются ресурсы физического сервера: процессор, оперативная память, дисковая подсистема и пропускная способность канала. Поэтому развитие виртуальной среды должно сопровождаться контролем их загрузки.
Результат
В рамках проекта мы:
- развернули VMware ESXi на сервере в московском дата-центре;
- настроили виртуальный сетевой шлюз на pfSense;
- связали офисный MikroTik и серверную сеть через site-to-site VPN;
- закрыли внутренние сервисы от прямого доступа из интернета;
- предусмотрели отдельное подключение для удалённых сотрудников;
- организовали хранение резервных копий на VDS;
- подготовили инфраструктуру к добавлению новых виртуальных машин.
Для сотрудников сервер стал частью корпоративной сети, несмотря на то что физически находился в другом городе. В офисе доступ к нему осуществлялся по внутренним адресам через постоянный VPN-туннель, а права между сегментами ограничивались правилами межсетевого экрана.
Существующее оборудование MikroTik осталось в работе, а сетевые и серверные функции были разделены между отдельными виртуальными машинами.
Что важно учесть перед переносом сервера
До переноса необходимо проверить, как корпоративные приложения работают через удалённый канал. Некоторые системы чувствительны к задержкам, потерям пакетов и нестабильному соединению, поэтому критичные сценарии лучше протестировать заранее.
Также важно использовать непересекающиеся подсети в офисе и дата-центре. Это значительно упрощает маршрутизацию и настройку VPN.
Отдельно следует продумать отказ интернет-канала в офисе. Сервер в дата-центре продолжит работать, но сотрудники не смогут к нему подключиться. Для критичных систем можно предусмотреть резервного провайдера и автоматическое переключение канала.
Нужно учитывать и то, что один физический сервер, один сетевой шлюз и один основной канал связи остаются точками отказа. Полная отказоустойчивость требует дополнительных серверов, каналов и механизмов репликации.
Однако даже без полного резервирования правильно построенная связь между офисом и дата-центром повышает безопасность и управляемость инфраструктуры. Удалённый сервер становится не отдельным устройством на внешней площадке, а частью единого корпоративного контура.
