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

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

Забросить shell-код на удаленную машину и застолбить там back-door — это только половина дела. А что делать дальше, мы подумали? Необходимо скрыть свой IP-адрес и обойти все брандмауэры, не оставляя никаких следов в логах, анализируемых как вручную, так и автоматизированными системами определения вторжения. Существует множество утилит, прячущих левые сетевые соединения от глаз администраторов, однако на физическом уровне весь «хакерский» трафик элементарно обнаруживается и пресекается практически любым брандмауэром, чего атакующему допускать ни в коем случае нельзя. В идеале необходимо пробить тоннель, открыв секретный канал связи, не создающий никаких дополнительных соединений и не
генерирующий никакого избыточного трафика, чтобы даже самый строгий разбор дампов, награбленных сетевым анализатором, не выявил ничего подозрительного.

Над решением этой проблемы бились лучшие хакерские умы. Сначала идея получила чисто теоретическое обоснование (Andrew Hintz, Craig Rowland) с чисто лабораторной реализацией, непригодной для практического использования. Затем к делу подключилась Жанна Рутковская, разработавшая специальный протокол с кодовым названием NUSHU и вполне жизнеспособные модули, ориентированные на работу в Linux Kernel 2.4. Жанна вручила нам мощное средство для управления удаленными shell’ами, от которого практически невозможно разработать адекватную защиту. Осталось только разобраться, как этим средством воспользоваться.

Скрытые пассивные каналы: основные концепции

С недавних пор в хакерском лексиконе появилось понятие «скрытых пассивных каналов » (Passive Covert Channels , или сокращенно PCC ). Они представляют собой разновидность обычных скрытых каналов (Covert Channels ), однако, в отличие от последних, не только не устанавливают своих соединений, но и вообще не генерируют никакого собственного трафика! Передача информации осуществляется исключительно путем модификации пакетов, пролетающих мимо атакованного узла.

Соль в том, что эти пакеты направляются не к хакеру, а шуруют своими путями на различные узлы интернета, например, www.google.com, за счет чего достигается высочайшая степень анонимности. Естественно, возникает резонный вопрос: как хакер сможет добраться до содержимого пакетов, идущих мимо него? Для этого необходимо подломать один из промежуточных маршрутизаторов (как правило, принадлежащих провайдеру, обслуживающему атакуемую организацию) и установить на него специальный модуль, анализирующий заголовки TCP/IP-пакетов на предмет наличия скрытой информации или ее внедрения.

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

Рассмотрим схему взаимодействия с целевым узлом (жертвой) по скрытому пассивному каналу. Хакер (обозначенный буквой Х) каким-то совершенно не относящимся к обсуждаемой теме образом забрасывает на целевой узел (обозначенный буквой A) shell-код, захватывающий управление и устанавливающий back-door вместе со специальным модулем, обеспечивающим функционирование PCC-канала. Теперь все TCP/IP-пакеты, отправляемые жертвой во внешний мир, содержат незначительные изменения, кодирующие, например, пароли или другую конфиденциальную информацию.

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

Таким образом, мы получаем защищенный канал A-B и открытый B-X, однако хакеру ничего не стоит общаться с узлом B через анонимный proxy-сервер или даже выстроить цепочку из нескольких защищенных хостов. К тому же, выбор маршрутизатора B необязателен. Главное, чтобы маршрутизатор располагался между целевым узлом А и одним из узлов, с которыми общается жертва.

Во власти протокола IP

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

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

Фишка в том, что PCC-модуль может беспрепятственно модифицировать поле идентификатора по своему вкусу, передавая с каждым IP-пакетом 16 бит полезных данных. Это в теории. На практике же нам потребуется выделить несколько бит для маркировки своих пакетов, иначе PCC-приемник ни за что не сможет отличить их от остальных. Пусть в 12 младших битах передаются полезные данные, а в четырех старших — их контрольная сумма. Тогда PCC-приемнику останется всего лишь взять 12 бит, рассчитать их CRC и сравнить с оставшимися четырьмя битами. Если они совпадут, значит, это наш пакет, если же нет — пускай идет себе лесом.

