Сеть досталась без документации: как восстановить схему и ничего не отключить

Под этим я понимаю обследование без переподключения кабелей, перезагрузок и изменения настроек. Обещать нулевой риск для незнакомого оборудования было бы неправильно. Даже опрос может создать нагрузку, а старый принтер или контроллер — неожиданно отреагировать на сканирование.

На первом проходе я ограничиваю задачу чтением существующих таблиц и конфигураций через согласованные учётные записи. Активный поиск, включение LLDP или SNMP, настройка зеркалирования и проверка кабеля прибором — отдельные работы. Если для подтверждения связи нужен разрыв линии, в схеме пока остаётся вопросительный знак.

До доступа к оборудованию стоит определить границы: какие помещения и подсети входят в обследование, кто отвечает за телефонию, камеры, СКУД и оборудование подрядчиков, к кому обращаться при сбое. Отдельно записываются недоступные зоны. Пропуск в документации лучше, чем самовольное изменение чужой системы.

Сначала нужен список опорных точек: ввод провайдера, маршрутизатор или межсетевой экран, основные коммутаторы, серверы DNS и DHCP, гипервизоры, Wi-Fi-контроллер и система мониторинга. Их названия пока могут быть рабочими: SW-01, SW-02, FW-01. Важнее не перепутать устройства между собой.

В серверной фотографируются общий вид стойки, панели и читаемые номера портов. Кабели при этом остаются на месте. На снимке должна быть понятна ориентация: какая стойка, какой шкаф, какая панель. Пароли, QR-коды доступа и наклейки с чувствительными сведениями в общую папку не попадают.

Полезно поговорить с человеком, который работает на площадке: где пропадает связь, какие устройства включают редко, кто обслуживает кассу или контроллер двери. Ответы заносятся как сообщения сотрудников, а не как подтверждённая топология.

• Сохранить доступные конфигурации штатным способом, учитывая модель и версию ПО.
• Отметить дату, время, часовой пояс и источник каждой выгрузки.
• Хранить исходные файлы отдельно от обработанной таблицы, с ограничением доступа.
• Зафиксировать уже существующие ошибки и недоступные сервисы, чтобы не принять их за последствия обследования.

Экспорт конфигурации может содержать секреты. Его место — в защищённом хранилище, а не в приложении к статье или общедоступной схеме. И сам факт экспорта ещё не доказывает, что устройство получится восстановить: это проверяют отдельно.

Я разделяю физические соединения, логическую сеть и зависимости сервисов. Иначе на одном листе быстро смешиваются кабели, VLAN, адреса и стрелки к приложениям, которые никто не может уверенно объяснить.

В учебном офисе есть FW-01, два управляемых коммутатора SW-01 и SW-02, точка AP-01, рабочая станция PC-07 и принтер PRN-02. В начале известны только их названия и часть адресов. В конце нужно проследить подключение PC-07 и честно отметить, чего о принтере выяснить не удалось.

Один IP-адрес не равен одному устройству: сервер может иметь несколько интерфейсов, а адрес — сменить владельца. Поэтому отдельный инвентарный ID связывается с серийным номером, интерфейсами и наблюдениями. Название из DNS удобно для поиска, но не заменяет идентификацию.

DHCP даёт отправную точку: адрес, идентификатор клиента, имя, состояние и срок аренды. Я использую эту выгрузку как список наблюдений. В ней не будет всей сети: устройства со статическими адресами, другой DHCP-сервер и давно выключенное оборудование требуют отдельных источников.

Для Windows DHCP пример чтения активных аренд одной области выглядит так. Нужны модуль DhcpServer, разрешённый доступ к серверу и существующая область; имя и адрес ниже относятся к учебному примеру.

Get-DhcpServerv4Lease -ComputerName DHCP-01 -ScopeId 10.20.20.0 |
  Select-Object IPAddress, HostName, ClientId, AddressState, LeaseExpiryTime

По документации Microsoft, без параметра AllLeases команда возвращает активные аренды указанной области. Для истории понадобятся другие состояния и, при наличии, журналы. Идентификатор ClientId не следует автоматически считать MAC-адресом: сначала проверьте его формат и сопоставьте с интерфейсом клиента.

В нашем примере находится запись PC-07: 10.20.20.47, ClientId 02-00-00-00-20-47. В таблицу она попадает с пометкой «DHCP, снимок T0». Это ещё не доказательство, что компьютер сейчас включён или подключён к конкретному порту.

Кроме аренд сохраняются области, исключения, резервирования и параметры шлюза и DNS. Резервирование адреса не означает, что устройство действительно использует DHCP: локальную настройку всё равно нужно проверить.

Дальше я сопоставляю адрес клиента с MAC. Для IPv4 помогает ARP, для IPv6 — таблица соседей NDP. Смотреть их нужно там, где есть нужный сегмент: например, на его шлюзе. Таблица рабочего ноутбука не покажет MAC каждого устройства за маршрутизатором.

# Windows PowerShell: локальный кеш соседей IPv4
Get-NetNeighbor -AddressFamily IPv4 |
  Select-Object InterfaceIndex, IPAddress, LinkLayerAddress, State

# Linux: локальные таблицы соседей
ip -4 neigh show
ip -6 neigh show

Состояние Stale не означает «устройство выключено». Оно говорит о состоянии записи кеша. Отсутствие записи тоже не доказывает отсутствие узла. Не нужно очищать таблицу или запускать массовый ping, чтобы получить более красивый список.

В учебном снимке шлюза FW-01 адрес 10.20.20.47 связан с 02:00:00:00:20:47. На PC-07 через локальные настройки подтверждён тот же MAC проводного интерфейса. Теперь есть два независимых наблюдения, согласующихся с DHCP.

Для сопоставления привожу MAC-адреса к одному виду: 02-00-00-00-20-47, 02:00:00:00:20:47 и 0200.0000.2047 могут обозначать один адрес. При этом сохраняю оригинальные значения. Если источники расходятся, проверяю время выгрузок, VLAN, несколько адаптеров, виртуальные интерфейсы и повторное использование IP. Производитель по префиксу MAC — только подсказка, особенно при локально назначенных и случайных адресах.

Справка по полям: Get-NetNeighbor; для Linux — ip-neighbour.

Таблица коммутации, которую также называют FDB или MAC-таблицей, показывает, через какой порт коммутатор выучил адрес в данном VLAN. Здесь легко сделать лишний вывод: увидеть MAC на порту и объявить, что компьютер подключён прямо к нему. За портом может находиться ещё один коммутатор, точка доступа, телефон с проходным подключением или гипервизор.

Ниже — команды чтения для распространённых вариантов Cisco IOS/IOS XE. Синтаксис и доступность зависят от платформы; сначала сверяйте справку конкретного устройства.

show mac address-table dynamic
show mac address-table address 0200.0000.2047
show interfaces status
show interfaces trunk
show vlan brief
show lldp neighbors detail

Для RouterOS с bridge можно начать с /interface bridge host print и /ip neighbor print detail. Какие записи видны и как учитывается аппаратная коммутация, зависит от модели и конфигурации. Поля разбираются в руководстве MikroTik. Не переносите команды с одной платформы на другую по сходству названий.

Сначала нужно выяснить, куда ведёт Gi1/0/24 на SW-01. Если это восходящее соединение SW-02, переход к его таблице обоснован. Если сосед неизвестен, линия остаётся неподтверждённой.

Динамические записи стареют. Для тихого устройства можно дождаться штатной активности и повторить чтение в согласованное время. При агрегации портов таблица может указывать логический Port-channel или bond: по такой записи нельзя выбирать конкретный физический кабель. А несколько MAC на одном порту сами по себе не доказывают наличие неуправляемого свитча.

