🧠 День 13 — Доступ к Windows Server 2022 через WireGuard и WinRM (без открытия портов в интернет)
✎
29–30 апреля 2026 я собрал первый практический сценарий удалённого сбора данных с Windows Server 2022 (прод-сервер) без публикации админ-портов наружу.
Идея простая:
- строим защищённый туннель;
- добиваемся корректной авторизации;
- получаем техданные (health-check) через WinRM;
- фиксируем результат и делаем повторяемый скрипт.
Важно: в этой статье я специально обезличил хосты, домен, пользователей и точные адреса. Логика и грабли реальные.
🎯 Контекст задачи
- Цель: безопасно собирать техданные с Windows Server 2022:
- версия ОС, аптайм
- CPU/RAM
- диски
- состояние критичных сервисов (например, бизнес-приложение и SQL)
- Ограничения:
- сервер продовый, люди работают по RDP
- нельзя “распахнуть” WinRM/RDP в интернет
- по обе стороны туннеля исторически одинаковые подсети (классическая боль)
🗺️ Схема (упрощённо)
(площадка A) (площадка B)
+---------------------+ +----------------------+
| VPN/Edge (Linux) |<===== WG ========>| Router/Gateway |
| vpn01 | tunnel /30-ish | (MikroTik/edge) |
+----------+----------+ +----------+-----------+
| |
| |
(LAN A) | | (LAN B)
192.168.xx.0/24 192.168.xx.0/24
| |
| |
+----------v----------+ +----------v-----------+
| Windows Server | | другие хосты/узлы |
| (prod) | | (не важно) |
+---------------------+ +----------------------+
Проблема: LAN A и LAN B пересекаются по адресам.
Решение: отдельная "виртуальная" сеть в туннеле + NAT/NETMAP.
### Схема overlay + NAT/NETMAP
Идея простая: внутри WireGuard мы вводим отдельную “виртуальную” подсеть и маппим на неё реальный сервер.
Так мы избегаем конфликта одинаковых LAN по обе стороны.
```text
Клиент/сборщик (площадка A)
(Linux / automation)
|
| WinRM (HTTP/HTTPS) -> overlay
v
+------+------+
| vpn01 (WG) |
| overlay: |
| 10.xx.xx.1 |
+------+------+
|
| WireGuard tunnel
v
+------+------+
| edge router |
| NAT/NETMAP: |
| 10.xx.xx.145 |
| <-> LAN IP |
+------+------+
|
| (внутри площадки B)
v
+------+------+
| Windows srv |
| (prod host) |
+-------------+
Снаружи ничего не открываем: WinRM доступен только “через overlay-адрес”.
✅ Что было сделано (по шагам)
Поток доступа (WinRM)
Чтобы было понятно “что куда ходит”, вот упрощённый поток:
Operator/Script
|
| (1) connect to overlay host: 10.xx.xx.145
v
vpn01 (WG overlay)
|
| (2) encrypted tunnel
v
edge router (NETMAP)
|
| (3) translate dst 10.xx.xx.145 -> real LAN IP
v
Windows Server
|
| (4) WinRM auth (NTLM) + policies/groups/UAC
v
Remote command exec -> JSON/text report
- Проверил базовую доступность узла и сервисов в пределах допустимых правил.
- Поднял site-to-site WireGuard между узлом на Linux и edge-роутером.
- Уперся в конфликт одинаковых подсетей и сделал отдельную виртуальную сеть туннеля:
WG overlay: 10.xx.xx.0/24
Windows host (через маппинг): 10.xx.xx.145
- Настроил NAT/NETMAP так, чтобы удалённый Windows хост имел “виртуальный адрес” в overlay-сети.
- Проверил, что сервер доступен через туннель по нужным направлениям.
- Подтвердил права учётки для WinRM.
- Донастроил права в локальных группах Windows (привязываясь к SID/группам, чтобы не зависеть от языка ОС).
- Включил корректный удалённый доступ через WinRM (NTLM) и поправил нюансы UAC/token filtering.
- Снял расширенный health-check и оформил отчёт.
- Добавил скрипт повторного сбора и зафиксировал всё в git.
🧨 Ключевые проблемы и как решались
1) “Порт виден, но не пускает”
Пинг/порт могут быть “живы”, но это не значит, что дальше авторизация будет работать.
В Windows часто упираешься в:
- локальные политики;
- членство пользователя в группах;
- UAC token policy (когда удалённая сессия получает урезанные права);
- настройки WinRM и разрешённые методы.
2) Совпадение подсетей по обе стороны
Когда обе стороны исторически живут в одной и той же 192.168.xx.0/24, классическая маршрутизация не поможет.
Решение, которое сработало стабильно:
- поднять overlay-сеть внутри WG (условно
10.xx.xx.0/24) - сделать NAT/NETMAP до целевого сервера
- дальше работать как будто это “обычный” хост в отдельной подсети
3) WinRM “не работает с нужной учёткой”
Чаще всего проблема не в WinRM как в сервисе, а в том, чем именно является учётка и какие права ей даны.
В итоге у меня заработало после:
- корректных локальных групп;
- включения WinRM и проверенной схемы аутентификации;
- настройки политики, влияющей на удалённые токены.
📊 Что получилось на выходе
- Туннель стабилен, доступ к Windows идёт только внутри защищённого канала.
- Сбор данных через WinRM работает.
- В репозитории лежит:
- отчёт health-check
- скрипт повторного сбора
- базовая гигиена (
.gitignore, структура)
🔢 Цифры (обезличено)
- ОС: Windows Server 2022 Datacenter (build 20348)
- Аптайм на момент проверки: около 4 недель
- RAM: около 32 GB
- Диски (примерно):
- C: ~476 GB, свободно ~284 GB
- D: ~894 GB, свободно ~763 GB
- Критичные сервисы: Running
🧠 Личный вывод
Это был мой первый полноценный рабочий сценарий получения данных с Windows Server через защищённый канал.
Главный инсайт: в таких задачах важны не “одна-две команды”, а аккуратная цепочка:
сеть -> маршруты/NAT -> доступы -> политики безопасности -> WinRM -> автоматизация -> документирование
Дальше логичный шаг: поверх уже готовой схемы сборов сделать событийные алерты (например, Telegram) и постепенно превращать это в эксплуатационный контур.