Также следует позаботиться о нумерации пакетов, поскольку порядок следования IP-пакетов в общем случае не совпадает с порядком их отправки. А для этого также требуются биты, в результате чего реальная информационная емкость IP-заголовка стремится к одному байту, что, в общем-то, не так уж и плохо. Для передачи небольших объемов данных (типа паролей) вполне сойдет. Главное — не забывать о том, что идентификатор должен: а) быть уникальным; б) выглядеть случайным. Поэтому необходимо прибегнуть к скремблированию, то есть к наложению на передаваемый текст некоторой псевдослучайной последовательности данных (известной как PCC-отправителю, так и PCC-получателю) через оператор XOR.

Кроме идентификатора, можно (с некоторой осторожностью) менять поля TTL (Time To Live – максимальное время жизни пакета), тип сервиса (TOS) и протокола (protocol). Однако это слишком заметно и легко обнаруживается просмотром дампов, полученных любым снифером.

Наш извозчик — протокол TCP

При установке TCP-соединения передающая сторона (узел A) устанавливает флаг SYN и выбирает произвольный 32-битный номер последовательности (Sequence Number, или сокращенно SEQ). Если принимающая сторона (узел B) согласна принять узел А в свои объятия, она отправляет ему пакет с установленным флагом ACK и номером подтверждения (Acknowledgment Number), равным SEQ+1, а также генерирует свой собственный номер последовательности, выбираемый случайными образом. Узел A, получив подтверждение, поступает аналогичным образом, что наглядно демонстрирует следующая схема:

узел A —— SYN(ISN) ————> узел B
узел A <—— SYN(ISN+1)/ACK —— узел B
узел A —— ACK —————-> узел B

ISN – это начальный номер последовательности (Initial Sequence Number ), уникальный для каждого TCP/IP-соединения. С момента установки соединения номера последовательности планомерно увеличиваются на количество принятых/отправленных байт. Впрочем, не будем углубляться в теорию. Остановимся на том факте, что 32-битное поле ISN можно изменять псевдослучайным образом, «промодулированным» секретными данными и… никто ничего не заметит! Конечно, пропускная способность упадет до четырех байт на каждое TCP-соединение, устанавливаемое узлом-жертвой, а TCP-соединений устанавливается не так уж и много (особенно если мы имеем дело не с нагруженным сервером, а с рабочей станцией). Тем не менее, для
перекачки паролей и удаленного управления через командную строку даже такой скромной пропускной способности вполне достаточно.

Жанна Рутковская , решив не ограничивать себя лабораторными опытами, разработала протокол NUSHU , создающий скрытые пассивные каналы посредством модификации ISN с последующим шифрованием последнего алгоритмом DES на основе идентификатора IP-пакета (IP.id), порта-источника (TCP.sport) и IP-адреса назначения (IP.daddr).

Сеанс практической магии

Идем на сайт Жанны Рутковской — invisiblethings.org , видим раздел с инструментами tools, находим в нем «NUSHU — passive covert channel engine for Linux 2.4 kernels » и качаем архив исходных текстов — invisiblethings.org/tools/nushu/nushu.tar.gz (всего 18 Кб). Распаковываем, компилируем. Компиляция осуществляется стандартно. Просто запускаем утилиту make и получаем три модуля ядра: nushu_receiver.o (приемник), nushu_sender.o (передатчик) и nushu_hider.o.

Механизм шифрования ISN в протоколе NUSHU

Приемник устанавливается на поломанный маршрутизатор, передатчик — на целевой узел жертвы. Для организации двухсторонней связи приемник и передатчик устанавливаются на оба узла. Модуль nushu_hider.o в организации скрытого канала не участвует и предназначен для обмана штатных анализаторов (типа tcpdump), не позволяя им обнаруживать факт изменения ISN.

