Как настроить сеть трафик

Заворачиваем весь трафик локальной сети в vpn без ограничения скорости

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

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

Итак, каковы наши цели:

• пропускать через VPN весь без исключения исходящий трафик
• делать это с максимально возможной скоростью
• не зависеть от временных неполадок VPN-провайдера
• максимум анонимности в Интернете

Подготовка

Нам нужен мощный роутер, способный шифровать трафик на высокой скорости. Он будет выступать в роли VPN-шлюза. Мы нашли замечательные мини-ПК на AliExpress, которые подошли под эту задачу: четырехъядерный Intel Celeron, нативная поддержка AES-CBC, AES-XTS, AES-GCM, AES-ICM и аж четыре RJ-45 порта. И по умолчанию на них была установлена pfSense. С ней и будем работать.

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

Настройка

Статья предполагает, что интернет подключен к первому порту, ваш ПК или домашняя сеть — ко второму, и что до настройки VPN вы смогли выйти в интернет.

Во избежание дальнейших проблем давайте авторизуемся у любимого VPN-провайдера и найдем инструкцию по настройке pfSense. Если ваш провайдер не предоставляет инструкцию по ручной настройке в pfSense, можно воспользоваться вот этой от моего любимого провайдера: www.expressvpn.com/support/vpn-setup/pfsense-with-expressvpn-openvpn — основная суть не изменится. Приведенная статья с картинками расписывает, как полностью настроить только что купленный роутер с pfSense.

Вот краткий чеклист настройки нового VPN-а:

• System — Cert. Manager — CAs. Добавляем сертификат VPN CA
• System — Cert. Manager — Certificates. Добавляем сертификат VPN сервера
• VPN — OpenVPN — Clients. Создаем нового клиента по инструкции от VPN-провайдера
• Interfaces — Assignment. Добавляем клиентов как интерфейсы
• System — Routing. Проверяем что появился шлюз.
• Firewall — NAT. Добавляем правила NAT для каждого клиента
• Firewall — Rules — LAN. Добавляем перенаправление всего трафика из сети через Gateway
• System — Routing. Для активного VPN-a в настройках шлюза указываем Monitor IP, пингом до которого будет проверяться работоспособность VPN-а

Перезагрузка VPN-ов осуществляется в Status — OpenVPN. Просмотр логов в Status — Package Logs — OpenVPN.

На этом этапе останавливаемся и проверяем, что доступ в интернет через VPN есть, и что при отключении от VPN доступ пропадает вовсе. Если интернета нет — где-то ошиблись, смотрим логи VPN, проверяем настройки заново. Если после отключения VPN трафик начинает идти через основной шлюз, значит накосячили в Firewall — Rules — LAN.

Теперь интересная часть. Если ваш провайдер выдает 20 Мбит в секунду, и то ночью — то на этом этапе вы уже получили локальную сеть, полностью закрытую VPN-ом, который работает с максимально возможной скоростью. Но что, если у вас канал пошире?

Масштабируемся

Настраиваем еще пару-тройку VPN клиентов для разных серверов по инструкции выше. Добавлять сертификаты CA и сервера не нужно, выбираем уже добавленные. Также не выполняем шаг с Firewall — Rules — LAN, его мы сделаем позже. Необходимое количество клиентов устанавливается эмпирическим путем по результатам замеров скорости через каждый отдельный сервер.

После того как завершили, у нас должна быть следующая картина:

— В VPN — OpenVPN — Clients созданы и активированы клиенты

— В Interfaces — Assignment созданы и активированы интерфейсы для каждого клиента

— В Status — OpenVPN все клиенты находятся в состоянии «up»

— В System — Routing появились шлюзы, и для них указаны пингуемые IP-адреса.
(Если не можете придумать, кого попинговать — откройте shodan.io и найдите все IP google)

Теперь зайдем в System — Routing — Gateway Groups. Нажмите Add. Укажите запоминающееся имя в Group Name.

Теперь обратите внимание на таблицу Gateway Priority. Группы шлюзов работают следующим образом: failover по уровням, балансировка внутри уровня. Столбец Tier указывает, в каком уровне будет использоваться данный шлюз. Простейший вариант — указываем все активные VPN-шлюзы в первом уровне. Вариант для медленного интернета — создаем двух клиентов и размещаем их на первом и втором уровне, но в этом случае будет только отказоустойчивость.

