Как составить журнал сети

Сразу скажу, что на написание мини статейки об основах документирования для наших подписчиков подтолкнул курс от уже упоминавшегося на канале Netskills. Вся основная механика у них на канале:

Курс подойдет для совсем “зеленых”, хотя и для матерых не помешает на x2 скорости пробежаться, чтобы систематизировать и обновить имеющуюся экспертизу. Я же в свою очередь хочу выдать вам основное резюме по данной теме и дополнить материал коллег полезными ништячками шаблонами для документирования.

Все еще интересно? Тогда погнали!

Итак обозначим состав рассматриваемой документации:

Структурная схема. Ее еще ласково называют структурой

Давайте рассмотрим обозначенную доку в двух контекстах: 

1. Проектирование/модернизация;
2. Эксплуатация существующей инфраструктуры. 

Проектирование/модернизация 

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

Эксплуатация существующей инфраструктуры

Чем отличается эксплуатация от проектирования/модернизации. Ну прежде всего эксплуатация это работа с тем что уже имеешь. По факту эксплуатация это про учет изменений. Если документации на существующую инфраструктуру нет или она косая и кривая, то стоит ее разработать с нуля. В данном случае можно пойти от частного к общему. Стоит начать с L2 схемы и пойти выше к структурной схеме. А на инженера по СКС делегировать задачу по заполнению КЖ. L2 схемы ему будет достаточно. Удобный шаблон КЖ дам вам ссылкой.

Итак, у нас есть корректная документация, как основа для дальнейшего учета. С точки зрения эксплуатации дальше просто не забывайте ее актуализировать. 

1. Так выглядит типовая, по дизайну современная структурная схема в draw.io (diagrams.net):

На структурную схему наносятся принципиальные моменты дающее полное, но общее представление о том:

1. Cколько у нас провайдеров;
2. Как у нас выстроена архитектура ЛВС: внешний периметр, ядро, уровень доступа; 
3. Как обстоит дело с отказоустойчивостью. Каскад устройств, как на картинке firewall и core switch, указывает на то, что используется стек. Вот какой конкретно стек: stack wise, vss с единым control plane или vPC/MCLAG домен с раздельным control plane тут не важно. Аспекты типов стекирования отражаются на схеме L2, в таблице кабельных соединений, а особенности настроек в документе под номером 6 — “Описание настроек”.

Еще раз заостряю внимание. Структурная схема — общая информация. Стеки/кластера и связанные с этим концепции укладываем на L2 схему.

2.Так выглядит типовая, по дизайну современная L3 схема в draw.io (diagrams.net):

После того как у нас есть “структурка” мы готовим (требуем от подрядчика) L3 схему.

L3 схема

На L3 схеме отображаются ключевые сегменты сети: стыки access-core, core-FW, FWs (border routers) — ISPs. Если описывается корпоративная инфраструктура, то к ключевым сегментам можно отнести сегменты в которых находятся основные корпоративные ресурсы: dns, почта, NTP, VIP пользователи, гостевой и пользовательский Wi-Fi. Если описывается инфраструктура уровня ЦОД, где может быть десятки тысяч сегментов, необходимо ограничится L3 сегментами лишь стыковых соединений. Сегмент удобно изображать в виде трубы с нанесением на нее адреса подсети и соответствующего идентификатора vlan. Целесообразно указывать default gateway. Оборудование уровня L2: L2 коммутаторы, хабы, медиаконвертеры на L3 схеме не изображаются!

3. Так выглядит типовая, по дизайну современная L2 схема в draw.io (diagrams.net): 

После того как имеется структурная схема и L3 переходим к L2 схеме.

L2 схема

L2 схема это уже про частности канального, местами физического уровня. Тут мы уже делаем акцент на типе используемого кабеля: оптика или медь, стековое соединение. Указываем номер порта, тип линка: агрегированный или нет, режим: trunk или access, id vlans в транках (можно и не указывать, так как их может быть слишком много). Конкретные перечни vlan относящихся к информационным системам клиентов, пользователей и то каким транкам они принадлежат лучше всего отражать в документе “Описание настроек”. На схеме же можно/целесообразно отразить факт наличия in-band и out-of-band менеджмента. Т.е. на наличие управляющего трафика посредством основных каналов и альтернативного варианта управления инфраструктурой посредством выделенных каналов, менеджмент коммутаторов, консольных серверов.

