План сети — это не только картинка с коммутатором и интернетом. Он связывает бизнес-сервисы, физические подключения, адреса, правила доступа, резервирование и способы проверки. Если эти части не согласованы, новые VLAN могут красиво выглядеть в схеме и при этом не обеспечивать ни изоляцию, ни доступность.
Разберём небольшой офис с серверами, рабочими станциями, гостевым Wi-Fi и отдельным управлением. Адреса и количества — учебный пример; они не являются проектом вашей компании. Работу начинаем с инвентаризации и требований, затем проверяем реализацию на пилоте.
1. Сначала опишите сервисы и требования к простою
Составьте список: AD/DNS, файлы, телефония, приложения, печать, интернет, VPN, камеры, резервное копирование. Для каждого запишите владельца, пользователей, зависимости, чувствительность данных и допустимый простой. Термин «сервер» недостаточен: на одной VM может находиться несколько функций с разными требованиями.
Уточните рост на несколько лет, временные устройства, филиалы и удалённый доступ. Если телефоны питаются через PoE, количество портов ещё не определяет достаточность коммутатора: нужен бюджет питания. Если пользователи регулярно передают большие файлы, оцените одновременность и uplink, а не среднюю скорость одного рабочего места.
Результат первого шага — согласованные требования. Покупка оборудования до этого шага часто заканчивается добавлением случайных коммутаторов, скрытых узких мест и непрозрачных исключений firewall.
2. Разделите физическую схему и логическую сеть
На физической схеме обозначьте шкафы, патч-панели, линии, номера портов, модели, питание и резервные пути. На логической — VLAN, подсети, шлюзы, маршруты, зоны firewall и сервисы. Один trunk способен переносить несколько VLAN, поэтому линия на физической схеме не обязательно означает одну подсеть.
Для каждого устройства выберите единственное понятное имя и отдельный инвентарный идентификатор. Не смешивайте hostname, IP и подпись вроде «коммутатор бухгалтерии»: подразделение переедет, а диагностика станет неоднозначной.
В материалах Cisco по проектированию campus/branch представлены разные архитектуры. Малому офису не обязательно нужна сложная fabric-сеть; полезно перенять принципы управления, сегментации и проверки, выбрав масштаб, который команда сможет сопровождать.
3. Постройте адресный план с учётом VPN и роста
Для учебного офиса используем четыре независимые сети:
VLAN 10 MANAGEMENT 10.20.10.0/24 шлюз 10.20.10.1
VLAN 20 SERVERS 10.20.20.0/24 шлюз 10.20.20.1
VLAN 30 USERS 10.20.30.0/24 шлюз 10.20.30.1
VLAN 40 GUEST 10.20.40.0/24 шлюз 10.20.40.1RFC 1918 определяет частные диапазоны; они не становятся глобально уникальными только потому, что начинаются с 10. Исходный RFC полезен для понимания назначения адресов. Перед выбором проверьте пересечения с филиалами, партнёрами, облаком и домашними сетями VPN-пользователей.
Для обычной /24 адрес сети заканчивается на .0, broadcast — .255, адреса хостов находятся между ними. Шлюз — договорённость проекта, а не всегда автоматически .1. Запишите резервирование диапазонов для инфраструктуры, статических серверов и DHCP. Не назначайте один адрес одновременно статически и из динамического пула.
4. Проверьте подсети и границы DHCP
Для расчёта можно использовать Python 3 без внешних библиотек:
from ipaddress import ip_network
networks = [ip_network(f"10.20.{v}.0/24") for v in (10, 20, 30, 40)]
for network in networks:
print(network, network.network_address, network.broadcast_address,
network.num_addresses - 2)
for i, left in enumerate(networks):
for right in networks[i + 1:]:
assert not left.overlaps(right), (left, right)В этом примере ожидается 254 обычных адреса хостов в каждой /24. Выражение «минус два» не является универсальным для /31 и /32: их назначение и правила использования иные. Скрипт проверяет только перечисленные сети, не весь реальный проект.
В USERS можно выделить DHCP .100–.220, зарезервировав остальное по плану. Учтите телефоны, Wi-Fi и время аренды. DHCP предоставляет клиенту не только адрес, но и маску, шлюз, DNS и другие согласованные параметры. AD-клиенту нужен корпоративный DNS, а не случайный публичный сервер.
При централизованном DHCP в другом VLAN нужен relay и разрешённый путь обмена. Если в одном сегменте неожиданно появился второй сервер, воспользуйтесь инструкцией поиска DHCP.
5. VLAN создаёт отдельный L2-домен, но не гарантирует изоляцию
Access-порт обычно относится к одному пользовательскому VLAN; trunk передаёт трафик нескольких разрешённых VLAN. Конкретные native VLAN, маркировку и допустимый список согласуйте с обеих сторон. Неверное предположение о режиме uplink может дать доступ не тому сегменту или полностью нарушить связь.
Если межсетевые шлюзы свободно маршрутизируют весь трафик между VLAN, сегментация не стала политикой безопасности. Нужно выбрать точку фильтрации: stateful firewall, ACL на L3-устройстве или другой управляемый механизм. Stateful-фильтрация учитывает состояние соединения; обычная ACL пакетов требует отдельного анализа обратного трафика.
Отдельный управленческий VLAN уменьшает смешение пользователей и администрирования, но не заменяет AAA, SSH, MFA и ограничения источников. Запрет доступа к SVI или MGMT должен быть проверен реальным тестом, а не только наличием красивого названия MANAGEMENT.
6. Составьте матрицу доступа до написания ACL
Каждое разрешение описывайте как источник, назначение, протокол/порт, инициатор, бизнес-основание и владелец. Например:
USERS → корпоративный DNS: TCP/UDP 53, разрешено
USERS → HTTPS-приложение 10.20.20.10: TCP 443, разрешено
GUEST → внутренние подсети: новые соединения запрещены
Административный jump host → коммутаторы: TCP 22, разрешено
Прочие рабочие станции → управление коммутаторами: запрещеноЭто фрагмент, а не полный ruleset: не хватает конкретных DNS, доступа в интернет, AD-зависимостей, NTP и других сервисов. Для AD нельзя решить всё разрешением одного порта 389: состав соединений определяют по роли клиентов и серверов.
Для правила фиксируйте срок пересмотра и отрицательный тест. Разрешение any → any ради быстрого восстановления превращается в постоянную дыру, если у него нет владельца и даты окончания. Логирование отказов планируйте с ограничением шума: бесконтрольный журнал способен перегрузить устройство и скрыть значимые события.
7. Проектируйте Wi-Fi как несколько сценариев доступа
Гости и сотрудники требуют разных политик. Гостевой SSID не должен давать маршрута к управлению, серверам и пользовательским подсетям компании. Captive portal сам по себе не заменяет фильтрацию после авторизации; client isolation также не равна запрету доступа к внутренней сети через шлюз.
Для управляемого корпоративного доступа рассмотрите 802.1X/RADIUS и сертификатную аутентификацию EAP-TLS. Важны PKI, выпуск и отзыв сертификатов, настройка доверия и имён серверов, а также управляемые клиентские профили. Общий Wi-Fi-пароль затрудняет индивидуальный отзыв и аудит.
Не утверждайте, что любой WPA2-пароль «взламывается за пару минут». Риск зависит от метода, стойкости секрета, оборудования и конфигурации. Слабый общий пароль действительно создаёт угрозу, но точная оценка не должна подменяться мифом. Для сети с enterprise-аутентификацией неверная проверка сертификата тоже способна обесценить защиту.
8. Посчитайте ёмкость, питание и реальные резервные пути
Запишите число занятых портов, резерв расширения, одновременную нагрузку, uplink и ограничения стека или агрегирования. LACP не превращает один поток автоматически в сумму скоростей всех линков: распределение зависит от хеширования и характеристик трафика.
Для PoE учитывайте мощность устройств и общий бюджет коммутатора, а для ИБП — нагрузку и время автономии. Два блока питания, подключённые к одной розетке без ИБП, не дают независимого резервирования питания.
Два интернет-провайдера могут проходить одним кабельным вводом или иметь общую точку отказа. Аналогично два оптических волокна в одной трассе не защищают от её повреждения. Проверяйте независимость, а не только количество линий. Выбор и приёмка оптики описаны в статье об оптоволокне.
9. Определите тесты до миграции и начните с пилота
Для каждого сервиса создайте положительный тест и тест запрета. Пример на Windows:
Get-NetIPConfiguration
Resolve-DnsName app.corp.example
Test-NetConnection -ComputerName '10.20.20.10' -Port 443
Test-NetConnection -ComputerName '10.20.10.2' -Port 22Из USERS HTTPS-приложение должно быть доступно, управление коммутатором — запрещено по выбранной политике. С административного jump host ожидается другой результат. Обе машины должны действительно находиться в нужных сегментах. Для TCP достаточно этого теста соединения; UDP-службы проверяют протокольным запросом, а приложение — своей рабочей операцией.
Пилот охватывает несколько устройств, включая типичный Wi-Fi-клиент и зависимый сервис. Проверяйте DHCP, DNS, маршруты, разрешения, MTU и журналы. Перед массовым переносом должен существовать точный план возврата портов, VLAN, адресов и правил.
10. Какая документация нужна после ввода сети
Сохраните физическую и логическую схемы, адресный план, матрицу доступа, инвентарь, конфигурационные копии, журнал изменений и результаты тестов. Укажите ответственных за обновление и способ получения аварийного доступа. Секреты хранятся отдельно от общей документации.
В мониторинг включите доступность устройств и сервисов, ошибки интерфейсов, загрузку uplink, питание, события аутентификации и контроль изменения конфигурации. Не ограничивайтесь ping: коммутатор может отвечать, когда DHCP или приложение уже недоступны.
Проект принят, когда требования владельцев сервиса проверены, запрещённые связи действительно запрещены, резервирование испытано в согласованном окне и команда может восстановить конфигурацию. Это даёт компании управляемую сеть, а не набор настроек, понятный только человеку, который однажды её собрал.
Нужно привести сеть в управляемое состояние?
Начните с учёта оборудования и наблюдаемости, затем определите требования к защите корпоративной сети.