Короткий ответ

Если DC, SQL, файловый сервер и рабочие станции сидят в 10.0.10.0/24 в одном L2, firewall периметра не видит их трафик: east-west ходит мимо WAN 203.0.113.10. Вынесите серверы в отдельную сеть (целевой пример: 10.0.20.0/24), пользователей оставьте в 10.0.10.0/24, mgmt 10.0.99.0/24, DMZ 10.0.30.0/24. На шлюзе — L3 и filter forward между VLAN. Не объединяйте всё обратно «чтобы шары заработали». Не отключайте фильтр.

Полная схема офиса: как сегментировать. Здесь — именно серверный кусок.

Симптомы и как отличить

С ПК 10.0.10.50 без маршрута «через firewall» доступны 10.0.10.10 (DC) по 445/389/3389, iLO гипервизора, Postgres. arp -a показывает серверы в той же подсети. На MikroTik нет VLAN servers, один bridge LAN.

НаблюдениеСегментации нетСегментация есть
Один gateway, одна маска на ПК и DCданет
Между ПК и DC пакеты на switch, не на WANдаL3 через FW
Guest видит DCещё и guestнет

Периметр может быть идеальным, внутренность — плоская. Аудит «порты на 203.0.113.10 закрыты» это не ловит.

Возможные причины

  1. «Так настроили 10 лет назад, маска /24 на всех».
  2. Один коммутатор unmanaged.
  3. Боялись сломать SMB/сканеры/1С.
  4. Hypervisor management в том же LAN, что 1С.
  5. Wi‑Fi корпоративный в том же VLAN, что серверы.

Диагностика

1. Кто в одной L2

На ПК:

ipconfig /all
arp -a
Test-NetConnection 10.0.10.10 -Port 445

Если маска /24 и DC в той же сети — L2 общая.

На шлюзе:

ip -br addr
bridge vlan show   # если vlan-aware
/ip address print
/interface bridge vlan print
/interface vlan print

Один адрес 10.0.10.1/24 на bridge — типичная плоская LAN.

2. Инвентарь «кто сервер»

Список: DC, файловые, SQL, 1С, гипервизоры, backup, печати «серверные». Не тащите туда МФУ пользователей без нужды. Гипервизор и iLO — в mgmt 10.0.99.0/24, не в servers для приложений.

3. Потоки users→servers

Снимите, что реально нужно с ПК: 88, 135, 139, 389, 445, 636, 3268, RPC динамические для AD; 445 к файловому; 1433/5432 к SQL — лучше через app, не с каждого ПК. Это будущие allow, не any.

tcpdump на будущем SVI бесполезен, пока всё в L2: зеркалируйте порт коммутатора или смотрите на хосте.

4. Коммутатор

Нужен tagged VLAN. Access-порты серверов → VLAN servers, ПК → VLAN users. Trunk на шлюз. Без этого только «другая /24 на том же L2» — не сегментация (прокси ARP/ошибки).

Решение

Целевые сети (пример внедрения, WAN не трогаем):

  • users: 10.0.10.0/24
  • servers: 10.0.20.0/24 (новое)
  • DMZ: 10.0.30.0/24
  • mgmt: 10.0.99.0/24

Сценарий A. Коммутатор умеет VLAN, RouterOS 7 — L3

  1. Backup.
  2. Создайте VLAN 20, адрес 10.0.20.1/24 на шлюзе.
  3. DHCP для серверов или статику.
  4. Перенесите один некритичный сервер, проверьте маршрут и allow.
  5. Filter:
/ip firewall filter add chain=forward src-address=10.0.10.0/24 dst-address=10.0.20.0/24 \
  protocol=tcp dst-port=445,139,88,389,636 action=accept comment="users to DC/file - tighten later"
/ip firewall filter add chain=forward src-address=10.0.10.0/24 dst-address=10.0.20.0/24 \
  connection-state=new action=drop comment="users to servers default"
/ip firewall filter add chain=forward src-address=10.0.20.0/24 dst-address=10.0.10.0/24 \
  connection-state=new action=drop comment="servers do not initiate to users"

Established выше. Затем сужайте 445 только к file01, не ко всем 10.0.20.0/24.

Сценарий B. Ubuntu nftables-шлюз

SVI vlan20 10.0.20.1/24, vlan10 10.0.10.1/24. Forward:

sudo cp /etc/nftables.conf /root/nftables.conf.bak.seg
# iif vlan10 oif vlan20 tcp dport { 88,389,445,636 } accept
# iif vlan10 oif vlan20 ct state new drop
# iif vlan20 oif vlan10 ct state new drop
sudo nft -c -f /etc/nftables.conf

Не flush. Политика drop на new east-west.

Сценарий C. Перенос DC

  1. Временный второй IP DC в новой сети или смена адреса с обновлением DNS осознанно.
  2. Клиенты: DHCP option 6 на новый DNS, после репликации SRV.
  3. Не выключайте старый интерфейс, пока nltest /dsgetdc с тестового ПК в VLAN users не стабилен.
  4. Firewall не stop на DC «на время переноса» — узкие правила Windows Firewall: 445 только с 10.0.10.0/24 и 10.0.99.0/24.

Сценарий D. Пока нет VLAN на коммутаторах

Не рисуйте фальшивую /24. Закупите/включите VLAN или поставьте серверы за отдельный NIC шлюза (физический сегмент). Private VLAN на одном свитче — если модель умеет; не выдумывайте команды вендора.

Гипервизоры — в mgmt, не в servers. См. админ-интерфейсы.

Egress с 10.0.20.0/24egress filtering.

Как проверить, что проблема устранена

С ПК users:

Test-NetConnection 10.0.20.10 -Port 445
Test-NetConnection 10.0.20.2 -Port 3389

445 к файловому/DC — по матрице success. 3389 к серверу — fail (только mgmt/VPN). Ping к iLO в 10.0.99.0/24 с users — fail.

С сервера к случайному ПК tcp 445 — fail.

arp на ПК не содержит MAC серверов (другая L2).

Скан своего WAN не изменился к худшему.

Если не помогло

  • Забыли default gateway на сервере → новая сеть не маршрутизируется.
  • ACL на L3-коммутаторе дублирует и противоречит FW.
  • Клиенты ходят по старому IP DC в DNS.
  • Broad/multicast (mDNS, WINS) ждали L2 — это цена сегментации, чините DNS.
  • Backup-агент с users VLAN — перенесите или allow точечно.

Профилактика

  • Новые VM только в servers/mgmt/DMZ по роли.
  • Запрет «воткните сервер в любой порт».
  • Регулярный ARP-опрос: серверные MAC в VLAN users — регресс.
  • Документ VLAN = сеть = шлюз = владелец.
  • Тест «с бухгалтерии не открывается RDP SQL» как канарейка.

FAQ

Можно ли просто ACL внутри одной /24?

Микросегментация на хостах (Windows Firewall) полезна как слой, но не заменяет L2-разделение: broadcast, DHCP starvation, ошибка «any allow». Делайте оба, начиная с VLAN.

Нужен ли отдельный VLAN для печати?

Часто да (или servers). Не оставляйте МФУ с SMB в users без фильтра, если на них ждут сканы на DC.

Живой миграции VM между VLAN

Меняется IP — DNS/приложения. Планируйте. vMotion сеть — mgmt/storage, не users.

DHCP в каждом VLAN

Да, свой scope. Helper на шлюзе, не один плоский пул на всех.

Это остановит ransomware?

Снизит скорость east-west, не серебряная пуля. Нужны ещё права SMB, бэкапы, почта.