Туннелирование

Защита информации в процессе ее передачи по открытым каналам основана на построении защищенных виртуальных каналов связи, называемых криптозащищенными туннелями. Каждый такой туннель представляет собой соединение, проведенное через открытую сеть, по которому передаются криптографически защищенные пакеты сообщений. Создание защищенного туннеля выполняют компоненты виртуальной сети, функционирующие на узлах, между которыми формируется туннель. Эти компоненты принято называть инициатором и терминатором туннеля. Инициатор туннеля инкапсулирует (встраивает) пакеты в новый пакет, содержащий наряду с исходными данными новый заголовок с информацией об отправителе и получателе. Хотя все передаваемые по туннелю пакеты являются пакетами IP, инкапсулируемые пакеты могут принадлежать к протоколу любого типа, включая пакеты немаршрутизируемых протоколов, таких, как NetBEUI. Маршрут между инициатором и терминатором туннеля определяет обычная маршрутизируемая сеть IP, которая может быть и сетью отличной от Интернет. Терминатор туннеля выполняет процесс обратный инкапсуляции – он удаляет новые заголовки и направляет каждый исходный пакет в локальный стек протоколов или адресату в локальной сети. Сама по себе инкапсуляция никак не влияет на защищенность пакетов сообщений, передаваемых по туннелю. Но благодаря инкапсуляции появляется возможность полной криптографической защиты инкапсулируемых пакетов. Конфиденциальность инкапсулируемых пакетов обеспечивается путем их криптографического закрытия, то есть зашифровывания, а целостность и подлинность – путем формирования цифровой подписи. Поскольку существует большое множество методов криптозащиты данных, очень важно, чтобы инициатор и терминатор туннеля использовали одни и те же методы и могли согласовывать друг с другом эту информацию. Кроме того, для возможности расшифровывания данных и проверки цифровой подписи при приеме инициатор и терминатор туннеля должны поддерживать функции безопасного обмена ключами. Ну и наконец, чтобы туннели создавались только между уполномоченными пользователями, конечные стороны взаимодействия требуется аутентифицировать.

Классификация виртуальных частных сетей vpn

Наиболее часто используются следующие три признака классификации VPN:

• рабочий уровень модели OSI;

• конфигурация структурно-технического решения;

• способ технической реализации.

Классификация VPN по рабочему уровню ЭМВОС

Для технологий безопасной передачи данных по общедоступной (незащищенной) сети применяют обобщенное название - защищенный канал (secure channel). Защищенный канал можно построить с помощью системных средств, реализованных на разных уровнях эталонной модели взаимодействия открытых систем (ЭМВОС, OSI) (рис.1).

Протоколы защищенного доступа	Прикладной	Влияют на приложения
	Представительный
	Сеансовый
	Транспортный	Прозрачны для приложений
	Сетевой
	Канальный
	Физический

Рис.1. Уровни протоколов защищенного канала

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

• VPN второго (канального) уровня;

• VPN третьего (сетевого) уровня;

• VPN пятого (сеансового) уровня.

VPN строятся на достаточно низких уровнях модели OSI. Причина этого в том, что чем ниже в стеке реализованы средства защищенного канала, тем проще их сделать прозрачными для приложений и прикладных протоколов. Однако здесь возникает другая проблема - зависимость протокола защиты от конкретной сетевой технологии. Если для защиты данных используется протокол одного из верхних уровней (прикладного или представительного), то такой способ защиты не зависит от того, какие сети (IP или IPX, Ethernet или ATM) применяются для транспортировки данных, что можно считать несомненным достоинством. С другой стороны, приложение при этом становится зависимым от конкретного протокола защиты, то есть для приложений подобный протокол не является прозрачным. Защищенному каналу на самом высоком, прикладном уровне свойствен еще один недостаток - ограниченная область действия. Протокол защищает только вполне определенную сетевую службу - файловую, гипертекстовую или почтовую. Например, протокол S/MIME защищает исключительно сообщения электронной почты. Поэтому для каждой службы необходимо разрабатывать соответствующую защищенную версию протокола. На верхних уровнях модели OSI существует жесткая связь между используемым стеком протоколов и приложением.