Если оборудование установлено в стойках имеющих нумерацию, то целесообразно нанести на L2 схему имена по следующему принципу. К примеру СoreSW1 у вас находится в стойке F36, 27-й юнит в серверной №1. То целесообразно данному коммутатору дать такое имя: sr1-f36-27-core1. Т.е. sr- server room 1 и дальше логика ясна. Если оборудование разбросано по цодам, то можно заменить на dc#. Пример: dc1-k10-30-fw1 и dc2-g10-12-fw1. У вас есть межсетевые экраны в даталайне и селектеле. Вы определили, что в вашей картине мира даталайн это DC1, а селектел — DC2. Данную идею именования можно развить не только для схематичного отображения, но и по аналогии задавать FQDN этим устройствам на локальных DNS серверах.

На L2 схеме отражаются: коммутаторы, маршрутизаторы, ключевые сервера, рабочие места, аспекты стекирования.

На L2 схеме не отражаются: ip-адреса, виртуальные сущности: vdc, vrf, vds, vdom и тд. и тп. 

Аспекты стекирования на L2 схеме

Traditional — два standalone коммутатора с наличием петли и работающим STP (стоит избегать таких вариантов архитектур, по возможности. Но в кампусе допускается);

StackWise Virtual-Physical/StackWise Virtual-logical — Два коммутатора представляются Access уровню как один виртуальный. Нет риска петель, не надо беспокоится о STP, нет простоя линков (must have в крупном enterprise и data center) 

IP план

При проектировании IP план составляется в Excel таблице. Честно говоря это самый удобный способ так как можно использовать функционал группировок

Вот если говорить не про проект, а про эксплуатацию действующей инфраструктуры, то существует два подхода:

1. Ведение такой же Exel таблицы. Просто функционально, но есть нюансы. Как правило плодится много копий и по итогу информация зачастую не 100% актуальна. Если документ ведет один человек, то это куда не шло. Если к планированию и учету IP пространства причастны >1, то целесообразно использовать специальные продукты (пункт 2). 
2. Система централизованного учета IP пространства. Есть один бесплатный и удобный продукт под названием phpipam, лично его использую. С этим инструментом планирование и учет IP пространства циклопически упрощается (https://phpipam.net/)

Таблица кабельных соединений aka кабельный журнал (КЖ) aka схема коммутации

В организациях наиболее часто встречается именно КЖ, как оперативный документ инженера СКС (структурированная кабельная система). В проектах же редко используется понятие кабельного журнала, чаще всего это таблица кабельных соединений или схема коммутации.  Если руководствоваться моделью OSI, то это уровень L1 — физический. Редко, но можно услышать такое понятие как L1 схема. По факту это все об одном и том же

Кабельный журнал. <<скачать шаблон>>

Маркер — идентификатор связи (по аналогии с ключевым полем в БД). В продаже есть специальные принтера. Можно использовать ручные бобины.

Откуда (Ряд/Шкаф/Юнит)-Оборудование-Плата/порт

КудаОткуда — транзитные (промежуточные) коммутации. Если оконечное оборудование, в нашем примере это блейд корзина HP C7000 подключается портом OA1 (On-board administrator) непосредственно к менеджмент коммутатору Cisco WS-C3750X-24 (Маркер 0051), то блоки КудаОткуда пустые. А вот если взять маркер 0094, то связь между с7000 и коммутаторами ядра пролегает через промежуточную патч-панель и нетподиум (оптическая СКС);

Куда — собственно так же как и Откуда — Оборудование-Плата/порт. Обычно (в большинстве случаев) Откуда — оконечное оборудование: рабочее место, сервер. Куда — коммутатор. Но если связь отражает межкоммутаторное взаимодействие, кластерное взаимодействие, то слева отражается условный 1-й номер, а справа условный 2-й номер.

Тип разъема: RJ-45, MM/SM LC/MM SC и тд. и тп. По данному столбцу сразу понятно что у вас за физика оптика или медь, какой тип оптики мультимод или синглмод, какой тип оптического разьема.

Количество кусков (патчкордов) и их длина— тут все должно быть понятно.

Кто и когда проводил работы — тоже очень важный момент.

Описание настроек

Совершенно необходимы документ при проектировании/модернизации. В практике я встречал еще такой синоним как пусконаладочные карты. В целом, данные документы про настройки по шагам. В них описывается текущая настройка, какие вносятся изменения и для чего, какой результат ожидается. Когда будет этап пусконаладки если ожидаемый результат получен — успех, нет — разбираемся в чем проблема и уже только устранив которую идем дальше;

Дополнительные документы:

7. Расположение оборудование в стойках <<скачать шаблон>> (см. вкладку СКС-2)

8. Схемы подключения питания <<скачать шаблон>>

Очень важные схемы. Предположим у вас в стойках по два независимых луча. Подрядчик или ваш инженер взяли два одноблочных устройства отказоустойчивого  кластера и подключили к одному лучу. Луч вырубился не штатно или планово на регламент и нет больше вашего клачтера — весь сегмент прилег. Если схема имеется, по ней монтировали и по нейже осуществлена приемка и испытания, то не будет вам печали. Возьмите на вооружение) “Знаем, плавали, вся жопа в ракушках”)