Из readme следует, что модуль-передатчик обрабатывает следующие параметры командной строки:

• dev=, где device – сетевое устройство, с которым предполагается работать (например, eth0);
• cipher=, где 0 означает передачу без шифрования, а 1 предписывает использование DES;
• key="string", где string — произвольная строка-маркер, идентичная строке-маркеру, установленной на модуле-приемнике (используется только в том случае, если шифрование выключено, иначе игнорируется);
• src_ip= — IP-адрес узла, на котором установлен передатчик.

Модуль-приемник, помимо описанных выше ключей dev, cipher и key, обрабатывает аргумент exclude_ip=<172.16.*.*>, задающий список неприкосновенных IP-адресов, при отправке пакетов на которые протокол NUSHU задействован не будет, поскольку ISN останется неизменным (этот параметр является опциональным).

Модуль nushu_hider.o загружается без каких-либо параметров и только в том случае, если в этом возникает необходимость.

Хорошо, все модули успешно загружены, ядро функционирует нормально и в панику, судя по всему, впадать не собирается. Что делать дальше? А ничего! Ведь это только движок, обеспечивающий функционирование PCC-каналов . К нему можно прикрутить кейлоггер или удаленный shell, но это уже придется делать самостоятельно. А как?! Ни readme, ни сопроводительные презентации не дают ответа на этот вопрос, поэтому приходится зарываться в исходные тексты и разбирать их на отдельные байты.

Начнем с передатчика, реализованного в файле sender.c. В процедуре init_module(), отвечающей за инициализацию модуля, сразу же бросаются в глаза следующие строки:

create_proc_read_entry ("info", 0, proc_de, cc_read_proc_info, NULL);
struct proc_dir_entry * wpde = create_proc_entry ("message_to_send", 0, proc_de);

Все ясно! Модуль использует псевдофайловую систему /proc, создавая директорию nushu, а в ней — два файла: info и message_to_send, с которыми можно работать с прикладного уровня, как с обычными устройствами (если быть точнее, псевдоустройствами).Аналогичным образом обстоят дела и с приемником, реализованным в файле receiver.c, ключевой фрагмент которого приведен ниже:

Struct proc_dir_entry *proc_de = proc_mkdir ("nushu", NULL);
create_proc_read_entry ("message_received", 0, proc_de, cc_read_proc_message, NULL);
create_proc_read_entry ("info", 0, proc_de, cc_read_proc_info, NULL);

Как видно, вместо устройства message_to_send на этот раз создается message_received, из которого можно читать получаемые сообщения через стандартные функции ввода/вывода. В общем, имея на руках исходные тексты, со всеми этими причиндалами совсем несложно разобраться, тем более что их суммарный объем составляет всего 69 Кб.

Заключение

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

Может ли атакованный администратор обнаружить скрытые пассивные каналы хотя бы теоретически? Скрупулезный анализ сетевого трафика позволяет выявить некоторую ненормальность распределения ISN, но для этого требуется обработать сотни тысяч «хакнутых» пакетов, сравнивая их с оригиналами. Потому намного проще выявить посторонний ядерный модуль, отвечающий за создание и поддержку PCC-каналов, используя общие методики верификации целостности системы. Однако это уже совсем другой разговор, к которому мы еще вернемся.

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

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

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

Мировой интернет-трафик вырастет до 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-сети должны обладать достаточным интеллектом и гибкостью для поддержки постоянно появляющихся новых и модернизируемых приложений для фиксированных и мобильных сетей. Стремясь дифференцировать свои сервисы, многие сервис-провайдеры активно сотрудничают с разработчиками приложений.

мая
2017

Публикации

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

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

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

Для чтения статьи нужно иметь базовые представления об IP-сетях и межсетевых экранах.

Введение

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

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

1.1 Компоненты виртуальной сети ViPNet