LLDP помогает увидеть объявленные соседом идентификаторы устройства и порта. В учебном снимке SW-01 сообщает: локальный Gi1/0/24 соединён с SW-02, удалённый порт Gi1/0/24. Затем я проверяю обратную сторону на SW-02 и сопоставляю chassis ID, имена и номера портов.

Имя из объявления может быть устаревшим или повторяться. Поэтому одного System Name недостаточно. Сохраняются исходный вывод, идентификатор устройства, локальный и удалённый интерфейсы, время наблюдения. Для стека отдельно проверяется нумерация участников.

Пустой список соседей ничего не говорит об отсутствии кабеля. LLDP может быть выключен, не поддерживаться или не проходить через промежуточное оборудование. Включать его по всей сети ради обследования я не предлагаю: это изменение конфигурации, которое нужно рассматривать отдельно.

RouterOS объединяет сведения разных протоколов обнаружения; поля и ограничения описаны в документации Neighbor discovery. Для Cisco используйте руководство CDP, LLDP и MAC для соответствующей платформы.

Даже согласованное соседство не описывает всю физическую трассу: между устройствами могут быть патч-панели, оптика и пассивные соединения. На схеме логическое соседство и подтверждённый кабельный маршрут обозначаются раздельно.

MAC-таблица не знает, что кабель проходит через панель PP-01/18 и заканчивается розеткой B-214/02. Эти сведения появляются из осмотра, маркировки, исполнительной документации и проверки на рабочем месте.

Для PC-07 цепочка складывается так: MAC проводного адаптера подтверждён локально; SW-02 видит его на Gi1/0/7; патч-корд от этого порта визуально прослежен до PP-01/18. На рабочем месте кабель PC-07 идёт в розетку B-214/02. Маркировка панели указывает на ту же розетку, но скрытая линия за стеной ещё не проверена.

Поэтому участок PP-01/18 → B-214/02 получает статус «предполагается по маркировке». Совпадение подписей полезно, но не заменяет проверку линии. Полностью подтверждённый путь и правдоподобная гипотеза не должны выглядеть одинаково.

Если кабель можно проследить взглядом без натяжения и перемещения соседних соединений, этого достаточно для фиксации видимого участка. Не стоит вытягивать пучок, расстёгивать нагруженные крепления или трогать оптику ради фотографии.

Тональный генератор, тестер и TDR применяются по инструкции прибора и оборудования. Некоторые проверки требуют разрыва или могут повлиять на линк и PoE. Когда подходящего безопасного способа нет, я оставляю задачу на согласованное окно работ. Порт с погасшим индикатором нельзя считать свободным: за ним может быть выключенный компьютер или резервное устройство.

Пусть PRN-02 имеет адрес 10.20.20.60 и MAC 02:00:00:00:20:60. На SW-02 этот адрес виден через Gi1/0/12 вместе с несколькими другими. LLDP на порту пуст. Объявлять найденный «свитч под столом» рано: наблюдение допускает несколько объяснений.

В журнале появляется запись: «За Gi1/0/12 обнаружено несколько MAC в VLAN 20; состав промежуточного оборудования не установлен». Следующее действие — осмотр рабочего места и сверка с владельцем оборудования. До этого на схеме остаётся пунктир к неизвестному сегменту.

Статус относится к конкретному утверждению. Можно подтвердить, что MAC доступен через порт, и одновременно не знать физическую схему за ним. В шаблоне для этого есть поле «Что именно установлено».

При противоречии я сохраняю обе версии с датами. Старое DNS-имя не удаляется из исходных данных, а переносится в примечание. Если MAC перемещается между портами, это повод разобраться с топологией и временем наблюдений, а не выбрать наиболее удобную строку.

Когда основные соединения понятны, можно нанести логическую сеть. Для каждого VLAN записываются ID, назначение, подсеть, шлюз и устройство, на котором работает маршрутизация. Эти сведения берутся из конфигурации и сверяются с настройками клиентов. Номер VLAN нельзя выводить из номера подсети.

