Создание стенда для моделирования домена в локальной сети организации на базе Hyper‑V с защитой через обратный прокси

Введение

При проектировании и тестировании инфраструктуры организации часто возникает необходимость в изолированном стенде, максимально приближенном к реальной среде. Такой стенд позволяет отработать развёртывание доменных служб, настройку сетевого доступа и политики безопасности без риска нарушить работу продуктивной сети. В данной статье рассмотрим процесс создания виртуального стенда на базе Hyper‑V, включающего контроллер домена, рабочие станции и серверы приложений, а также организацию безопасного доступа к внутренним ресурсам через обратный прокси на базе open source решений.

Цели и задачи стенда

• Создание изолированной доменной среды (Active Directory).
• Размещение типовых серверных ролей (файловый сервер, веб-сервер).
• Подключение клиентских машин к домену.
• Обеспечение контролируемого доступа к сервисам стенда из внешней сети (сети организации) через обратный прокси с шифрованием и аутентификацией.
• Отработка сценариев администрирования и безопасности.

Архитектура решения

В качестве гипервизора используется Microsoft Hyper‑V (в составе Windows Server или Windows 10/11 Pro). Виртуальные машины объединены в изолированную виртуальную сеть Hyper‑V. Для взаимодействия с внешней сетью (локальной сетью организации) используется виртуальный маршрутизатор или прокси-сервер, который также выполняет функции обратного прокси и межсетевого экрана.

Основные компоненты стенда:

• Контроллер домена (Windows Server) – службы AD DS, DNS, DHCP.
• Сервер приложений (Windows Server) – например, файловый сервер или IIS.
• Клиентские машины (Windows 10/11) – для проверки групповых политик и доступа к ресурсам.
• Обратный прокси / шлюз (Linux с nginx) – обеспечивает терминацию SSL, аутентификацию и перенаправление запросов к внутренним серверам.

Шаг 1. Установка и настройка Hyper‑V

Если Hyper‑V ещё не развёрнут, необходимо включить его через «Панель управления» → «Программы и компоненты» → «Включение или отключение компонентов Windows». После установки рекомендуется создать виртуальный коммутатор для изолированной сети.

Шаг 2. Создание виртуальных машин

Создаём следующие ВМ (можно использовать автоматизированные сценарии PowerShell):

Имя ВМ	Конфигурация	ОС
DC	2 ядра, 4 ГБ ОЗУ, 60 ГБ диска	Windows Server 2022
SRV-App	2 ядра, 2 ГБ ОЗУ, 40 ГБ	Windows Server 2022
Client1, Client2	по 2 ядра, 2 ГБ ОЗУ, 40 ГБ	Windows 10/11
Proxy	1 ядро, 1 ГБ ОЗУ, 20 ГБ	Ubuntu Server 22.04 LTS

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

Шаг 3. Настройка сети Hyper‑V

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

Простейший способ – создать внутренний коммутатор и назначить прокси-серверу два сетевых адаптера: один для внешней сети (основной адаптер Hyper‑V с доступом в локальную сеть организации), другой – для внутренней сети стенда. На прокси-сервере настраивается маршрутизация и iptables для трансляции адресов (NAT) и/или проброс портов.

Альтернативный вариант – использовать только внутренний коммутатор и подключаться к ВМ через консоль Hyper‑V, а для доступа к сервисам извне использовать только обратный прокси, который будет иметь сетевой интерфейс как во внешней, так и во внутренней сети.

Шаг 4. Развёртывание контроллера домена

1. Установить ОС Windows Server на ВМ DC.
2. Назначить статический IP-адрес из диапазона внутренней сети (например, 192.168.100.10/24).
3. Установить роль AD DS и настроить новый лес (домен, например, lab.local).
4. После завершения настройки перезагрузить сервер.
5. Настроить DHCP на контроллере домена для автоматической выдачи адресов клиентам (опционально).

Шаг 5. Ввод остальных машин в домен

1. На SRV-App и клиентах настроить DNS-сервером IP-адрес контроллера домена.
2. Присоединить машины к домену lab.local.
3. Перезагрузить и войти под доменной учётной записью.

Шаг 6. Настройка обратного прокси на базе nginx

В качестве обратного прокси используем Ubuntu Server с установленным nginx. Настройка включает:

• Установку nginx: sudo apt update && sudo apt install nginx -y.
• Настройку сайтов (server blocks) для проброса запросов к внутренним серверам.
• Генерацию самоподписанных SSL-сертификатов или получение сертификатов от Let's Encrypt (если прокси доступен из интернета).
• Ограничение доступа по IP-адресам или с помощью базовой аутентификации.

Пример конфигурации для проброса запросов к веб-серверу на SRV‑App (192.168.100.20):

server {
    listen 443 ssl;
    server_name app.lab.local;

    ssl_certificate /etc/nginx/ssl/lab.local.crt;
    ssl_certificate_key /etc/nginx/ssl/lab.local.key;

    location / {
        proxy_pass http://192.168.100.20;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Для обеспечения дополнительной безопасности рекомендуется настроить базовую аутентификацию:

location / {
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://192.168.100.20;
}

Шаг 7. Обеспечение безопасности

1. На прокси-сервере настроить файрвол (ufw) для разрешения только необходимых портов (22, 80, 443) с определённых источников (например, из сети администраторов).
2. Отключить прямой доступ к внутренним серверам из внешней сети: на внутреннем коммутаторе не должно быть маршрутов наружу, кроме как через прокси.
3. Регулярно обновлять ОС и компоненты.
4. Включить логирование запросов для последующего аудита.

Шаг 8. Тестирование стенда

1. Проверить доступность контроллера домена и сервисов из внутренней сети (с клиентских машин).
2. Попробовать подключиться к веб-серверу через обратный прокси из внешней сети (например, с рабочей станции администратора) по адресу https://app.lab.local (если DNS настроен, либо через IP и с подменой Hosts).
3. Проверить работу аутентификации и SSL.
4. Убедиться, что прямой доступ к внутренним IP-адресам из внешней сети невозможен.

Заключение

Созданный стенд позволяет моделировать работу доменной инфраструктуры в изолированной среде, а использование обратного прокси даёт возможность безопасно предоставлять доступ к внутренним сервисам ограниченному кругу лиц. Данное решение легко масштабируется: можно добавить дополнительные серверы, настроить балансировку нагрузки или внедрить систему обнаружения вторжений. Автоматизация развёртывания с помощью PowerShell, Ansible или Vagrant позволит быстро пересоздавать стенд после экспериментов.

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