Компьютеры и мобильные устройства с ПО ViPNet Client в дальнейшем именуются Клиентами. Клиенты обеспечивают сетевую защиту и включение в VPN-сеть отдельных компьютеров и устройств.

Компьютеры с ПО ViPNet Coordinator для Windows и Linux, программно-аппаратные комплексы ViPNet для больших и мелких сетей, индустриальные шлюзы безопасности различной мощности, координаторы ViPNet на виртуальных машинах в дальнейшем именуются Координаторами. Координаторы различного класса защищенности обеспечивают шифрование трафика туннелируемых ими сетевых ресурсов (как VPN-шлюзы), ретранслируют VPN-трафик между другими VPN-узлами, выполняют служебные функции по поддержанию связности защищенной сети и оптимизации маршрутов прохождения VPN-трафика между узлами.

Клиенты и Координаторы называются узлами виртуальной сети ViPNet или просто узлами ViPNet. Возможность обмена трафиком через защищенные каналы между узлами ViPNet (связи между узлами) централизованно задает администратор.

1.2 Функции координатора

VPN-шлюз - стандартная для классических VPN функция, реализующая создание защищенных каналов (туннелей) site-to-site и client-to-site между локальными и удаленными узлами. Координатор может создавать такой канал через каскад других координаторов, выполняющих функцию маршрутизации VPN-пакетов.

Межсетевой экран - функция фильтрации открытых, защищенных и туннелируемых транзитных и локальных сетевых соединений, а также функция трансляции адресов для открытых и туннелируемых соединений.

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

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

Если клиент или координатор подключается к Интернету через устройство с динамическим NAT, то они недоступны напрямую для входящих инициативных соединений других узлов. В этом случае для организации доступа к ресурсам корпоративной сети за этим координатором или для соединения с таким клиентом с удаленных узлов один из координаторов во внешней сети определяется для них как сервер соединений, с которым они поддерживают постоянную связь. За счет функционала маршрутизатора VPN-пакетов сервер соединений служит промежуточным звеном для установления связи с таким узлом из внешней сети (с возможностью последующего перехода на прямое общение, подробнее см. «Соединение двух узлов, которые подключаются к Интернету через устройства с динамическим NAT»).

Сервер соединений автоматически задается в настройках клиентов при их развертывании, и впоследствии его можно менять. Для координатора при необходимости сервер соединений можно задать в его настройках.

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

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

2. Общие принципы взаимодействия узлов ViPNet в виртуальной сети

2.1 Протокол динамической маршрутизации

У каждого клиента есть «свой» координатор - его сервер IP-адресов, сервер соединений и транспортный сервер (см. «Функции координатора». При необходимости можно настроить выполнение этих функций разными координаторами).

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

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

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

Для обеспечения защищенной передачи трафика в соответствии с задачами информационного обмена (далее целевого трафика) нужно задать связи между узлами, обеспечивающими защиту этого трафика (клиентами и туннелирующими координаторами), а также задать связи клиентов со «своими» координаторами, которые в большинстве случаев создаются автоматически.

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

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

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

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

2.2 Инкапсуляция

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

Определенные модификации координаторов также поддерживают построение туннелей на канальном уровне (L2 OSI), что позволяет объединить в единую локальную сеть удаленные сегменты сетей. В этом случае в защищенные ViPNet IP-пакеты (UDP-протокол) инкапсулируются Ethernet-кадры любых сетевых протоколов, а не только IP.

Для инкапсуляции в ViPNet-пакеты используются два типа IP-протокола:

IP/UDP с портом источника 55777 по умолчанию или любым другим портом, который автоматически регистрируется на других узлах.

IP/241 - используется при взаимодействии узлов в одной локальной сети.

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

Для инкапсуляции трафика между узлами в одном широковещательном домене используется протокол IP/241

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

Для инкапсуляции трафика между узлами, разделенными NAT-устройством, используется UDP-протокол

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

Узел автоматически определяет такой запрет и устанавливает с сервером соединений TCP-соединение (по умолчанию по порту 80), через которое передает сформированные UDP-пакеты. ViPNet-трафик для других узлов передается через это соединение на сервер соединений, откуда уже в обычном виде передается дальше. При настройке TCP-туннеля на сервере соединений может быть указан любой порт, на котором сервер будет принимать TCP-пакеты.

Если использование UDP-трафика невозможно, узел устанавливает соединение по протоколу TCP со своим сервером соединений и через него обменивается UDP-трафиком с другими узлами сети ViPNet

2.3 Первоначальные настройки защищенной сети

В Центре управления сетью сформируйте структуру сети – клиенты, координаторы и их связи.

Задайте IP-адреса или DNS-имена для доступа к координаторам сети.

Клиенты ViPNet после инсталляции ПО в общем случае не требуют каких-либо настроек.

Для каждого координатора при необходимости задайте один из нескольких режимов подключения к внешней сети. Режим по умолчанию («Со статической трансляцией адресов») в большинстве случаев обеспечивает его работу без дополнительных настроек. Подробнее о задании режимов подключения на координаторе см. раздел «Варианты подключения координаторов к внешней сети».

На внешнем сетевом экране организации при необходимости настройте пропуск соответствующего протокола ViPNet (порты и адреса UDP- и/или TCP-протокола).

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

3. Механизмы соединений в сети ViPNet

3.1 Определение взаиморасположения узлов

Находятся в одном широковещательном домене.

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

Разделены NAT-устройствами с динамической трансляцией адресов.

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

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

3.2. Соединение двух узлов, которые подключаются к Интернету через устройства с динамическим NAT

1. При включении компьютера ПО ViPNet каждого из Клиентов определяет канал доступа к своему серверу соединений по UDP-протоколу (сервер соединений может быть и общий).

Если Клиенту 1 не удается соединиться со своим сервером соединений по UDP-протоколу, то Клиент устанавливает соединение по протоколу TCP (по умолчанию - порт 80, но можно установить и любой другой порт).

2. После подключения к серверу соединений клиент поддерживает соединение с ним путем периодической отправки на него тестовых IP-пакетов. Благодаря этому Клиент 1 предоставляет возможность другим узлам, в том числе и Клиенту 2, установить с ним инициативное соединение через свой сервер соединений. Интервал отправки IP-пакетов на сервер соединений по умолчанию равен 25 секундам. Этого, как правило, достаточно для работы через большинство устройств NAT. При необходимости интервал (тайм-аут) можно изменить.

3. Если от некоторого приложения на Клиенте 1 появляется целевой трафик в направлении Клиента 2 (например, VoIP), то Клиент 1 начинает передавать пакеты через свой сервер соединений. Сервер соединений, в свою очередь, пересылает эти пакеты на сервер соединений Клиента 2, а тот уже - самому Клиенту 2. Обратный трафик идет аналогичным маршрутом.

Если Клиент 1 соединяется со своим сервером соединений через TCP-соединение, то сервер соединений извлекает из TCP-соединения UDP-трафик (который по-прежнему зашифрован и недоступен для расшифрования на сервере соединений). Сервер передает UDP-трафик Клиенту 2 через его сервер соединений. Если Клиент 2 поддерживает связь со своим сервером соединений через TCP, то трафик, дойдя до сервера соединений Клиента 2, пойдет к Клиенту 2 через это TCP-соединение.

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

1. Параллельно с началом передачи и приема целевого трафика по протоколу UDP через серверы соединений происходит следующее:

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

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

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

Не все типы NAT позволяют установить прямое соединение (см. ниже). Прямое соединение возможно, если хотя бы у одной из сторон используется устройство NAT, позволяющее это сделать.

