Обработка входящего трафика что это
Контроль трафика в локальной сети: особенности и рекомендации
Практические рекомендации по контролю сетевого трафика в компаниях и организациях. Для чего нужен мониторинг и отслеживание трафика? Как лучше всего реализовать? Boodet.online.
Контроль интернет-трафика в сети
Если не контролировать интернет-трафик в рабочей сети, часть пользователей обязательно воспользуется этим в личных целях. Периодически отвлекаться во время работы — это физиологическая потребность организма. Проблема в том, что не всегда работники выбирают для этого маломощные ресурсы. Даже посмотрев небольшой видеоролик, можно существенно увеличить нагрузку на рабочую сеть, если это видео в HD. Эта нагрузка может оказаться критичной, если в соседнем отделе выгружают отчеты в 1С или бэкап, деплоят приложение.
Контролировать трафик в сети нужно обязательно. Обычно этим занимается системный администратор. Специалисты Boodet.Online расскажут, как отслеживать и мониторить трафик в локальной сети.
Для чего это нужно?
Зачем контролировать трафик в корпоративной сети? Даже если компания подключена к корпоративному тарифу, нецелевое использование интернета может нанести ущерб бизнесу.
Основные причины ограничений:
снижение пропускной способности канала;
эффективное использование рабочего времени;
обеспечение безопасности корпоративной информации;
снижение вероятности простоя сетевых сервисов.
Администрировать активность пользователей можно с помощью специализированных сервисов и программ. Несмотря на обилие сервисов, контроль трафика — это сложная комплексная задача. Если ее не решить, то даже кратковременная остановка сети спровоцирует серьезные финансовые потери для бизнеса. Потери для государственных организаций могут быть намного серьезнее — вплоть до утраты критически важных данных.
BGP: некоторые особенности поведения трафика
В этой небольшой заметки хочу коснуться некоторых интересных моментов и особенностей управления трафиком (или попыток управления трафиком) в случае использования протокола BGP. Статья не даст ответ на вопрос о том, как сделать счастье в сети!
Изложенная информация носит познавательный характер и будет похожа на легкое чтиво для специалистов в области телекоммуникаций. Сведения будут изложены в достаточно свободной форме, без излишнего насыщения спецификой. Попробуем ответить на вопрос: «почему трафика нет там, где он должен быть, и есть там, где быть его не должно».
Мы не будем рассматривать назначение протокола BGP со всеми вытекающими последствиями, а сразу возьмем быка за рога.
Исходные данные
Начнем с того, что мы имеем собственную автономную систему, делегированный блок(-и) адресов и одного провайдера. В данном случае связь нашей AS с сетью Интернет осуществляется используя один единственный канал с провайдером. Трафик в нашу сеть (к нашим префиксам) пройдет через этот логический канал, второго мнения тут быть не может. Аналогично с входящим трафиком, весь исходящий трафик пойдет через единственный существующий канал.
Ситуация с резервированием канала может иметь два основным сценария:
1) имеется основной канал емкостью 1Гбит. Резервный (только на случай резерва) покупается значительно меньшей пропускной способность — например, 100 Мбит. В этом случае стоит осознавать последствия выхода из строя основного канал — конца света не наступит, но клиенты ощутят перемены;
2) резервный канал покупается аналогичной (или близкой к тому) пропускной способность. Такой канал получается не совсем дешевый и очень не хочется что бы он простаивал. Тут администратор начинает шаманить с разными балансировками.
Природно, что сетевой администратор хочет абсолютно точно понимать как трафик входит/выходит/проходит через его сеть. А бы даже сказал — его автономную систему. Так вот, в этом можно на 100% быть уверенным только в том случае, если используется один провайдер. Если провайдеров несколько, то понимание о трафике в сети перерастает в предположения о трафике в сети. И вот почему.
В рукаве администратора несколько механизмом влияния на информационные потоки (local preference, weight, med, as-path, etc.), но на сколько они эффективны? Скажу, что они достаточно эффективны (кто-бы сомневался), но не до конца. Ниже приведу парочку интересных примеров.
1. Исходящий трафик
Предположим что от двух провайдеров мы получаем Full View. Первый провайдер у нас будет основной, второй — резервный. Определяем политику обработки анонсов от провайдера: устанавливаем на префиксы, полученные от первого провайдера, больший local preference (как вариант) чем на префиксы, полученный от второго провайдера.
Рис. 1 
В итоге весь исходящий трафик должен пойти по основному каналу. Визуализируем логические каналы (например с помощью Cacti Weathermap) и наблюдаем странную картину: трафик уходит не только через основной канал, но и через резервный. Как же так?
Все дело в том, что один Full View другому — рознь. Посмотрим на то, что мы получаем от провайдеров, в частности, на количество получаемых префиксов PfxRcd (пример взят с реального маршрутизатора):
#sh ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
X.X.X.X 4 AAAAA 3582179 106997 96854566 0 0 4w6d 392986
Y.Y.Y.Y 4 BBBBB 772880 508161 96854556 0 0 6d02h 400394
Сессия с оборудованием X.X.X.X (AS-AAAAA) — основная.
Видим разницу в количестве в 8000 префиксов. Это означает, что если мы будет запрашивать ресурсы, находящиеся в этих 8000 сетях, то будет использоваться резервный канал. Почему так получается? Обратив внимание на эти префиксы (дельту) я заметил, что и от основного провайдера я их получаю, но в агрегированном виде. Имеется ввиду, что вместо 4*/24 мы получаем 1*/22. Кто делает эту сумаризацию? Тяжело сказать, наверное, кто-то из upstream’ов.
Небольшой подитог: даже исходящий трафик способен вытекать тудой, кудой мы не ожидаем.
2. Входящий трафик
В этом случае все с одной стороны проще, с другой сложнее.
Каким образом мы можем влиять на поведение входящего трафика? Классика — искуственно удлинять AS-PATH (prepend), отправлять анонсы провайдеру с некоторыми communities для занижения провайдерского local preference (сражу скажу, что такую возможность предоставляют не все провайдеры, а у некоторых, достаточно не маленьких, даже нет looking-glass. В таком случае коллеги звонят провайдеру и дежурный администратор в телефонном режиме рассказывает какие префиксы он «видит» и с какими атрибутами) и другие значительно менее эффективные методы.
Но как бы мы не старались, в большей мере все зависит от политик провайдера. И если с балансировкой/нагрузкой исходящего трафика все более менее хорошо, то входящий трафик мы будем получать в оба канал, причем в достаточно непредсказуемом соотношении.
Например. Наша AS-A имеет связи с двумя провайдерами: AS-B (основной) и AS-C (резервный). Свои сети мы анонсируем обоим провайдерам, но в сторону резервного мы специально удлиняем AS-PATH (хотим получить трафик в этот канал только при неисправностях с основным).
Рис. 2 
Резервный провайдер получает анонсы о наших сетях из двух источников: непосредственно от клиента (от нас) и от своих пиринговых партнеров (пунктирная линия). Во многих случаях приходится сталкиваться с тем, что провайдер считает более приоритетным путем в клиентскую сеть тот путь, который непосредственно соединяет его с клиентом. Для этого он (резервный провайдер) увеличивает значения local preference на анонсы, полученные непосредственно от клиента (в данном случае 200), а не от пира (в данном случае 100). Всем своим соседям он расскажет именно об удлиненном пути (анонсах полученных от клиента), так как BGP маршрутизатор анонсирует дальше только лучший маршрут.
Значит, если трафик будет проходить через автономную сеть провайдера AS-B, то получать мы его будем в основной канал, если через сеть провайдера AS-C — в резервный. В итоге, хотим мы того или нет, но входящий трафик к нам будет «заходить» с обоих каналов. В добавок мы получаем ассиметрию: всячески пытаемся отправить трафик в основной канал, а получаем его и с основного, и с резервного.
Небольшой подитог: при двух и более провайдерах, трафик будет «литься» со всех сторон.
3. Иногда, даже порядок установки сессий играет роль
1. Рассмотрим пример.
Рис. 3 
Наша сеть (AS-A) связана с провайдером (AS-B). AS-C, AS-D — другие провайдеры, AS-E — такой-же клиент как и мы. Зеленой стрелкой показано распостранение маршрутной информации, синей — входящий трафик.
2. И тут мы решаем установить связь с AS-E (это наш партнер, не провайдер). Суть связи не в организации дополнительного канала, а в обеспечении резервирования — страховки друг друга. По умолчанию, линк должен быть не нагружен. При возникновении аварий, одна AS подстраховывает другую.
Для этого мы устанавливаем политику на исходящие анонсы в сторону партнера, а именно удлиняем AS-PATH. Для партнерской сети этот анонс не является лучшим, поэтому дальше AS-E его не распространяется.
Рис. 4 
3. Но так случилось, что наша сессия с основным провайдером порвалась (или это мы тестировали). В таком случае происходит: красные стрелки — распостранение удлиненного маршрута, синие стрелки — путь трафика в сеть.
Рис. 5 
И тоже все в порядке.
Сессия с основным провайдером поднимается. Следует отметить, что провайдер AS-D — это тот случай о котором мы говорили ранее (для клиентов устанавливают повышенный local preference), остальные провайдеры такого не делают, то есть выбор пути основывается на AS-PATH.
4. AS-B принимает анонс от AS-A. Анонс без prepend, стало быть этот путь теперь лучший, и именно он анонсируется далее.
Рис. 6 
Видим как далее распостраняется анонс и меняются источники трафика:
Рис. 7 
5. В конце концов информация о доступности собственных префиксов AS-A доходит до AS-D. Для этой автономной системы такой путь считается менее приемлемым, так как ранее на обновления от клиента (от AS-E) были установлены более высокие local preference. Итогом этих процессов является такое установившееся состояние:
Рис. 8 
Прошу обратить внимание на рис. 4 и рис. 8. Как видно, характер входящего трафика существенно меняется. В этом случае наш резервный канал стал если не основным, то далеко не резервным. Как исправить ситуацию? Для возвращения на круги своя можно положить/поднять сессию с партнером (AS-E), но метод далеко не научный.
Небольшой подитог: я хотел продемонстрировать, что иногда даже порядок установки сессий играет роль и влияет на характер трафика. Можно сказать, что случай слегка надуманный, но взят он из реальной жизни и имеет место быть.
Управления трафиком используя протокол BGP и маршрутизация между автономными системами — комплексный и интересный процесс. Количество факторов, влияющих на информационные потоки, даже больше, чем нам может показаться.
Трафик клиентов | 5 шагов для создания непрерывного потока
Не секрет, что для процветания любой компании, важно обеспечить постоянный приток новых покупателей. Пока ваши конкуренты вкладываются в дорогую рекламу и тратят бюджет компании, мы советуем пересмотреть работу вашей системы лидогенерации. Эксперт № 1 по маркетингу Игорь Манн рассказывает о пяти шагах, которые помогут увеличить трафик клиентов в несколько раз.
Еще больше идей для роста выручки можно получить на наших авторских бесплатных вебинарах от компании Ой-Ли. Регистрируйтесь прямо сейчас.
Хотите создать бесконечный трафик потенциальных клиентов?
Прежде чем говорить о способах привлечения новых покпателей, давайте разберемся, что такое лидогенерация с точки зрения маркетинга. Это обеспечение непрерывного трафика заинтересованных клиентов. Соответственно лид — это потенциальный клиент с контактами.
Чтобы создать трафик новых покупателей используйте 5 шагов.
Трафик клиентов: Целевая аудитория
Прежде чем начать привлекать новых покупателей, вы должны четко осознать, кто является клиентом именно вашей компании. Вам нужно определить свою целевую аудиторию. Как только вы составите ее портрет, менеджеру по продажам сразу станет понятно, какой вопрос можно задать покупателю, чтобы выявить его потребности и правильно подать коммерческое предложение. Например, если ваша аудитория – это клиенты старше 50 лет, предложение для них должно быть написано, как минимум, 14 размером шрифта. Потому что у большинства людей в этом возрасте зрение снижено.
Понять, кто ваш целевой клиент, можно двумя способами:
По науке
В любом учебнике по маркетингу предлагается провести огромное количество исследований, исходя из уровня доходов, проживания, образования, пола и многого другого. Это весьма сложно, такой метод в основном используют крупные компании с большим отделом маркетинга.
Как сделать так, чтобы данный процесс был максимально практичным и простым? Один из наиболее удобных способов — создать фотоколлаж. Одна картинка может заменить около 100 слов. Например, для женского журнала коллаж может включать: белый воротничок, стиральную машину, домашних животных, блюда. Тогда вы сможете достаточно точно объяснить менеджерам, кто ваш целевой клиент и, таким образом, визуализировать свою аудиторию.
Интуитивно
Используйте метод от обратного: отбросьте «плохих» покупателей. Формула для определения ваших клиентов = все – «плохие».
Кто такие «плохие» покупатели? Это те, кто:
Они не приносят ничего кроме негатива. Помните, что плохого обязательно заменит хороший, с которым будет приятно работать и который принесет прибыль.
Трафик клиентов: инструменты привлечения покупателей
Принципы организации учёта IP-трафика
Любой администратор рано или поздно получает инструкцию от руководства: «посчитать, кто ходит в сеть, и сколько качает». Для провайдеров она дополняется задачами «пустить кого надо, взять оплату, ограничить доступ». Что считать? Как? Где? Отрывочных сведений много, они не структурированы. Избавим начинающего админа от утомительных поисков, снабдив его общими знаниями, и полезными ссылками на матчасть.
В данной статье я постараюсь описать принципы организации сбора, учёта и контроля трафика в сети. Мы рассмотрим проблематику вопроса, и перечислим возможные способы съема информации с сетевых устройств.
Это первая теоретическая статья из цикла статей, посвящённого сбору, учёту, управлению и биллингу трафика и IT-ресурсов.
Структура доступа в сеть Интернет
В общем случае, структура доступа в сеть выглядит следующим образом:
Сетевой трафик
Для начала необходимо определить, а что же подразумевается под «сетевым трафиком», и какую полезную статистическую информацию можно извлечь из потока пользовательских данных.
Доминирующим протоколом межсетевого взаимодействия пока остается 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-сессия между клиентом и сервером. Она характеризуется постоянным набором параметров . Вместо того, чтобы обрабатывать и хранить информацию попакетно, гораздо удобнее хранить параметры потока (адреса и порты), а также дополнительную информацию – число и сумму длин переданных пакетов в каждую сторону, опционально длительность сессии, индексы интерфейсов маршрутизатора, значение поля ToS и прочее. Такой подход выгоден для ориентированных на соединение протоколов (TCP), где можно явно перехватить момент завершения сессии. Однако и для не ориентированных на сессии протоколов можно проводить агрегацию и логическое завершение записи о потоке по, например, таймауту. Ниже приведена выдержка из SQL-базы собственной системы биллинга, осуществляющей протоколирование информации о потоках трафика:
Необходимо отметить случай, когда устройство доступа осуществляет трансляцию адресов (NAT, маскарадинг) для организации доступа в Интернет компьютеров локальной сети, используя один, внешний, публичный IP-адрес. В этом случае специальный механизм осуществляет подмену IP-адресов и TCP/UDP портов пакетов трафика, заменяя внутренние (не маршрутизируемые в Интернете) адреса согласно своей динамической таблице трансляции. В такой конфигурации необходимо помнить, что для корректного учета данных по внутренним хостам сети съём статистики должен производиться способом и в том месте, где результат трансляции ещё не «обезличивает» внутренние адреса.
Методы сбора информации о трафике/статистике
Снимать и обрабатывать информацию о проходящем трафике можно непосредственно на самом устройстве доступа (ПК-маршрутизатор, VPN-сервер), с этого устройства передавая ее на отдельный сервер (NetFlow, SNMP), или «с провода» (tap, SPAN). Разберем все варианты по-порядку.
ПК-маршрутизатор
Рассмотрим простейший случай – устройство доступа (маршрутизатор) на базе ПК c ОС Linux.
Libpcap
В первом случае копия пакета, проходящего через интерфейс, после прохождения фильтра (man pcap-filter) может быть запрошена клиентской программой на сервере, написанной с использованием данной библиотеки. Пакет поступает вместе с заголовком 2го уровня (Ethernet). Можно ограничить длину захватываемой информации (если нас интересует только информация из его заголовка). Примерами таких программ могут быть tcpdump и Wireshark. Существует реализация libpcap под Windows. В случае применения трансляции адресов на ПК-маршрутизаторе такой перехват можно осуществлять только на его внутреннем интерфейсе, подключенном к локальным пользователям. На внешнем интерфейсе, после трансляции, IP-пакеты не содержат информации о внутренних хостах сети. Однако при таком способе невозможно учесть трафик, создаваемый самим сервером в сети Интернет (что важно, если на нем работают веб– или почтовый сервис).
При передаче пакета через выбранный интерфейс, после прохождения фильтра эта функция получает буфер, содержащий Ethernet, (VLAN), IP и т.д. заголовки, общим размером до snaplen. Поскольку библиотека libcap копирует пакеты, заблокировать их прохождение при ее помощи невозможно. В таком случае программе сбора и обработки трафика придется использовать альтернативные методы, например вызов скрипта для помещения заданного 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 “снаружи”
Отдельно стоит рассмотреть случай доступа пользователей к сети путем явного установления соединения к серверу доступа. Классическим примером может служить старый добрый dial-up, аналогом которого в современном мире являются VPN-службы удаленного доступа (PPTP, PPPoE, L2TP, OpenVPN, IPSEC)
Устройство доступа не только маршрутизирует IP-трафик пользователей, но также представляет из себя специализированный VPN-сервер, и терминирует логические туннели (часто зашифрованные), внутри которых передается пользовательский трафик.
Для учета такого трафика можно пользоваться как всеми средствами, описанными выше (и для глубокого анализа по портам/протоколам они хорошо подходят), так и дополнительными механизмами, которые предоставляют средства управления VPN-доступом. В первую очередь речь пойдет о протоколе RADIUS. Его работа – достаточно сложная тема. Мы же кратко упомянем, что контролем (авторизацией) доступа к VPN-серверу (RADIUS-клиенту) управляет специальное приложение (RADIUS-сервер), имеющее за собой базу (текстовый файл, SQL, Active Directory) допустимых пользователей с их атрибутами (ограничения по скорости подключения, назначенные IP-адреса). Помимо процесса авторизации, клиент периодически передает серверу сообщения аккаунтинга, информацию о состоянии каждой текущей работающей VPN-сессии, в том числе счетчики переданных байт и пакетов.
Заключение
Сведем все описанные выше методы сбора информации о трафике воедино: