Информационный портал по безопасности. Передача IP трафика по сетям SDH, или Есть ли у ATM альтернатива

мая
2017

Публикации

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

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

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

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

Введение

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

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

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

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

Компьютеры и мобильные устройства с ПО 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 в виртуальной сети

Узлы сети ViPNet могут располагаться в сетях любого типа, поддерживающих IP-протокол. Способ подключения узла к сети может быть любой: сеть Ethernet, PPPoE через XDSL-подключение, PPP через подключение Dial-up или ISDN, любая сеть сотовой связи, устройства Wi-Fi, сети MPLS или VLAN и другие.

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

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

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

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

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

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

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

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

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

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

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

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

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

При появлении любого 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 Первоначальные настройки защищенной сети

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

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

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

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

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

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

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

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

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

Узлы по-разному устанавливают соединения, в зависимости от того, как они расположены по отношению друг к другу:

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

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

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

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

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

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

Рассмотрим организацию соединений между двумя узлами, которые подключаются к сети Интернет через провайдера, предоставляющего доступ в Интернет в режиме динамического NAT. Например, Клиент 1 находится в гостинице в Лондоне, а Клиент 2 - в гостинице в Санкт-Петербурге:

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 Соединение узлов в одной маршрутизируемой сети

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

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

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

Пользователь клиента или администратор сети может выбирать для клиента в качестве сервера соединений любой координатор, в том числе - координатор в другой сети ViPNet, с которой установлено межсетевое взаимодействие. Это бывает нужно, например, если клиент перемещается в локальную сеть, из которой доступ в Интернет возможен только через расположенный в этой локальной сети «чужой» координатор (координатор другой сети ViPNet). Условием возможности подключения через сервер соединений в другой сети является:

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

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

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

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

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

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

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

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

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

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

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

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

Если координатор имеет постоянный IP-адрес в Интернете, то к нему можно построить маршрут из любой сети, имеющей доступ в Интернет. На таком координаторе можно установить режим «Без использования межсетевого экрана».

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

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

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

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

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

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

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

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

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

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

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

Если на границе локальной сети уже установлен межсетевой экран стороннего производителя с возможностью настройки статических правил трансляции адресов, то за ним можно расположить координатор с частными адресами сетевых интерфейсов и установить на нем режим межсетевого экрана «Со статической трансляцией адресов». Каждый из сетевых интерфейсов координатора может быть подключен к той или иной сети через отдельный межсетевой экран со статическими правилами трансляции. Через этот координатор будет обеспечено взаимодействие других узлов ViPNet и открытых узлов в локальной сети с узлами за ее пределами. На межсетевом экране должны быть настроены статические правила трансляции адресов:

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

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

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

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

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

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

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

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

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

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

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

Для включения в виртуальную сеть узлов локальной сети, трафик которых не требуется защищать в локальной сети, координатор выполняет функцию туннелирующего сервера (VPN-шлюза):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На каждом узле ViPNet известны списки реальных IP-адресов всех узлов ViPNet, с которыми связан данный узел, а также списки IP-адресов туннелируемых координаторами узлов. Узел получает эти адреса разными способами:

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. Маршрутизация трафика координаторов с несколькими сетевыми интерфейсами

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

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