2. Если тестовые прямые IP-пакеты не дошли ни до одной из сторон, но дошли до сервера соединений другой стороны, то целевой трафик между двумя клиентами будет идти через один из серверов соединений. Доступность этого соединения также сохраняется для соединяющихся узлов в течение 75 секунд после окончания передачи целевого трафика. Аналогичная ситуация возникает, если один из клиентов подключается к своему серверу соединений через TCP. Этот сервер соединений не может быть исключен из передачи трафика, но может быть исключен другой сервер соединений, к которому его узел подключен по UDP.

3. Если тестовые пакеты никуда не дошли, то трафик между двумя узлами так и продолжит идти по длинному маршруту через два сервера соединений.

Начало взаимодействия клиентов за NAT-устройствами через серверы соединений и переход к взаимодействию напрямую

Существует четыре типа динамического NAT: Cone NAT, Address-Restricted cone NAT (или Restricted cone NAT), Port-Restricted cone NAT, Symmetric NAT. Установка прямого соединения не поддерживается только в случае, если оба NAT-устройства настроены для выполнения Symmetric NAT. В этом случае трафик будет идти через один из серверов соединений. Если хотя бы у одной стороны выполняется другой тип NAT, то прямое соединение будет установлено.

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

3.3 Соединение узлов в одной маршрутизируемой сети

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

3.4 Выбор сервера соединений для клиента, который перемещается в другую сеть ViPNet

наличие межсетевого взаимодействия между сетью клиента и сетью сервера соединений;

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

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

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

4. Варианты подключения координаторов к внешней сети

Режим подключения «Без использования межсетевого экрана».

Режим подключения «За координатором», при котором внешним межсетевым экраном является другой координатор.

Режим подключения через межсетевой экран «Со статической трансляцией адресов».

Режим подключения через межсетевой экран «С динамической трансляцией адресов».

По умолчанию координаторы устанавливаются в режим работы через межсетевой экран «Со статической трансляцией адресов». Режим можно изменить в управляющем приложении ViPNet Administrator или непосредственно на координаторе. Этот режим достаточно универсален и может использоваться в большинстве случаев.

4.1 Подключение координатора в режиме «Без использования межсетевого экрана»

В этом случае может использоваться и режим по умолчанию «Со статической трансляцией адресов». В последующих версиях ViPNet режим «Без использования межсетевого экрана» предполагается исключить из использования.

4.2 Подключение координатора через другой координатор: режим «За координатором»

Если координатор А расположен на границе между внутренним и внешним сегментами локальной сети, а внешняя сеть защищена координатором Б, то координатор А обычно устанавливают в режим «За Координатором», выбрав в качестве внешнего координатора координатор Б. Координатор Б в этом случае выполняет для координатора А роль сервера соединений.

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

Каскадное включение координаторов

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

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

• Удаленные узлы ViPNet отправляют трафик, предназначенный для внутреннего сегмента локальной сети, через внешний координатор, который перенаправляет его дальше, координаторам внутри локальной сети.

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

Построение схемы с каскадированием координаторов не ограничено настройкой координаторов в режиме «За координатором». Такую же схему можно создать путем использования режима координатора с динамическим NAT с настройкой «Весь трафик передавать через сервер соединений». В последующих версиях для построения каскадных схем планируется использовать только этот режим координатора.

4.3 Подключение координатора через межсетевой экран «Со статической трансляцией адресов»

Перенаправление пакетов из внешней сети на адрес координатора в соответствии с заданным на координаторе портом инкапсуляции трафика.

• Пропуск во внешнюю сеть UDP-пакетов, в которых в качестве источника указаны адрес и порт инкапсуляции координатора.

Координатор в данном режиме успешно работает и при отсутствии реального внешнего межсетевого экрана. Поэтому такой режим устанавливается на координаторах по умолчанию.

4.1 Режим межсетевого экрана «С динамической трансляцией адресов»

Поскольку координатор недоступен из внешней сети для инициативных соединений, то для него следует назначить в качестве сервера соединений один из координаторов, доступный из внешней сети (работающий в режиме «Со статической трансляцией адресов» или «Без использования межсетевого экрана»). Сервер соединений обеспечит возможность инициативного соединения с ресурсами локальной сети за таким координатором со стороны любых других узлов (с учетом связей в защищенной сети).

