ЗАЩИЩЕННАЯ ПЕРЕДАЧА ИНФОРМАЦИИ ПО SSL-VPN ТУННЕЛЯМ С ПОМОЩЬЮ ПРОТОКОЛОВ TCP И UDP
Секция: 3. Информационные технологии
III Студенческая международная заочная научно-практическая конференция «Молодежный научный форум: технические и математические науки»
ЗАЩИЩЕННАЯ ПЕРЕДАЧА ИНФОРМАЦИИ ПО SSL-VPN ТУННЕЛЯМ С ПОМОЩЬЮ ПРОТОКОЛОВ TCP И UDP
Впрочем, открытие доступа к ресурсам вовне может привести к тому, что они будут доступны не только сотрудникам компании, но и сотрудникам конкурирующих фирм. Одно из решений возникшей проблемы — это применение VPN (англ. Virtual Private Network — виртуальная частная сеть) — технологии, эта технология обеспечивает высокий уровень безопасности, у конечных пользователей не возникает сложностей в ее использовании и в то же время является наименее затратной.
VPN-технология, кроме защищенного удаленного доступа для сотрудников, предоставляет возможность предприятиям объединять сети территориально разрозненных подразделений и организовывать защищенные как видео, так и аудио конференции через Internet.
На текущий момент существует обилие VPN решений, тем не менее, обычно, системные администраторы корпоративных сетей предприятия для обеспечения дополнительной безопасности ограничивают доступ ко всем портам, за исключением 80 и 443, и поэтому использовать многие из них возможным не представляется. Вместо этого используют SSL-VPN (Secure Socket Layer — уровень защищенных сокетов), для использования которого, нужен только порт 443 [1]. Очень важной задачей является обеспечение надежной и быстрой работы VPN-сетей, потому что от этого зависит оперативность обмена информационными данными между сотрудниками компании и ее филиалами.
В процессе работы были поставлены следующие задачи:
· теоретический обзор реализации SSL-VPN-туннеля;
· выполнение эксперимента для определения зависимости скорости передачи данных от вероятности отброса пакетов;
· предложение оптимального способа решения выявленных проблем.
1. Процесс передачи данных по SSL-VPN туннелю
Приведем пример ситуации передачи данных сотрудником в корпоративную сеть. Предположим, работнику организации нужно обратиться к защищенному, невидимому извне Web-ресурсу компании. Для этого программа (прикладной уровень) должна сформировать HTTP-запрос (Hyper Text Transfer Protocol — протокол передачи гипертекстовой информации), а тот далее инкапсулируется в TCP (Transport Control Protocol — протокол управления транспортом) пакет и адресуется на порт 80 станции, на которой находится нужный нам Web-ресурс. Впрочем по одному порту нельзя распознать требуемую станцию, так как порт — это всего лишь точка доступа к какой-либо программе (в нашем случае к Web-серверу). Для того чтобы достичь нужную станцию, требуется указать её IP-адрес (сетевой уровень), но так как сеть назначения корпоративная, то IP-адрес Web-ресурса — локальный адрес из этой сети, который не имеет никакого значения в рамках глобального Internet. Таким образом, для того чтобы донести пакет до корпоративной сети, необходим какой-то транспорт по Интернету.
Перед процессом транспортировки внутренний стэк протоколов полностью шифруется (протокол SSL) и далее, с помощью внешнего IP, осуществляется передача по Internet до VPN-шлюза. Потом, уже на VPN-шлюзе, происходит передача пакетов вышестоящему протоколу (TCP), который перенаправляет их на порт программы, которая расшифровывает информацию (протокол SSL). Вслед за тем, используя IP адрес локального Web-ресурса, внутренний TCP с изначальным HTTP-запросом передаются по корпоративной сети.
2. Проблемы реализации SSL-VPN
Имеются две главные проблемы данной реализации: «эффект таяния трафика» и транспортирование UDP (User Datagram Protocol — протокол пользовательских датаграм, который является одним из основных протоколов, расположенных непосредственно над IP) поверх TCP. Протокол TCP является протоколом с гарантированной доставкой сообщений. Таким образом, если пакет, имеющий в себе сообщение, не получен, то он будет поставлен в очередь для возобновления отсылки и отправлен по окончанию отведенного периода времени (retransmission timeout — таймаут повторной передачи). Если по какой-либо причине пакет опять не получен, то TCP применяет механизм увеличения интервала времени, т. е. таймаута повторной передачи перед очередной повторной посылкой пакета. Впрочем, при применении протокола TCP поверх TCP, увеличение определенного интервала времени повторной передачи внешнего протокола TCP приводит к положению, что внутреннему TCP протоколу не доставится вовремя уведомления о получении пакета TCP, отправленного по корпоративной сети, что приводит к увеличению таймаутов повторной передачи. Возникает увеличение суммарных задержек, т. е. уменьшению скорости передачи — «эффект таяния трафика». Существует также вопрос, связанный с наличием у TCP механизма повторной передачи, который появляется при передачи UDP-трафика, например мультимедийной информации. В ситуации туннелирования UDP поверх TCP, внешний TCP, если пакет не был доставлен, повторит посылку данного пакета. Таким образом, пакеты, находящиеся в очереди, ждут доставки данного пакета, из-за чего возникают огромные задержки потокового вещания. При учитывании принципа нарастания интервала времени повторной передачи задержки при передаче потоковой информации становятся недопустимыми [2].
3. Результаты тестирования протоколов TCP и UDP
Для осуществления эксперимента были использованы две схемы: передача трафика по VPN-туннелю поверх TCP и туннелирование трафика поверх протокола UDP. Шифрование в обоих случаях не использовалось для того, чтобы можно было провести более тщательный анализ трафика.
При осуществлении эксперимента данные между VPN-клиентом и сервером проходил через трафик Шейпер (traffic shaper — рабочая станция, управляющая трафиком, на которой установлена операционная система UNIX), где программой ipfw был реализован отброс пакетов с определенной вероятностью (рис. 1). Это максимально приблизило ситуацию к реальной ситуации в сети. В качестве среды передачи данных использовался реальный сегмент сети Ethernet.
Рисунок 1. Экспериментальный полигон системы защиты из двух локальных сетей
Эксперимент проходил в четыре этапа:
1) тестирование туннелирования TCP поверх стандартного TCP;
2) тестирование туннелирования TCP поверх UDP;
3) тестирование туннелирования UDP поверх стандартного TCP;
4) тестирование туннелирования UDP поверх UDP.
Для проведения первых двух этапов использовалась передача файла по FTP-протоколу через VPN-туннель, при этом производились замеры скорости передачи (V) в зависимости от различных вероятностей отброса пакетов (P). Результаты эксперимента отражены на рис. 2.
Рисунок 2. График зависимости скорости передачи данных от вероятности отброса пакетов
Из рис. 2 видно, что при низких потерях туннелирование по протоколу UDP более эффективно: скорость передачи примерно в два раза выше, чем при туннелировании по TCP. Однако при больших потерях скорость передачи данных по протоколу TCP несколько выше, чем у протокола UDP, что объясняется наличием у внешнего протокола механизмов адаптации к текущей нагрузке сети.
Для проведения последних двух этапов на клиенте и сервере были соответственно установлены клиентская и серверная части программы VideoLan, которая может использоваться для вещания потокового видео по UDP-протоколу. Это дало возможность протестировать эффективность передачи UDP-трафика в зависимости от различных вероятностей отброса пакетов.
После эксперименты мы можем сделать выводы, что при туннелировании видеопотока поверх TCP с вероятностью отброса пакетов менее 4 процентов, скорость воспроизведения и качество изображения достаточны для проведения видеоконференций. Однако повышение вероятности отброса пакетов на один процент привело к значительному ухудшению качества вещания (таблица): видео-поток практически полностью остановился, чему свидетельствует скорость воспроизведения видео — 5, 6 кадров в секунду, чего явно недостаточно для восприятия видеоинформации человеком.
При туннелировании UDP-трафика поверх UDP ситуация заметно лучше: при потере пакетов с вероятностью, меньшей 9 %, качество потока оставалось на уровне, достаточном для проведения видеоконференций, что подтверждается высокой скоростью воспроизведения кадров (таблица 1).
Таблица 1.
График зависимости скорости передачи данных от вероятности отброса пакетов
№ |
Вероятность отброса пакетов, % |
Данные, полученные при туннелировании по TCP |
Данные, полученные при туннелировании по UDP |
||||
FSP, к/с |
Скорость потока, к/с |
Количество потерянных кадров |
FSP, к/с |
Скорость потока, к/с |
Количество потерянных кадров |
||
1 |
0 |
25 |
236 |
0 |
24 |
236 |
0 |
2 |
1 |
24 |
236 |
0 |
24 |
236 |
0 |
3 |
2 |
21 |
236 |
22 |
24 |
236 |
0 |
4 |
3 |
23 |
236 |
0 |
24 |
236 |
0 |
5 |
4 |
5.3 |
73.6 |
438 |
24 |
235 |
3 |
6 |
5 |
<1 |
52.5 |
1076 |
24 |
235 |
10 |
7 |
6 |
-- |
-- |
-- |
24 |
230 |
11 |
8 |
7 |
-- |
-- |
-- |
24 |
225 |
22 |
9 |
8 |
|
|
|
23 |
34 |
948 |
Из результатов опыта мы видим, что использование протокола UDP в качестве внешнего (поверх которого осуществляется туннелирование) можно считать более эффективным для передачи видеоинформации (UDP-трафика) по SSL-VPN-туннелям. Однако при передаче TCP-трафика по сетям с большой вероятностью потери пакетов, из-за отсутствия механизмов адаптации к текущей нагрузке сети, а именно механизма регулирования размера окна, протокол UDP показывает более низкие результаты, чем TCP.
Заключение
Несомненно, что пользоваться лишь одним из протоколов (либо TCP, либо UDP) во всех случаях недопустимо. Использование обоих протоколов (TCP и UDP) позволяет решить вышеуказанные проблемы (передачи UDP-данных по SSL-VPN-туннелю и таяния трафика). Выбор нужного протокола должен осуществляться автоматически в зависимости от типа туннелируемого трафика.
Список литературы:
1. В.Ф. Шангин. Информационная безопасность компьютерных систем и сетей [Текст] / В.Ф. Шангин — СПб.: Издательский Дом «ФОРУМ»: ИНФА-М, 2008. — 416 с.
2. Олифер В. Компьютерные сети. Принципы технологии, протоколы / В. Олифер — СПб.: Питер, 2010. — 944 с.