P.S. Ссылка на схемы в draw.io

Немного поддержу Netskills еще рекламкой:

https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqbFQxMzRuTndmVlNHcnZ6S285Q2pPZnF4VTRrUXxBQ3Jtc0tuZXQxVnhNRnFWWFVDYXZrQVZ0NFZQM084bFZIa3RjbS1yVjM0SUNNZVhZV3praWFMd3ZaOEFKR3ZMSmpXdFNKVXpDZWl2dXJKSVB4Z01uY1hzQWVGaEt2bWhRLUpDbjZlMkRFdkplSHdfM2k0cG1lOA&q=https%3A%2F%2Fnetskills.ru%2Fosnovi-dokumentirovaniya-setei%2Fcertification

Если материал понравился — лучшая помощь порекомендовать канал товарищу IT-шнику. Лишними знания не бывают)

Спасибо за внимание!

Может быть, вы перешли на новое место работы на должность сетевого администратора и, приступив к управлению сетью, обнаружили, что по сети нет никакой документации / кабельного журнала. Или ваш начальник потребовал от вас документирование сети от начала до конца. Вне зависимости от ситуации, если вы должны документировать сеть, не имея никаких начальных записей, то не так-то просто понять с чего начать:

• Как определить какую информацию о сети включить в кабельный журнал?
• Как собрать нужную вам информацию, провести аудит сети?
• Как лучше представить информацию, полученную в результате аудита сети?

Но, прежде всего, рассмотрим, стоит ли этим заниматься.

Зачем нужно документировать сетевую инфраструктуру?

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

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

Ваш кабельный журнал должен быть:

• Инструментом для устранения неисправностей. Когда что-нибудь идет не так как надо, документация может служить руководством при поиске и устранении неисправности. Она сохранит время и деньги.
• Помощью в подготовке нового персонала. Если к вам приходит новый сотрудник, то он или она будет скорее готовы к работе, если доступна документация по тому участку работы, где ему (ей) предстоит работать. Это снова сбережет время и деньги.
• Помощью для поставщиков и консультантов. Услуги этих людей, как правило, весьма дороги. И если им нужно знать какие-либо детали вашей сетевой инфраструктуры, то наличие документации позволит им выполнить свою работу быстрее. Что опять же сбережет время и деньги вашей компании.

Что и как должно быть отражено в кабельном журнале

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

Хотя каждая сеть имеет свои уникальные особенности, многие общие элементы являются кандидатами на включение в документацию:

• Топология сети. Обычно эта информация представляется в форме диаграмм, на которых показаны основные сетевые узлы, такие как, маршрутизаторы, коммутаторы, файерволы, сервера и как они взаимосвязаны. Принтеры и рабочие станции обычно сюда не включаются.
• Информация о серверах. То есть, та информация, которая необходима вам для управления и администрирования серверами, такая как имя, функции, IP адреса, конфигурация дисков, ОС и сервис-паки, дата и место покупки, гарантия и так далее.
• Назначение портов коммутаторов и маршрутизаторов. Сюда включается детальная информация о конфигурации WAN, VLAN’ов или даже назначение портов сетевым узлам через патч-панель.
• Конфигурация сетевых служб. Сетевые службы, такие как DNS, WINS, DHCP, и RAS, критичны для операций в сети. Вам следует детально описать, как они структурированы. Хотя всегда можно получить эту информацию с серверов, можно сэкономить время, если документировать их заранее в легкочитаемом формате.
• Политики и профили доменов. Вы можете ограничить возможности пользователей с помощью Policy Editor в Windows NT или с помощью Group Policies в Windows 2000. При этом можно создать профили пользователей, хранимые на сервере, а не на локальной машине. Если такие возможности используются, то такая информация должна быть документирована.
• Критически важные приложения. Вы должны включить в документацию как такие приложения поддерживаются, что бывает с ними чаще всего не так и как решать такие проблемы.
• Процедуры. Это само по себе может быть большим проектом. В основном процедуры — средство для реализации политик и могут быть достаточно обширными. Например, политика может устанавливать, что «Сеть должна быть защищена от неавторизованных пользователей». Однако, для реализации такой политики, потребуется масса усилий. Существуют процедуры для файерволов, сетевых протоколов, паролей, физической безопасности и так далее. Вы можете также иметь отдельные процедуры для обработки проблем, о которых сообщают пользователи, и процедуры для регулярного обслуживания серверов.

Чтобы получить действительно полную документацию следует включить в нее, там, где это применимо:

• Номер канала или IP адрес
• Основной производитель
• Начало и конец соединения (если оно точка-точка)
• Оконечное и сетевое оборудование на каждом конце
• Кто в компании владеет или отвечает за соединение
• Как канал подводится к зданию (медь, оптоволокно, радио, и тому подобное)
• Точка входа в здании
• Имя и контактный номер основного поставщика услуг

Хотя такая работа требует достаточно много времени, аудит и документирование сети важны и необходимы. Выделите время на планирование проекта документирования сети.

Рассмотрите не только, какие аспекты сети вы будете документировать, но и в каком порядке.

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

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

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

Как поддержать документацию в актуальном состоянии

Для любого работающего в ИТ отрасли известно, что изменения постоянны. Это только вопрос времени — и обычно очень малого времени — когда значительные изменения будут внесены в сетевую инфраструктуру. Обновляются сервера, добавляются сетевые сегменты, меняются процедуры работы, нанимаются новые сотрудники или арендуются новые офисы. В результате сетевая документация, созданная с большим трудом, очень быстро становится устаревшей, если у вас нет серьезного плана, как ее сохранить актуальной.

Управление изменениями

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

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

Как будут оцениваться предложенные изменения, также может варьироваться от организации к организации. В этом могут участвовать всего лишь несколько человек, комитет или несколько комитетов. Но в любом случае следующим шагом за одобрением предложенного изменения должно быть обновление документации, чтобы отразить те изменения, которые будут реализованы — до того, как они будут реализованы. Этим будет гарантирована актуальность документации в любое время.

Дополнительные соображения

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

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

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

Бесконечный процесс

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

Время на прочтение
11 мин

Количество просмотров 135K

Любой администратор рано или поздно получает инструкцию от руководства: «посчитать, кто ходит в сеть, и сколько качает». Для провайдеров она дополняется задачами «пустить кого надо, взять оплату, ограничить доступ». Что считать? Как? Где? Отрывочных сведений много, они не структурированы. Избавим начинающего админа от утомительных поисков, снабдив его общими знаниями, и полезными ссылками на матчасть.
В данной статье я постараюсь описать принципы организации сбора, учёта и контроля трафика в сети. Мы рассмотрим проблематику вопроса, и перечислим возможные способы съема информации с сетевых устройств.

Это первая теоретическая статья из цикла статей, посвящённого сбору, учёту, управлению и биллингу трафика и IT-ресурсов.

Структура доступа в сеть Интернет

В общем случае, структура доступа в сеть выглядит следующим образом:

• Внешние ресурсы – сеть Интернет, со всеми сайтами, серверами, адресами и прочим, что не принадлежит сети, которую вы контролируете.
• Устройство доступа – маршрутизатор (аппаратный, или на базе PC), коммутатор, VPN-сервер или концентратор.
• Внутренние ресурсы – набор компьютеров, подсетей, абонентов, работу которых в сети необходимо учитывать или контролировать.
• Сервер управления или учёта – устройство, на котором работает специализированное программное обеспечение. Может быть функционально совмещён с программным маршрутизатором.

В данной структуре, сетевой трафик проходит от внешних ресурсов к внутренним, и обратно, через устройство доступа. Оно передает на сервер управления информацию о трафике. Сервер управления обрабатывает эту информацию, хранит в базе, отображает, выдает команды на блокировку. Однако, не все комбинации устройств (методов) доступа, и методов сбора и управления, совместимы. О различных вариантах и пойдет речь ниже.

Сетевой трафик

Для начала необходимо определить, а что же подразумевается под «сетевым трафиком», и какую полезную статистическую информацию можно извлечь из потока пользовательских данных.
Доминирующим протоколом межсетевого взаимодействия пока остается IP версии 4. Протокол IP соответствует 3му уровню модели OSI (L3). Информация (данные) между отправителем и получателем упаковывается в пакеты – имеющие заголовок, и «полезную нагрузку». Заголовок определяет, откуда и куда идет пакет (IP-адреса отправителя и получателя), размер пакета, тип полезной нагрузки. Основную часть сетевого трафика составляют пакеты с полезной нагрузкой UDP и TCP – это протоколы 4-го уровня (L4). Помимо адресов, заголовок этих двух протоколов содержит номера портов, которые определяют тип службы (приложения), передающего данные.

Для передачи IP-пакета по проводам (или радио) сетевые устройства вынуждены «оборачивать» (инкапсулировать) его в пакет протокола 2го уровня (L2). Самым распространенным протоколом такого типа является Ethernet. Фактическая передача «в провод» идет на 1м уровне. Обычно, устройство доступа (маршрутизатор) не занимается анализом заголовков пакетов на уровне, выше 4го (исключение – интеллектуальные межсетевые экраны).
Информация из полей адресов, портов, протоколов и счетчики длин из L3 и L4 заголовков пакетов данных и составляет тот «исходный материал», который используется при учёте и управлении трафиком. Собственно объем передаваемой информации находится в поле Length («Длина пакета») заголовка IP (включая длину самого заголовка). Кстати, из-за фрагментации пакетов вследствие механизма MTU общий объем передаваемых данных всегда больше размера полезной нагрузки.

Суммарная длина интересных нам в данном контексте IP- и TCP/UDP- полей пакета составляет 2…10% общей длины пакета. Если обрабатывать и хранить всю эту информацию попакетно, не хватит никаких ресурсов. К счастью, подавляющий объем трафика структурирован так, что состоит из набора «диалогов» между внешними и внутренними сетевыми устройствами, так называемых «потоков». Например, в рамках одной операции пересылки электронного письма (протокол SMTP) открывается TCP-сессия между клиентом и сервером. Она характеризуется постоянным набором параметров {IP-адрес источника, TCP-порт источника, IP-адрес получателя TCP-порт получателя}. Вместо того, чтобы обрабатывать и хранить информацию попакетно, гораздо удобнее хранить параметры потока (адреса и порты), а также дополнительную информацию – число и сумму длин переданных пакетов в каждую сторону, опционально длительность сессии, индексы интерфейсов маршрутизатора, значение поля ToS и прочее. Такой подход выгоден для ориентированных на соединение протоколов (TCP), где можно явно перехватить момент завершения сессии. Однако и для не ориентированных на сессии протоколов можно проводить агрегацию и логическое завершение записи о потоке по, например, таймауту. Ниже приведена выдержка из SQL-базы собственной системы биллинга, осуществляющей протоколирование информации о потоках трафика:

Необходимо отметить случай, когда устройство доступа осуществляет трансляцию адресов (NAT, маскарадинг) для организации доступа в Интернет компьютеров локальной сети, используя один, внешний, публичный IP-адрес. В этом случае специальный механизм осуществляет подмену IP-адресов и TCP/UDP портов пакетов трафика, заменяя внутренние (не маршрутизируемые в Интернете) адреса согласно своей динамической таблице трансляции. В такой конфигурации необходимо помнить, что для корректного учета данных по внутренним хостам сети съём статистики должен производиться способом и в том месте, где результат трансляции ещё не «обезличивает» внутренние адреса.

Методы сбора информации о трафике/статистике

Снимать и обрабатывать информацию о проходящем трафике можно непосредственно на самом устройстве доступа (ПК-маршрутизатор, VPN-сервер), с этого устройства передавая ее на отдельный сервер (NetFlow, SNMP), или «с провода» (tap, SPAN). Разберем все варианты по-порядку.

ПК-маршрутизатор

Рассмотрим простейший случай – устройство доступа (маршрутизатор) на базе ПК c ОС Linux.

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

• перехват (копирование) пакетов, проходящих через сетевую карту сервера, при помощи библиотеки libpcap
• перехват пакетов, проходящих через встроенный межсетевой экран
• использование сторонних средств преобразования попакетной статистики (полученной одним из двух предыдущих методов) в поток агрегированной информации netflow

Libpcap

В первом случае копия пакета, проходящего через интерфейс, после прохождения фильтра (man pcap-filter) может быть запрошена клиентской программой на сервере, написанной с использованием данной библиотеки. Пакет поступает вместе с заголовком 2го уровня (Ethernet). Можно ограничить длину захватываемой информации (если нас интересует только информация из его заголовка). Примерами таких программ могут быть tcpdump и Wireshark. Существует реализация libpcap под Windows. В случае применения трансляции адресов на ПК-маршрутизаторе такой перехват можно осуществлять только на его внутреннем интерфейсе, подключенном к локальным пользователям. На внешнем интерфейсе, после трансляции, IP-пакеты не содержат информации о внутренних хостах сети. Однако при таком способе невозможно учесть трафик, создаваемый самим сервером в сети Интернет (что важно, если на нем работают веб– или почтовый сервис).

Работа libpcap требует поддержки со стороны операционной системы, что в настоящее время сводится к установке единственной бибилиотеки. При этом прикладная (пользовательская) программа, осуществляющая сбор пакетов, должна:

• открыть необходимый интерфейс
• указать фильтр, через который пропускать принятые пакеты, размер захватываемой части (snaplen), размер буфера,
• задать параметр promisc, который переводит сетевой интерфейс в режим захвата вообще всех проходящих мимо пакетов, а не только адресованных MAC-адресу этого интерфейса
• установить функцию (callback), вызываемую на каждый принятый пакет.

При передаче пакета через выбранный интерфейс, после прохождения фильтра эта функция получает буфер, содержащий Ethernet, (VLAN), IP и т.д. заголовки, общим размером до snaplen. Поскольку библиотека libcap копирует пакеты, заблокировать их прохождение при ее помощи невозможно. В таком случае программе сбора и обработки трафика придется использовать альтернативные методы, например вызов скрипта для помещения заданного IP-адреса в правило блокировки трафика.

Межсетевой экран

Захват данных, проходящих через межсетевой экран, позволяет учесть и трафик самого сервера, и трафик пользователей сети, даже при работе трансляции адресов. Главное в этом случае – правильно сформулировать правило захвата, и поставить его в нужное место. Данным правилом активируется передача пакета в сторону системной библиотеки, откуда приложение учета и управления трафиком может его получить. Для ОС Линукс в качестве межсетевого экрана применяют iptables, а средства перехвата – ipq, netfliter_queue или ulog. Для OC FreeBSD – ipfw с правилами типа tee или divert. В любом случае механизм межсетевого экрана дополняется возможностью работы с пользовательской программой следующим способом:

• Пользовательская программа — обработчик трафика регистрирует себя в системе, используя системный вызов, или библиотеку.
• Пользовательская программа или внешний скрипт устанавливает правило в межсетевой экран, “заворачивающее” выбранный трафик (согласно правилу) вовнутрь обработчика.
• На каждый проходящий пакет обработчик получает его содержимое в виде буфера памяти (с заголовками IP и т.д. После обработки (учёта) программе необходимо также сообщить ядру операционной системы, что делать далее с таким пакетом — отбросить или передать далее. Как вариант, возможно передать ядру видоизмененный пакет.

Поскольку IP-пакет не копируется, а пересылается в программное обеспечение для анализа, становится возможным его «выброс», а следовательно, полное или частичное ограничение трафика определенного типа (например, до выбранного абонента локальной сети). Однако в случае, если прикладная программа перестала отвечать ядру о своем решении (зависла, к примеру), трафик через сервер просто блокируется.
Необходимо отметить, что описанные механизмы при существенных объемах передаваемого трафика создают избыточную нагрузку на сервер, что связано с постоянным копированием данных из ядра в пользовательскую программу. Этого недостатка лишен метод сбора статистики на уровне ядра ОС, с выдачей в прикладную программу агрегированной статистики по протоколу NetFlow.

Netflow

Этот протокол был разработан фирмой Cisco Systems для экспорта информации о трафике с маршрутизаторов с целью учета и анализа трафика. Наиболее популярная сейчас версия 5 предоставляет получателю поток структурированных данных в виде UDP-пакетов, содержащих информацию о прошедшем трафике в виде так называемых flow records:

Объем информации о трафике меньше самого трафика на несколько порядков, что особенно актуально в больших и распределенных сетях. Конечно же, блокировать передачу информации при сборе статистики по netflow невозможно (если не использовать дополнительные механизмы).
В настоящее время становится популярным дальнейшее развитие этого протокола – версия 9, основанная на шаблонной структуре flow record, реализации для устройств других производителей (sFlow). Недавно был принят стандарт IPFIX, который позволяет передавать статистику и по протоколам более глубоких уровней (например, по типу приложения).
Реализация netflow-источников (агентов, probe) доступна для ПК-маршрутизаторов, как в виде работающих по описанных выше механизмам утилит (flowprobe, fprobe, softflowd), так и непосредственно встроенных в ядро ОС (FreeBSD: ng_netgraph, Linux: ipt_neflow). Для программных маршрутизаторов поток статистики netflow можно принимать и обрабатывать локально на самом маршрутизаторе, или отправлять по сети (протокол передачи – поверх UDP) на принимающее устройство (коллектор).

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

Функции экспорта netflow поддерживают маршрутизаторы Cisco Systems, Mikrotik, и некоторые другие. Аналогичный функционал (с другими протоколами экспорта) поддерживается всеми крупными производителями сетевого оборудования.

Libpcap “снаружи”

Немного усложним задачу. Что, если ваше устройство доступа – аппаратный маршрутизатор другого производителя? Например, D-Link, ASUS, Trendnet и т.д. На нем, скорее всего, невозможно поставить дополнительное программное средство съема данных. Как вариант – интеллектуальное устройство доступа у вас есть, но настроить его не представляется возможным (нет прав, или оно управляется вашим провайдером). В таком случае можно собирать информацию о трафике непосредственно в точке стыка устройства доступа с внутренней сетью, пользуясь «аппаратными» средствами копирования пакетов. В таком случае непременно потребуется отдельно стоящий сервер с выделенной сетевой картой для приема копий Ethernet-пакетов.
Сервер должен использовать механизм сбора пакетов по методу libpcap, описанному выше, и наша задача — на вход выделенной для этого сетевой карты подать поток данных, идентичный выходящему из сервера доступа. Для этого можно использовать:

• Ethernet – хаб (hub): устройство, просто пересылающее пакеты между всеми своими портами без разбора. В современных реалиях его можно найти где-нибудь на пыльном складе, и применять такой метод не рекомендуется: ненадежно, низкая скорость (хабов на скорости 1 Гбит/с не бывает)
• Ethernet – коммутатор с возможностью зеркалирования (мирроринга, SPAN портов. Современные интеллектуальные (и дорогие) коммутаторы позволяют копировать на указанный порт весь трафик (входящий, выходящий, оба) другого физического интерфейса, VLANа, в том числе удаленного (RSPAN)
• Аппаратный раздвоитель, который может потребовать установки для сбора двух сетевых карт вместо одной – и это помимо основной, системной.

Естественно, вы можете настроить SPAN-порт и на самом устройстве доступа (маршрутизаторе), если оно это позволяет – Cisco Catalyst 6500, Cisco ASA. Вот пример такой конфигурации для коммутатора Cisco:
monitor session 1 source vlan 100 ! откуда берем пакеты
monitor session 1 destination interface Gi6/3! куда выдаем пакеты

SNMP

Что, если маршрутизатора под нашим контролем нет, с netflow связываться нет желания, нас не интересуют детали трафика наших пользователей. Они просто подключены в сеть через управляемый коммутатор, и нам надо просто грубо оценить объем трафика, приходящегося на каждый из его портов. Как вы знаете, сетевые устройства с возможностью удаленного управления поддерживают, и могут отобразить счетчики пакетов (байт), проходящих через сетевые интерфейсы. Для их опроса правильно будет использовать стандартизованный протокол удаленного управления SNMP. При помощи его можно достаточно просто получить не только значения указанных счетчиков, но также другие параметры, такие как имя и описание интерфейса, видимые через него MAC-адреса, и другую полезную информацию. Это делается как утилитами командной строки (snmpwalk), графическими SNMP-браузерами, так и более сложными программами мониторинга сети (rrdtools, cacti, zabbix, whats up gold и т.д.). Однако, данный метод имеет два существенных недостатка:

• блокировка трафика может производиться только путем полного отключения интерфейса, при помощи того же SNMP
• счетчики трафика, снимаемые по SNMP, относятся к сумме длин Ethernet-пакетов (причем unicast, broadcast и multicast по-отдельности), в то время как остальные описанные ранее средства дают величины относительно IP-пакетов. Это создает заметное расхождение (особенно на коротких пакетах) из-за оверхеда, вызванного длиной Ethernet-заголовка (впрочем, с этим можно приближенно бороться: L3_байт = L2_байт — L2_пакетов*38).

VPN

Отдельно стоит рассмотреть случай доступа пользователей к сети путем явного установления соединения к серверу доступа. Классическим примером может служить старый добрый dial-up, аналогом которого в современном мире являются VPN-службы удаленного доступа (PPTP, PPPoE, L2TP, OpenVPN, IPSEC)

Устройство доступа не только маршрутизирует IP-трафик пользователей, но также представляет из себя специализированный VPN-сервер, и терминирует логические туннели (часто зашифрованные), внутри которых передается пользовательский трафик.
Для учета такого трафика можно пользоваться как всеми средствами, описанными выше (и для глубокого анализа по портам/протоколам они хорошо подходят), так и дополнительными механизмами, которые предоставляют средства управления VPN-доступом. В первую очередь речь пойдет о протоколе RADIUS. Его работа – достаточно сложная тема. Мы же кратко упомянем, что контролем (авторизацией) доступа к VPN-серверу (RADIUS-клиенту) управляет специальное приложение (RADIUS-сервер), имеющее за собой базу (текстовый файл, SQL, Active Directory) допустимых пользователей с их атрибутами (ограничения по скорости подключения, назначенные IP-адреса). Помимо процесса авторизации, клиент периодически передает серверу сообщения аккаунтинга, информацию о состоянии каждой текущей работающей VPN-сессии, в том числе счетчики переданных байт и пакетов.

Заключение

Сведем все описанные выше методы сбора информации о трафике воедино:

Подведем небольшой итог. На практике существует большое количество методов присоединения управляемой вами сети (с клиентами или офисными абонентами) к внешней сетевой инфраструктуре, с использованием ряда средств доступа – программных и аппаратных маршрутизаторов, коммутаторов, VPN-серверов. Однако практически в любом случае можно придумать схему, когда информация о переданном по сети трафике может быть направлена на программное или аппаратное средство его анализа и управления. Возможно также, что это средство позволит осуществлять обратную связь с устройством доступа, применяя интеллектуальные алгоритмы ограничения доступа для отдельных клиентов, протоколов и прочего.
На этом закончу разбор матчасти. Из неразобранных тем остались:

• как и куда попадают собранные данные о трафике
• программное обеспечение для учета трафика
• чем отличается биллинг от простой “считалки”
• как можно накладывать ограничение на трафик
• учёт и ограничение посещенных веб-сайтов