Приложения, работающие на координаторе или туннелируемых им ресурсах, посылают свои пакеты в адрес удаленных защищаемых ресурсов по их адресам видимости: реальным адресам удаленных узлов (как правило, это частные 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!

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

Олег АЛЛЕНОВ
AMT Group

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

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

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

Технология ATM

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

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

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

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

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

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

Технология IP

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

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

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

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

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

IP через ATM

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

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

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

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

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

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

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

IP через SDH

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

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

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

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

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

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

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

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

ОБ АВТОРЕ

Олег Алленов - инструктор учебного центра компании AMT Group, CCSI/CCIE. С ним можно связаться по тел. 725 - 7660
... Вы можете также настроить брандмауэр для блокировки всего входящего трафика от определенного IP адреса. ... Например, брандмауэр обычно будет пропускать входящий трафик с веб сайта, но не позволит несанкционированно подключиться к вашему компьютеру. ... Для того, чтобы распознать, какой трафик ему пропустить или же наоборот заблокировать, брандмауэр использует автоматические параметры, а...

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

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

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

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

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

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

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

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

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

Всем привет! В сегодняшней статье расскажем о том, как настроить отправку статистики о пакетах, проходящих через наш роутер Mikrotik на коллектор для дальнейшего анализа. Все мы знаем про такой протокол как Netflow, предназначенный для учёта сетевого трафика, разработанный компанией Cisco, так вот у Mikrotik есть своя реализация данного решения, которая полностью совместима со стандартом Cisco Netflow - Mikrotik Traffic Flow .

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

Поскольку Traffic Flow полностью совместим с Cisco Netflow, то он может использоваться различными утилитами, которые разработаны для Netflow.

Traffic Flow поддерживает следующие версии Netflow:

1. version 1 - Самая первая версия формата данных Netflow. Рекомендуется использовать только если нет альтернатив
2. version 5 - Дополнение первой версии, которой появилась возможность добавления номеров автономных систем (AS) и порядковых номеров потоков
3. version 9 - новая версия, позволяющая добавлять новые поля и типы записей благодаря шаблонному исполнению

Настройка

Итак, для того, чтобы начать собирать статистическую информацию о трафике, необходимо сначала включить Traffic Flow и определиться с каких интерфейсов осуществлять сбор. Делается это при помощи комбинации следующих команд:

/ip traffic-flow set enabled=yes interfaces=ether1

В нашем случае, указан лишь один интерфейс ether1, однако, если вы хотите собирать статистику с нескольких интерфейсов, просто укажите их через запятую. Если со всех - интерфейсов введите interfaces=all .

Вы также можете настроить количество потоков, которые могут одновременно находиться в памяти роутера командой cache-entries и указав нужное значение - (128k | 16k | 1k | 256k | 2k / 4k - по умолчанию)

Командой active-flow-timeout - можно настроить максимальное время жизни потока, по умолчанию это 30 минут.

Некоторые потоки, могут стать неактивными через какое-то время, то есть, в них не будет происходить обмен пакетами, этот тайм-аут настраивается командой inactive-flow-timeout . Если пакетов в потоке нет и данное время истекло, то в следующий раз traffic flow создаст новый поток, если обмен возобновится. По умолчанию это 15 секунд, но если сделать данное время слишком коротким, то это может привести к созданию большого количества отдельных поток и переполнению буфера.

После того как мы включили Traffic Flow и определились с интерфейсами, с которых хотим получать информацию о потоках, необходимо настроить хост назначения, который будет получать данную информацию (в терминологии Netflow такой хост называется коллектором). Делается это при помощи следующей команды

Ip traffic-flow target

Затем указывается IP адрес и UDP порт хоста назначения - add dst-address=(IP address) port=(UDP port) . Если вы хотите использовать конкретную версию протокола, то укажите ее командой version= (1,5,9)

Пример

Рассмотрим пример конфигурации Traffic Flow на роутере Mikrotik

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

Сначала включаем Traffic Flow и указываем интерфейс

/ip traffic-flow set enabled=yes interfaces=ether3

Затем указываем адрес коллектора, стандартный порт и версию протокола 5:

/ip traffic-flow target add dst-address=192.168.2.123 port=2055 version=5

Если Вы предпочитаете консоли утилиту WinBox , то для настройки Traffic Flow левом меню откройте пункт IP и выберите Traffic Flow , перед Вами откроется следующее окно:

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

После этого переходим на вкладку Targets и добавляем параметры коллектора, достаточно внести IP адрес, порт и версию. После этого нажимаем на кнопку Apply

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

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас:(Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!