Принципы маршрутизации и преобразования IP-трафика в VPN-сети, созданной с использованием технологии ViPNet. Общие принципы взаимодействия узлов ViPNet в виртуальной сети

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

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

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

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

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

Для передачи 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 портов пакетов трафика, заменяя внутренние (не маршрутизируемые в Интернете) адреса согласно своей динамической таблице трансляции. В такой конфигурации необходимо помнить, что для корректного учета данных по внутренним хостам сети съём статистики должен производиться способом и в том месте, где результат трансляции ещё не «обезличивает» внутренние адреса.

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

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

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

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

Libpcap

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

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

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

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

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

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

Netflow

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


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

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

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

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

VPN

Заключение

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

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

Передача IP трафика по сетям SDH, или Есть ли у ATM альтернатива?

Немало спорят о том, какие транспортные технологии выйдут на первый план в высокоскоростных мультимедийных сетях, например Internet. И хотя большинство спорящих отдают свои голоса в пользу ATM, с этой точкой зрения согласны далеко не все. Возможен и другой, альтернативный, вариант построения транспортных мультимедийных сетей - использование протокола IP (Internet Protocol) с прямой инкапсуляцией в сети синхронной цифровой иерархии (SDH).

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

Для увеличения пропускной способности Internet прежде всего необходим высокоскоростной "транспорт". Один из вариантов - использование популярной технологии ATM. Следует отметить, что в качестве транспортного протокола ATM вызывает все больше нареканий как у производителей оборудования, так и у конечных пользователей. Мы постараемся проанализировать недостатки ATM более подробно и рассмотреть аргументы в пользу другого способа передачи трафика Internet - прямой инкапсуляции протоколов TCP/IP в протоколы SONET/SDH.

Технология ATM

Асинхронный режим передачи, ATM, был представлен на суд производителей и провайдеров сетевых услуг как технология, позволяющая обеспечить необходимую полосу пропускания по требованию и гарантированное качество обслуживания широкому спектру мультимедийных приложений, среди которых на первом месте находился Internet. Таким образом, не самая последняя часть компонентов ATM была ориентирована и разрабатывалась специально для передачи трафика Internet. Предполагалось, что в ближайшем будущем Сеть будет в значительной степени состоять из пользователей ATM и клиентов LANE (LAN Emulation), что обеспечит легкую и естественную миграцию Internet-приложений в новый транспортный протокол, обещающий безграничные возможности.

Однако (возможно, из-за дороговизны новых решений или их неорганичности) этого почему-то не произошло. Более того, все отчетливее стала проявляться тенденция к усилению влияния протоколов TCP/IP именно как транспортных протоколов.

Действительно, стек протоколов TCP/IP давно отработан и испытан, в его создание и отладку вложено немало средств и сил. Если у протокола IPv4 и есть определенные недостатки, то готовящаяся к выходу версия IPv6 позволит устранить большинство из них. Впрочем, существующая версия IPv4 тоже устраивает очень многих и, по мнению экспертов, в состоянии продержаться еще несколько лет. Изрядное число производителей рассматривает именно IP как перспективный транспортный протокол для современной телекоммуникационной инфраструктуры. Так при чем же здесь ATM?

ATM была предложена ITU-T как базовая технология для широкополосного ISDN (или B-ISDN). Поскольку B-ISDN предназначен в основном для передачи мультимедийного трафика, ATM имела все возможности для поддержки такого рода трафика в реальных сетях.

Прошло некоторое время, и производители телекоммуникационного оборудования обратили на ATM свое внимание. Был создан ATM Forum, который занялся воплощением новой технологии в жизнь. При этом задачи, возлагаемые на ATM Forum, состояли в стандартизации и разработке эффективного наращиваемого протокола, поддерживающего трафик с диаметрально противоположными характеристиками (мультимедиа), гарантирующего определенное качество обслуживания (QoS) и поддерживающего многоадресное вещание. Кроме того, данный протокол должен быть совместимым с существующими технологиями LAN и WAN.

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

Технология IP