За счет того, что координатор в данном режиме доступен из внешней сети через его сервер соединений, клиенты и туннелируемые ресурсы в локальной сети за ним доступны для других узлов в полном объеме - так же, как за координатором в любом другом режиме. Работа координатора через сервер соединений в этом режиме аналогична описанной выше работе клиента за NAT-устройством и позволяет переходить к сообщению «напрямую», без участия сервера соединений (подробно о работе клиентов через сервер соединений см. «Соединение двух узлов, которые подключаются к Интернету через устройства с динамическим NAT»).

Работа координатора в режиме «С динамической трансляцией адресов» аналогична работе клиента за NAT-устройством: координатор гарантированно доступен из внешней сетичерез сервер соединений. Для простоты на рисунке не отображен сервер соединений удаленного клиента, который также участвует в первоначальном установлении соединения.

Если в настройках координатора включить опцию «Весь трафик передавать через сервер соединений», то можно строить каскадные схемы, аналогичные режиму «За координатором».

5. Туннелирование IP-трафика открытых ресурсов

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

Обеспечивает взаимодействие туннелируемых узлов с удаленными узлами для любых IP-протоколов. При этом не имеет значения, согласованы ли локальные адреса взаимодействующих узлов. Благодаря технологии виртуальных адресов в сети ViPNet могут взаимодействовать узлы, имеющие одинаковые IP-адреса (см. «Виртуальные адреса в сети ViPNet»), так что согласования адресации не требуется.

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

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

Открытые узлы, которые данный координатор будет туннелировать, можно задавать в настройках координатора или в управляющем приложении ViPNet Administrator в виде отдельных адресов или диапазонов.

6. Виртуальные адреса в сети ViPNet

6.1 Принцип работы виртуальных адресов

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

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

Для клиентов и координаторов формируется столько же виртуальных адресов, сколько у них есть реальных адресов.

Для индивидуальных адресов или диапазонов адресов узлов, туннелируемых удаленными координаторами, формируются непересекающиеся виртуальные адреса и диапазоны.

На каждом узле для других узлов и туннелируемых ими устройств формируется свой уникальный набор виртуальных адресов.

6.2 Адреса видимости

1. Списки реальных адресов других клиентов и координаторов передаются на узел в служебных сообщениях из управляющего приложения ViPNet Администратор и за счет работы протокола динамической маршрутизации ViPNet-трафика (см. «Протокол динамической маршрутизации»).

2. Списки реальных адресов узлов, туннелируемых удаленными координаторами, передаются на узел в служебных сообщениях из управляющего приложения ViPNet Администратор.

3. Если зашифрованный трафик приходит от узла, реальный адрес которого не был получен ранее из ViPNet Administrator или за счет протокола динамической маршрутизации (пп. 1 и 2), то узел регистрирует IP-адрес источника расшифрованного пакета как реальный адрес этого узла.

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

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

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

7. Маршрутизация трафика координаторов с несколькими сетевыми интерфейсами

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

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

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

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

8.Туннелирование трафика открытых ресурсов на канальном уровне (работа координаторов в режиме L2-шифратора L2-шифратора)

Координаторы типа HW могут быть установлены в режим L2-шифратора (технология туннелирования на канальном уровне L2OverIP). Координаторы в этом режиме устанавливаются на границах нескольких (до 32) удаленных локальных сетей и объединяют их в единую локальную сеть. Узлы в этих локальных сетях взаимодействуют так, как если бы они находились в одном широковещательном домене (без маршрутизации, с прямой видимостью по MAC-адресам).

Координатор в режиме L2-шифратора работает как виртуальный коммутатор, который пересылает поступившие на его L2-адаптер Ethernet-кадры в удаленные сети через аналогичные L2-шифраторы на их границах:

широковещательные (в частности ARP-запросы) и мультикастовые кадры - во все объединяемые сети;

юникастовые кадры - в конкретную сеть в соответствии с накопленной таблицей MAC- адресов виртуального коммутатора.

Не имеет значения протокол более высокого уровне (IP или иной) трафика, поступившего на L2-адаптер.

Координатор обрабатывает Ethernet-кадры и не различает IP-пакеты. Поэтому он не может использоваться для туннелирования IP-трафика открытых ресурсов (см. «Туннелирование IP-трафика открытых ресурсов»).

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

Координаторы поддерживают технологию VLAN (802.1Q):

Координатор в режиме L2-шифратора может пересылать тегированные кадры в другие сегменты с сохранением тегирования.

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

Можно увеличить производительность L2-канала между локальными сетями за счет подключения нескольких координаторов к внешнему коммутатору через разные порты по технологии EtherChannel. Испытания такого кластера из трех координаторов HW2000 показали производительность 10 Гбит/с (прямо-пропорциональное числу координаторов увеличение производительности). Подробнее см. статью «Защита ЦОД при помощи кластера ViPNet Coordinator HW» https://www.anti-malware.ru/analytics/Technology_Analysis/ViPNet_Coordinator_HW .

Заключение

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

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

Владимир Игнатов

IP Traffic Monitor is a bandwidth monitor, which allows you to analyze Internet traffic in real time. IP Traffic Monitor provides you with detailed analysis about network bandwidth usage.

Security and audit of resources are the key questions of the modern Internet environment. IP Traffic Monitor allows you to solve such questions effectively and at the proper time.

IP Traffic Monitor is a tool that helps you watch your network activity and see which connections take a lot of traffic. It works with Proxy Servers. Also, it saves daily logs and allows you to view the saved logs.

Tracking of internet traffic helps to detect spyware, adware, viruses and other suspicious activities, before they compromise you system’s security.

Product Overview

There are many reasons why you may want to monitor your Internet traffic flows. I’ll point out only a few of the most popular reasons. No anti-virus can guarantee you 100% protection from Trojan Horses and malicious spyware or adware programs. Some of them are highly customized and checking against anti-virus databases does nothing. They also slow down your Internet connection. Needless to say that identity theft or using your computer as a peer-to-peer network hub for pirated software, music and video downloads without you even knowing about this may certainly have unwanted consequences. If you share your computer with family members or you administer computers in your office, knowing the Internet traffic details becomes essential. Network load balance, security reasons and more. IP Traffic Monitor is an application designed to stay quietly in your system tray and monitors all your network connections. You can either monitor the active connections in real-time or browse historical logs. The program shows extensive information about each connection: remote host IP, remote host name (if available), amounts of incoming and outgoing traffic through this connection, timestamps of the first and last activity of this connection, name of the process that initiated or accepted this connection, full path to the application the process belongs to, etc. The traffic summary indicator shows an upload and download speed graph and traffic totals. In addition it draws pie chart diagrams that illustrate the percentage of certain hosts in the total incoming and outgoing traffic.

Screenshots

These days it’s not enough to have software that detects spyware, adware, viruses, and other suspicious activities. There’s always a chance that a brand new, unknown piece of malware can sneak into your network and wreak havoc. To be absolutely certain that everything in your network is hunky dory, you need to be able to analyze the volume and direction of Internet traffic, in real time.

IP Traffic Monitor helps you to accurately observe all network activity to easily identify which processes are generating the most traffic, providing a powerful indicator of possible viral infection or illegal activity. Network activity logs are generated daily, and you always have the option of reviewing past logs in your search for suspicious patterns.

IP Traffic Monitor features a streamlined interface complete with colorful charts and intuitive displays. At a glance, you’ll be able to see all of the processes that are currently running, and how much data has been uploaded and downloaded by each process. Visual charts show you exactly how much bandwidth is consumed by each process. If a remote host is involved, IP Traffic Monitor will show you its IP address and resolved name!