Для соединений между коммутаторами нужны разрешённые VLAN, режимы tagged/untagged, native VLAN или PVID в терминологии платформы. Настройки на двух концах могут различаться. Обнаруженное несоответствие попадает в список замечаний; исправлять его во время инвентаризации не следует.

У AP-01 отдельно описываются управляющий адрес и подключение к SW-02, затем SSID и привязка клиентских сетей. Где именно появляются MAC Wi-Fi-клиентов, зависит от локальной коммутации, туннелирования на контроллер и маршрутизации. Нельзя автоматически приписывать каждого клиента физическому порту точки.

Маршруты и правила межсетевого экрана показывают предполагаемый путь и ограничения доступа. Наличие разрешающего правила не доказывает, что приложение работает. Если в границы работы входит проверка сервиса, выполняется согласованная штатная операция и отдельно записывается её результат.

IPv6 учитывается отдельными записями: префикс, маршрутизатор, механизм выдачи настроек, соседи. Инвентаризация только IPv4 не даёт оснований утверждать, что других путей связи в сети нет.

В приложенной схеме сплошными линиями обозначены подтверждённые в учебном сценарии соседства и видимые подключения. Скрытый участок между панелью и розеткой выделен пунктиром. Ветка принтера проходит через блок «Неизвестный сегмент»: обнаружение MAC через порт показано отдельно от физической трассы.

Файл draw.io можно открыть в diagrams.net и заменить учебные названия своими. Рядом доступен SVG для просмотра без редактора. На схеме есть легенда; статус соединения читается по линии и подписи, а не только по цвету.

Я не стремлюсь заполнить каждый пробел до выпуска первой версии. Схема уже полезна, если по ней можно найти опорные устройства, понять границы подтверждённого и продолжить обследование с того же места.

Вместе со статьёй доступны два CSV-файла: пустой шаблон и заполненный учебный пример. Они открываются в Excel и LibreOffice; при импорте выберите UTF-8 и разделитель «точка с запятой». IP, MAC и номера портов лучше импортировать как текст. Каждая строка описывает отдельное наблюдение или участок связи, поэтому одно устройство может встречаться несколько раз.

Поля включают инвентарный ID, устройство, интерфейс, IP, MAC, VLAN, соседнее устройство и порт, панель, розетку, статус, установленный факт, источник, время, исполнителя и следующий шаг. В рабочем файле вместо T0 указывается действительное время с часовым поясом.

Таблица не предназначена для хранения паролей и SNMP community. Ссылка на защищённое хранилище допустима только там, где это предусмотрено правилами организации. Перед отправкой подрядчику нужно проверить состав выгрузки и оставить только необходимые ему данные.

Для небольшого офиса таблицы и редактируемой схемы достаточно для начала. По мере роста можно перенести учёт в NetBox или другую систему. Начинать с установки большой платформы необязательно: она не подтвердит ошибочную связь и не объяснит непонятную маркировку вместо администратора.

Критерий готовности я формулирую через проверяемые действия. Другой администратор должен открыть комплект документов и найти путь выбранного рабочего места до шлюза, увидеть источник каждого вывода и понять, где остаются неизвестные участки.

• Опорные устройства получили устойчивые ID; доступные конфигурации и исходные наблюдения сохранены.
• У связей есть порты, статус и основание. Пунктир не скрывает предположение под видом факта.
• Физическая схема согласуется с таблицей, а VLAN и подсети вынесены в отдельное логическое представление.
• Неизвестные сегменты и противоречия оформлены как конкретные задачи с владельцем и следующим действием.
• Файлы доступны ответственным сотрудникам; указаны дата версии и порядок обновления.

После замены коммутатора, переноса рабочего места или изменения VLAN обновляется соответствующая запись, а не создаётся ещё одна схема с названием «финальная». Старую версию стоит сохранить, новую — датировать. Ответственный за изменение указывает, что именно проверено после работ.

Начните с одного рабочего места. Пройдите цепочку от его интерфейса до шлюза, запишите доказательства и оставьте отметки там, где их не хватает. Такой маршрут задаст понятный стандарт для остальной сети.