IP, с другой стороны, совсем не выглядит устаревающим протоколом, о котором следует забыть. По всему миру установлено огромное число решений типа "IP over Ethernet", и совсем непросто уговорить клиентов выбросить дешевые "карточки" Ethernet и установить адаптеры ATM, не обещая при этом принципиально новых возможностей или хотя бы более высоких скоростей (увеличение скорости отнюдь не является очевидным).

Думаю, многие клиенты, имеющие опыт использования адаптеров ATM для персональных компьютеров, согласятся со мной, что сетевая карта Fast Ethernet 100 Мбит/с (не говоря уже про Full Duplex) работает по крайней мере не медленнее, чем адаптер ATM на 155 Мбит/с. Это связано с большей избыточностью протокола ATM и задержками на сборку/разборку ячеек. Что же касается гарантированного качества обслуживания ATM, оно практически не реализовано в LANE, да и для передачи IP-трафика через ATM сейчас используется AAL5 UBR (максимум UBR+ или ABR). Так что говорить о QoS не приходится.

Несомненно, новая технология должна поддерживать широкий диапазон уровней качества обслуживания. Однако IP был выбран в качестве протокола для всеобщего межсетевого взаимодействия и прекрасно работал в Internet, насчитывавшем тогда 20 тыс. компьютеров, уже в середине 1980 г. и продолжает успешно соединять несколько миллионов хостов сегодня. Действительно ли IP изжил себя? Сторонники ATM, вероятно, ответят "да".

Огромные средства были вложены в разработку семейства Internet-протоколов и доведение их до нынешнего состояния. Действует не только ATM Forum, но и IETF (Internet Engineering Task Force) - продолжается поиск путей для применения IP в появляющихся высокоскоростных мультимедийных сетях. Созданы протоколы поддержки многоадресного вещания (IGMP, DVMRP, PIM) и протоколы, обеспечивающие резервирование ресурсов для передачи трафика (RSVP). Имеется возможность осуществлять маршрутизацию (правда, пока еще не так гибко, как при использовании PNNI) на основе требуемого качества обслуживания (Tag Switching), а готовящийся к выходу в IETF стандарт MPLS (Multiprotocol Label Switching) обеспечит интероперабельность всех устройств, поддерживающих коммутацию меток, и, вероятно, ощутимо потеснит позиции MPOA (Multiprotocol Over ATM).

Так имеет ли смысл заменять хорошо проработанную технологию IP на только появляющуюся ATM ?

IP через ATM

Первоначально идея передачи IP через ATM рассматривалась как возможный путь внедрения ATM в существующую архитектуру Internet с последующим полным вытеснением IP. Теперь, понимая, что ATM не в состоянии полностью заменить IP, мы можем задать вопрос: почему же до сих пор не созданы эффективные методы передачи трафика IP через ATM? Видимо, считается, что ATM предлагает уникальную технологию быстрой коммутации, способную решить существующие проблемы нехватки пропускной способности в Internet. Однако на деле здесь проявляются некоторые проблемы.

Прежде всего обратим внимание на то, что практически все (за редким исключением, например ATM25, TAXI и т.п.) физические интерфейсы ATM-коммутаторов работают в формате кадров SDH/SONET/PDH. Это сделано для облегчения интеграции с широко распространенными транспортными сетями SDH. Но даже когда SDH напрочь отсутствует и не предусмотрен проектом, все равно в передачу пользовательского трафика вносится SDH overhead, что, мягко говоря, не увеличивает скорость и производительность сети.

Уместно также будет отметить, что SDH - синхронный метод передачи, а ATM - асинхронный. При передаче ATM-трафика через транспортные сети SDH мы теряем все преимущества асинхронного метода переноса ячеек, не говоря уже о дублировании ряда функций (например, OA&M).

Улучшению ситуации отнюдь не способствует инкапсуляция IP в ATM, в свою очередь работающий через SDH. Протокол ATM является ориентированным на соединение, в то время как IP таковым не является. Это несоответствие также ведет к дополнительному усложнению и дублированию ряда функций.

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