Ниже найдите Trigger Level. Это условие, при котором произойдет временное исключение шлюза из группы. Варианты кроме Member Down позволяют перестать отправлять пакеты шлюзу чуть раньше, чем он упадет полностью — по превышению порога потери пакетов и/или по высокому пингу. Пороги потерь и пинга задаются для каждого шлюза индивидуально в System — Routing — Gateway.

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

Пришло время направить трафик в новую группу шлюзов. Идем в Firewall — Rules — LAN, открываем созданное ранее правило перенаправления, спускаемся до списка со шлюзами и видим в этом списке созданную нами группу. Выбираем её, сохраняем правило и применяем изменения. Всё, теперь каждое новое соединение будет идти через новый VPN-клиент в группе.

Время тестирования: открываем api.ipify.me, отключаем кэш и keep-alive, и перезагружаем страницу. Если вы единственный пользователь в сети, на каждое обновление страницы вы должны видеть новый IP адрес, отличающийся от вашего домашнего. Если вы видите один и тот же адрес, полностью обновите страницу при помощи Ctrl+F5 (Command+Shift+R на маках), или откройте новую приватную вкладку. Если не помогло — значит где-то ошиблись в настройках группы, или не сменили шлюз в правилах фаерволла.

Теперь о плохом. К сожалению, у данного решения есть небольшой трудноуловимый баг, если использовать его перед роутером локальной сети (а не коммутатором). Рано или поздно у вас отваливается один из VPN-клиентов, срабатывает исключение его из группы, и всё хорошо до того момента, пока VPN не поднимется обратно. Так как все пользователи находятся за NAT, а VPN-роутер видит только один IP-адрес и 65 тысяч портов, со временем он ассоциирует все порты с теми VPN-клиентами, которые никогда не падали. Соответственно, как только VPN-клиент поднимается, через него не идет никакой трафик. Клиент полностью жив, через него идут пинги и некоторое стабильное количество служебного трафика, но через него не идет трафик клиентов. По идее это решалось бы сбросом таблицы соединений, и для этого даже есть галочка в настройках pfSense, но в моих исследованиях эта галочка напрочь блокировала всякий доступ к роутеру, так как клиенты начинали валиться циклично, при этом роняя только-только установленные соединения с веб-интерфейсом, что сильно затрудняло исправление проблемы. Без этой галочки при наличии более двух VPN-ов они уравновешивали себя, так что доступ хотя бы через один всегда был. В конце концов я настроил в мониторинге условие «если пять минут на интерфейсе было меньше 1000 байт трафика в секунду, сообщить мне», и в особо запущенных случаях перезагружаю зомби-VPN-клиента вручную с целью сбросить таблицу соединений.

Итак, мы получили сеть, полностью пропускаемую через несколько распределенных VPN-ов. За счет сочетания нескольких разных VPN-серверов мы не зависим от доступности каждого из них в отдельности, а скорость сети ограничена только вашим каналом за вычетом шифрования. Если вдруг вам не хватит одного роутера — их тоже можно масштабировать, но это тема для отдельной статьи.

Источник

Контроль трафика в локальной сети: особенности и рекомендации

Практические рекомендации по контролю сетевого трафика в компаниях и организациях. Для чего нужен мониторинг и отслеживание трафика? Как лучше всего реализовать? Boodet.online.

Контроль интернет-трафика в сети

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

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

Для чего это нужно?

Зачем контролировать трафик в корпоративной сети? Даже если компания подключена к корпоративному тарифу, нецелевое использование интернета может нанести ущерб бизнесу.

Основные причины ограничений:

снижение пропускной способности канала;

эффективное использование рабочего времени;

обеспечение безопасности корпоративной информации;

снижение вероятности простоя сетевых сервисов.

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

Источник

Принципы организации учёта IP-трафика

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

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

Читайте также:  Как правильно настроить steelseries arctis pro

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! куда выдаем пакеты

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

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

Заключение

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

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

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

Источник