На недостатках методов эмуляции локальных сетей даже нет нужды останавливаться, поскольку любой квалифицированный сетевой специалист согласится, что технологию LANE никак нельзя назвать органичной и перспективной. Со многих точек зрения эта технология - неудачная попытка "притянуть" протоколы, разработанные для сред с широковещательной рассылкой, к работе в среде, где подобный режим передачи данных невозможен (NBMA, Nonbroadcast Multiple Access).

Таким образом, если Internet все-таки остается самим собой и продолжает базироваться на IP, нужна ли дополнительная "прослойка" в виде ATM между IP и действительно эффективным, действительно высокоскоростным транспортным проколом SDH, который одинаково хорошо служит для передачи трафика практически любого вида?

IP через SDH

Технология SDH широко используется для организации надежного транспорта. SDH была разработана для того, чтобы получить стандартный протокол для взаимодействия провайдеров; унифицировать американские, европейские и японские цифровые системы; обеспечить мультиплексирование цифровых сигналов на гигабитных скоростях; обеспечить поддержку функций эксплуатации и технического обслуживания OA&M (operation, administration and maintenance).

Хотя SDH и работает с кадрами и имеет свою канальную структуру, с точки зрения сетевого уровня SDH - всего лишь поток октетов. Для того чтобы корректно вложить пакет IP в SDH-контейнер, необходимо четко определить границы пакета (или группы пакетов) в рамках синхронного транспортного модуля STM (synchronous transport module). Иными словами, между IP и SDH нужна некоторая протокольная "прослойка" для формирования кадров канального уровня.

Поскольку SDH предоставляет соединения типа точка-точка, применение в качестве промежуточного протокола PPP (Point-to-Point Protocol) представляется вполне логичным. PPP широко используется в Internet в качестве протокола канального уровня для организации соединений через глобальные сети. Кроме того, PPP позволяет задействовать дополнительные функции PPP-протокола:

• возможность многопротокольной инкапсуляции;
• защиту от ошибок;
• использование протокола LCP для установления, конфигурирования и тестирования соединений канального уровня;
• возможность применения семейства протоколов NCP для поддержки и конфигурирования различных сетевых протоколов.

Впрочем, надо отметить, что в качестве сетевого протокола для нас сейчас представляет интерес только IP, а кроме того, ряд функций протокола NCP (например, динамическое присвоение IP-адресов) в нашем случае не актуален. Что нас действительно интересует, так это инкапсуляция IP в PPP с последующим размещением PPP-кадров в SDH.

Инкапсуляция IP в PPP не представляет проблемы, поскольку хорошо отработана и повсеместно используется. Процедура инкапсуляции PPP в SDH (определено значение Path Signal Label = 207hex), показанная на рисунке, должна осуществляться специальным сервис-адаптером на уровне тракта SDH. Сервис-адаптер может представлять собой "черный ящик", принимающий поток PPP-кадров и "выдающий" поток транспортных модулей STM. PPP весьма удачно подходит для работы с SDH, так как оба протокола ориентированы на работу в однобайтном режиме.

Таким образом, используя непосредственную инкапсуляцию трафика Internet в существующую транспортную службу SDH, мы существенно упрощаем сложную сетевую инфраструктуру, а тем самым уменьшаем ее стоимость и увеличиваем эффективную пропускную способность. С появлением новых возможностей передачи IP-трафика на гигабитных скоростях (Gigabit Ethernet) и технологий быстрой коммутации IP-пакетов (Multiprotocol Label Switching - MPLS) становится реальным использование именно IP-протокола как основы единой транспортной службы для передачи видео, телефонии и других мультимедийных приложений - благо основная часть работ по внедрению протокола IP во Всемирную сеть уже выполнена. В связи с этим очень своевременным кажется появление стандартов (RFC 1619) и первых практических реализаций интерфейсов типа "PPP over SDH" (или Packets Over Sonet - POS) на предназначенных для Internet современных маршрутизаторах, в частности GSR 12000 от Cisco Systems.

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

ОБ АВТОРЕ

Посмотрело: 3498

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

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

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

• Внешние ресурсы - сеть Интернет, со всеми сайтами, серверами, адресами и прочим, что не принадлежит сети, которую вы контролируете.


• Устройство доступа - маршрутизатор (аппаратный, или на базе PC), коммутатор, VPN-сервер или концентратор.


• Внутренние ресурсы - набор компьютеров, подсетей, абонентов, работу которых в сети необходимо учитывать или контролировать.


• Сервер управления или учёта - устройство, на котором работает специализированное программное обеспечение. Может быть функционально совмещён с программным маршрутизатором.

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

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

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

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

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

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

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

• перехват (копирование) пакетов, проходящих через сетевую карту сервера, при помощи библиотеки


• перехват пакетов, проходящих через встроенный межсетевой экран


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

Libpcap

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

• открыть необходимый интерфейс


• указать фильтр, через который пропускать принятые пакеты, размер захватываемой части (snaplen), размер буфера,


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


• установить функцию (callback), вызываемую на каждый принятый пакет.

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

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

• Пользовательская программа - обработчик трафика регистрирует себя в системе, используя системный вызов, или библиотеку.


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


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

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

Netflow

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


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

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

Libpcap в“снаружи”

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


• Ethernet - коммутатор с возможностью зеркалирования (мирроринга, . Современные интеллектуальные (и дорогие) коммутаторы позволяют копировать на указанный порт весь трафик (входящий, выходящий, оба) другого физического интерфейса, VLANа, в том числе удаленного (RSPAN)


• Аппаратный , который может потребовать установки для сбора двух сетевых карт вместо одной - и это помимо основной, системной.

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

SNMP

• блокировка трафика может производиться только путем полного отключения интерфейса, при помощи того же SNMP


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

VPN

Заключение

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

• как и куда попадают собранные данные о трафике


• программное обеспечение для учета трафика


• чем отличается биллинг от простой в“считалки”


• как можно накладывать ограничение на трафик


• учёт и ограничение посещенных веб-сайтов

Мировой интернет-трафик вырастет до 1,6 зеттабайта к 2018 году. Ключевыми факторами роста станут распространение видео в формате Ultra-HD/4K и технологий межмашинной связи, включая «умные» автомобили.

По данным исследования Cisco под названием «Индекс развития визуальных сетевых технологий: глобальный прогноз и распространение сервисов за период 2013-2018 гг.» (Cisco VNI), в течение 4 лет мировой IP-трафик практически утроится. Это произойдет за счет роста числа интернет-пользователей и различных устройств, увеличения скоростей ШПД и количества просмотров видео. Как ожидается, к 2018 году годовой объем мирового IP-трафика, проходящего через фиксированные и мобильные соединения, достигнет 1,6 зеттабайта*, т.е. более полутора триллионов гигабайт. Это больше IP-трафика (1,3 зеттабайта), сгенерированного во всем мире за период с 1984 по 2013 гг.

Десятки миллионов болельщиков будут смотреть трансляцию матчей начавшегося чемпионата мира по футболу через Интернет. Потоковое видео и IP-трансляция игр могут сгенерировать 4,3 эксабайта интернет-трафика, что втрое превышает месячный объем трафика в Бразилии. Кроме того, по прогнозам, интернет-трафик, который будут генерировать зрители на каждом стадионе и по пути на матч, превысит средний объем трафика, генерируемого в часы пик** всеми смартфонами, имеющимися в настоящее время у жителей Бразилии.

Как ожидается, к 2018 г. глобальный IP-трафик достигнет 132 эксабайт в месяц. Такой же объем трафика способны сгенерировать:

• потоковое видео в сверхвысоком разрешении (Ultra-HD/4K), если его одновременно передать на 8,8 миллиардов экранов во время финального матча за звание чемпиона мира по футболу;
• 5,5 миллиардов зрителей, которые, пользуясь сервисом «видео по запросу», без перерыва смотрят 4-й сезон «Игр престолов» в высоком разрешении (HD), либо 1,5 миллиарда - в сверхвысоком разрешении;
• 3-й сезон «Карточного домика», передаваемый одновременно на 24 миллиарда экранов в сверхвысоком разрешении;
• 940 квадрильонов текстовых сообщений;
• 4,5 триллиона клипов YouTube.

В ближайшие годы состав IP-трафика кардинально изменится. К 2018 г. большая его часть впервые будет ассоциироваться не с персональными компьютерами, а с другими устройствами. Так же впервые объем Wi-Fi-трафика превысит объем проводного трафика, а объем трафика видео высокого разрешения превзойдет трафик обычного видео.

Всеобъемлющий Интернет также набирает обороты, и к 2018 г. количество модулей межмашинной связи сравняется с количеством людей. Так, на каждый «умный» автомобиль будут приходиться почти 4 соединения.

«В первом такого рода отчете, опубликованном 9 лет назад, мы установили зеттабайт в качестве этапной отметки роста глобального IP-трафика, - напомнил Дуг Уэбстер (Doug Webster), вице-президент компании Cisco по маркетингу продуктов и решений. - Сегодня мы уже живем в эпохе зеттабайта, став свидетелями невероятных отраслевых перемен. Среди основных трендов, выделенных в нынешнем прогнозе и предоставляющих сервис-провайдерам значительные возможности как сегодня, так и в ближайшем будущем, отметим реализацию Всеобъемлющего Интернета, рост спроса на мобильность сетей и появление видео сверхвысокого разрешения».

Прогнозы глобального роста трафика и ключевые факторы распространения сервисов

IP-трафик

За большую часть трафика к 2018 г. будут отвечать мобильные и носимые устройства, без персональных компьютеров. Если в 2013 г. на устройства, отличные от ПК, приходилось 33% IP-трафика, то к 2018 г. их доля вырастет до 57%. Темпы роста трафика ПК составят 10% в год, тогда как для других устройств и соединений этот показатель будет выше: 18% для ТВ, 74% для планшетов, 64% для смартфонов и 84% - для модулей межмашинной связи (M2M).

Трафик в часы пик растет быстрее обычного интернет-трафика. В 2013 г. рост интернет-трафика в час пик составил 32%, тогда как трафик в другое время суток вырос на 25%.

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

IP-видео

К 2018 г. доля IP-видео в общем IP-трафике вырастет до 79% (в 2013 г. она составляла 66%).

Доля видео сверхвысокого разрешения в общем IP-трафике к 2018 г. увеличится на 0,1% по сравнению с 2013 г. и составит 11%. Доля видео высокого разрешения увеличится с 36% в 2013 г. до 52% к 2018 г., а видео стандартного разрешения сократится с 64% до 37% общего IP-трафика.

IP-трафик по типам доступа

К 2018 г. Wi-Fi и мобильные устройства будут генерировать 61% IP-трафика. На долю Wi-Fi придется 49%, на долю сотовых сетей - 12%. Фиксированный трафик к 2018 г. составит лишь 39% общего IP-трафика. Для сравнения: в 2013 г. доля Wi-Fi составляла 41%, сотового трафика - 3%, фиксированного трафика - 56%.

К 2018 г. Wi-Fi и мобильные устройства будут генерировать 76% интернет-трафика. На долю Wi-Fi придется 61%, на долю сотовых сетей - 15%. Фиксированный трафик составит к 2018 г. лишь 24% общего интернет-трафика. Для сравнения: в 2013 г. доля Wi-Fi составляла 55%, сотового трафика - 4%, фиксированного трафика - 41%.

Устройства и соединения

К 2018 г. на каждого жителя нашей планеты будет приходиться в среднем 2,7 сетевых устройства или соединения. В 2013 г. этот показатель составлял 1,7 на душу населения.

Общемировое число межмашинных соединений составит 7,3 миллиарда, или почти одно соединение на человека (если исходить из того, что к 2018 г. население Земли составит 7,6 миллиардов человек).

Число фиксированных и мобильных устройств с поддержкой IPv6 вырастет с 2 миллиардов в 2013 г. до 10 миллиардов в 2018 г.

Рост скоростей ШПД

Скорость ШПД в мире вырастет с 16 Мбит/с в конце 2013 г. до 42 Мбит/с к 2018 г.

Скорость большинства (примерно 55%) широкополосных соединений к 2018 г. превысит 10 Мбит/с. В Японии и Южной Корее средняя скорость ШПД к 2018 г. приблизится к 100 Мбит/с.

Распространение передовых сервисов

Самым быстрорастущим сервисом в жилом секторе станет онлайн-видео: при 10-процентном среднегодовом приросте за период 2013-2018 гг. число пользователей увеличится с 1,2 до 1,9 миллиарда человек.

В потребительском сегменте быстрее всего будут расти мобильные сервисы с учетом местоположения: при 36-процентном среднегодовом приросте за период 2013-2018 гг. число пользователей таких услуг вырастет с 236 миллионов до более миллиарда человек.

В бизнес-сегменте самым быстрорастущим интернет-сервисом станет проведение видеоконференций с использованием персональных устройств и настольных компьютеров: при 45-процентном среднегодовом приросте за период 2013-2018 гг. число пользователей вырастет с 37 миллионов до 238 миллионов человек.

Прогнозы по странам и регионам

К 2018 г. самый большой объем IP-трафика - 47,7 эксабайт в месяц - будет генерироваться в Азиатско-Тихоокеанском регионе. Этот самый густонаселенный регион мира, на который приходится большинство устройств и соединений, сохранит первое место по объемам трафика в течение всего 2018 года.

На Ближнем Востоке и в Африке в период 2013-2018 гг. сохранятся самые высокие темпы роста IP-трафика (пятикратное увеличение при 38-процентном среднегодовом приросте).

К 2018 г. странами, генерирующими наибольшие объемы трафика, станут США и Китай (соответственно, 37 и 18 эксабайтов в месяц).

Самый быстрый рост IP-трафика в период 2013-2018 гг. будет наблюдаться в Индии и Индонезии (соответственно, 39-процентный и 37-процентный среднегодовой прирост).

Что из всего этого следует для сервис-провайдеров

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

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

Продолжающееся распространение в бизнес-сегменте таких сервисов, как видеоконференции высокого разрешения и веб-видеоконференции, а также бизнес-видео по запросу, может стимулировать усиление роста виртуализации сетей и применения Интернета для передачи видео, что вызовет определенные проблемы как для сервис-провайдеров, так и для независимых поставщиков услуг (over-the-top providers, OTT).

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

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

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

... Брандмауэр также имеет IP фильтр, который может остановить известные злонамеренные IP адреса, которые попытаются получить доступ к вашим данным. ... Также брандмауэр может остановить нежелательный трафик от проникновения. ... Такое программное обеспечение вы с легкостью можете приобрести, установить и использовать. ... Сегодня большинство антивирусных программ могут быть куплены онлайн, и...

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

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

... Этот адрес называется IP . ... Но что такое IP-адрес? ... IP-адрес - 4-байтовое (32-разрядное) число, задающее уникальный номер компьютеру пользователя в Интернете. ... Если брандмауэр опознаёт пакет данных и его IP-адрес, то он позволяет этим данным «пройти». ... Брандмауэр просматривает весь трафик на наличие вирусов любого вида: - spyware (шпионящее ПО); - вредоносного программного...

... Брандмауэр с поддержкой режима обследования осмотрит каждое состояние соединения, обеспечив более высокую производительность и понизив злоумышленный трафик . ... В основном, беспроводной маршрутизатор используется для распределения сетевого трафика между сетью и Интернетом. ... Проверьте также URL, IP и МАК адреса в опциях фильтра.

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

... Пользователи iPod , чьи музыкальные файлы были потеряны в результате поломки компьютера, смогут восстановить их на компьютере со своего iPod. ... Когда вы разговариваете посредством своего компьютера, то вы общаетесь на IP-сети, которая отправляет и получает весь Интернет-трафик . ... Бизнес: Если вы являетесь менеджером компании-поставщика компьютерных услуг, то в ваши задачи входит...

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