Введение
Создание виртуальной среды для работы с VPN актуально тем, что студенты смогут получить практический навык работы в процессе обучения и применить его в дальнейшем на практике. В работе содержатся все необходимые сведения для самостоятельной настройки VPN сервера и реализации подключений.
Целью данной работы является создание виртуальной среды, реализующей различные виды соединений VPN.
Задачи, решаемые в данной работе:
1) Обзор протоколов построения VPN соединений;
2) Анализ существующих программных средств реализаций VPN сервера;
3) Выбор программной базы для реализации VPN в виртуальной среде;
4) Выбор операционных систем;
5) Анализ и выбор систем виртуализации;
6) Разработка виртуальной среды для проведения практических занятий по освоению протоколов построения VPN соединений;
7) Создание учебно-методического пособия для практических занятий.
Работа будет полезна студентам младших курсов, людям пытающимся разобраться с сетевыми технологиями самостоятельно, а также обычным пользователям.
1. Обзорно-аналитическая часть
1.1. Обзор протоколов
Технология VPN (англ. Virtual Private Network – виртуальная частная сеть) позволяет обеспечить одно или несколько соединений, поверх уже существующей сети (например, Интернет), а с помощью современных криптографических средств (шифрование, аутентификация, криптографические ключи) добиться максимальной защищенности передаваемой информации.
Если обратиться к модели OSI, то VPN чаще всего реализуется на уровне не выше сетевого, т.к. именно на этих уровнях можно использовать криптографию, оставляя без изменения транспортные протоколы.
Таким образом, VPN представляет собой защищенное соединение поверх существующей сети, осуществляемое посредством инкапсуляции данных, чаще всего в протокол IP.
В свою очередь, протоколов реализации VPN существует не так много. Рассмотрим каждый из них.
1.1.1. IPSEC
IPsec [2] (англ. IP Security) – это набор протоколов, обеспечивающих безопасность передачи данных поверх IP протокола. Принцип, по которому достигается требуемый уровень безопасности, состоит в добавлении к IP пакету собственных заголовков.
IPsec – стандарт Интернет, поэтому он обладает “Рабочим предложением” (RFC – Requests For Comments). Рассмотрим ряд RFC относящихся к IPsec:
RFC 2401 – SA (Security Architecture for the Internet Protocol)
Так называемая концепция “Защищенного виртуального соединения” (SA). Является фундаментальной в IPSec. Представляет собой двунаправленное соединение для каждого используемого протокола (AH - аутентифицирующий заголовок, или ESP – инкапсуляция зашифрованных данных).
Определены два режима SA: режим транспорта и режим туннелирования.
Транспортный режим SA обеспечивает безопасную связь между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP заголовка и всех опций и перед любыми протоколами более высокого уровня (ТСР или UDP). В случае ESP транспортный режим SA обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP-заголовка. В случае AH защита также распространяется на отдельные части IP-заголовка.
Другим режимом SA является режим туннелирования. Если хотя бы одним из концов соединения является шлюз безопасности, то SA обязательно должна выполняться в туннелирующем режиме. SA между двумя шлюзами безопасности всегда находится в туннелирующем режиме, так же, как и SA между хостом и шлюзом безопасности. Заметим, что когда трафик предназначен для шлюза безопасности, например, в случае SNMP-команд, шлюз безопасности рассматривается как хост, и допустим транспортный режим. Два хоста могут при желании так же устанавливать туннелирующий режим.
Так как защищенные виртуальные соединения (SA) являются симплексными, то для организации дуплексного канала, как минимум, нужны два SA. Помимо этого, каждый протокол (ESP/AH) должен иметь свою собственную SA для каждого направления, то есть, связка AH+ESP требует наличия четырех SA. Все эти данные располагаются в SADB (SA Data Base).
Помимо базы данных SADB, реализации IPsec поддерживают базу данных SPD (Security Policy Database - База данных политик безопасности). Запись в SPD состоит из набора значений полей IP-заголовка и полей заголовка протокола верхнего уровня. Эти поля называются селекторами. Селекторы используются для фильтрации исходящих пакетов, с целью поставить каждый пакет в соответствие с определенным SA. Когда формируется пакет, сравниваются значения соответствующих полей в пакете (селекторные поля) с теми, которые содержатся SPD. Находятся соответствующие SA. Затем определяется SA (в случае, если оно имеется) для пакета и сопряженный с ним индекс параметров безопасности (SPI). После чего выполняются операции IPsec (операции протокола AH или ESP).
RFC 2402 – AH (Authentication Header)
Протокол заголовка идентификации (рис. 1.1). Протокол обеспечивает целостность передаваемых по защищенному каналу данных, путем проверки того, что ни один байт в защищаемой информации не был изменен во время передачи. Подробно, с диаграммами, структура данного заголовка описывается в соответствующем RFC.
Важно отметить, что использование AH может вызывать проблемы при прохождении пакета через NAT устройство. Как известно, NAT меняет IP адрес, а значит пакет меняется и контрольная сумма AH – становится не верной.
АH служит для подтверждения факта связи с целевым узлом и что данные, которые мы получаем при передаче, не искажены.
Формат заголовка AH проиллюстрирован на рисунке 1.1. Рассмотрим его состав.
Next Header (8 bits)
Тип заголовка протокола, идущего после заголовка AH. По этому полю приемный IP-sec модуль узнает о защищаемом протоколе верхнего уровня. Значения этого поля для разных протоколов можно посмотреть в RFC 1700.
Payload Len (8 bits)
Это поле определяет общий размер АН-заголовка в 32-битовых словах, минус 2. Несмотря на это, при использовании IPv6 длина заголовка должна быть кратна 8 байтам.
Рис. 1.1 Формат протокола заголовка идентификации
Reserved (16 bits)
Зарезервировано. Заполняется нулями.
Security Parameters Index (32 bits)
Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (АН-протокол), однозначно определяет защищенное виртуальное соединение (SA) для данного пакета. Диапазон значений SPI 1...255 зарезервирован IANA.
Sequence Number (32 bits)
Последовательный номер. Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может отказаться от услуги по защите от повторной передачи пакетов, оно является обязательным и всегда присутствует в AH-заголовке. Передающий IPsec-модуль всегда использует это поле, но получатель может его и не обрабатывать.
Integrity Check Value
Контрольная сумма. Должна быть кратна 8-байтам для IPv6, и 4-байтам для IPv4.
RFC 2406 – ESP (IP Encapsulating Security Payload)
Инкапсулирующий протокол безопасности (рис. 1.2). ESP также может обеспечивать целостность соединения, аутентификацию исходных данных и дополнительно anti-replay сервис. Целостность обеспечивается только для протоколов более высокого уровня. Хотя бы один из этих сервисов должен быть задействован при использовании ESP.
Рис. .2 Структура инкапсулирующего протокола безопасности
Security Parameters Index (32 bits)
Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (АН-протокол), однозначно определяет защищенное виртуальное соединение(SA) для данного пакета. Диапазон значений SPI 1...255 зарезервирован IANA для последующего использования.
Sequence Number (32 bits)
Последовательный номер. Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может и отказаться от услуги по защите от повторной передачи пакетов, оно всегда присутствует в AH-заголовке. Отправитель (передающий IPsec-модуль) должен всегда использовать это поле, но получатель может и не нуждаться в его обработке.
Payload data (variable)
Это поле содержит данные в соответствии с полем "Next Header". Это поле является обязательным и состоит из целого числа байтов. Если алгоритм, который используется для шифрования этого поля, требует данных для синхронизации криптопроцессов (например, вектор инициализации — "Initialization Vector"), то это поле может содержать эти данные в явном виде.
Padding (0-255 octets)
Дополнение. Необходимо, например, для алгоритмов, которые требуют, чтобы открытый текст был кратен некоторому числу байтов), например, размеру блока для блочного шифра.
Pad Length (8 bits)
Размер дополнения(в байтах).
Next Header (8 bits)
Это поле определяет тип данных, содержащихся в поле "Payload data".
Integrity Check Value
Контрольная сумма. Должна быть кратна 8-байтам для IPv6, и 4-байтам для IPv4.
RFC 2409 – IKE (The Internet key Exchange)
Протокол, предназначенный для обмена ключами между двумя узлами VPN. Протокол предусматривает генерацию ключей вручную и в автоматическом режиме. Обмен данными в IKE происходит в 2 фазы. В первой фазе устанавливается SA IKE. Во второй SA IKE используется для согласования протокола (обычно IPSec).
Фаза Один и Фаза Два
Теперь давайте посмотрим как всё это работает вместе. Установка и поддержка VPN туннеля происходит в два этапа. На первом этапе (фазе) два узла договариваются о методе идентификации, алгоритме шифрования, хэш алгоритме и группе Диффи Хеллмана (Diffie Hellman – алгоритм, позволяющий двум или более пользователям обменяться без посредников ключом). Они также идентифицируют друг друга. Всё это может пройти в результате обмена тремя нешифрованными пакетами (т.н. агрессивный режим) или через обмен шестью нешифрованными пакетами (стандартный режим - main mode). Предполагая, что операция завершилась успешно, создаётся SA первой Фазы - Phase 1 SA (также называемый IKE SA) и процесс переходит к Фазе Два.
На втором этапе генерируются данные ключей, узлы договариваются насчёт используемой политики. Этот режим, также называемый быстрым режимом (quick mode), отличается от первой фазы тем, что может установиться только после первого этапа, когда все пакеты второй фазы шифруются. Такое положение дел усложняет решение проблем в случае неполадок на второй фазе при успешном завершении первой. Правильное завершение второй фазы приводит к появлению Phase 2 SA или IPSec SA, и на этом установка туннеля считается завершённой.
Допустим, туннель между узлами был успешно установлен и ожидает пакетов. Однако, узлам необходимо переидентифицировать друг друга и сравнить политику через определённое время. Это время известно как время жизни Phase One или IKE SA lifetime.
Узлы также должны сменить ключ для шифрования данных через другой отрезок времени, который называется временем жизни Phase Two или IPSec SA lifetime. Phase Two lifetime короче, чем у первой фазы, т.к. ключ необходимо менять чаще. Типичное время жизни Phase Two - 60 минут. Для Phase One оно равно 24 часам.
1.1.2. PPTP
PPTP [5][6] (англ. Point-to-point transfer protocol) – протокол соединения “точка-точка”. Создан для инкапсуляции PPP кадров в пакет IP. Инициирует сессию по протоколу GRE (протокол туннелирования сетевых пакетов, инкапсулирующий пакеты сетевого уровня в IP пакеты) с другой стороной и создает TCP соединение для управления GRE трафиком по порту 1723. Протокол поддерживает шифрование данных MPPE (Microsoft point-to-point encryption). Для аутентификации клиентов, могут использоваться различные механизмы, наиболее безопасные из них: MS-CHAPv2 и EAP-TLS.
Процесс связи по протоколу PPTP
Поскольку вся идея дистанционного доступа состоит в разрешении машине клиента подключаться по телефонной линии к машине сервера, соединение PPTP инициируется клиентом, который использует служебное средство Windows NT - Remote Access Service (RAS) - для установления PPP-соединения с поставщиком услуг Internet. Затем при активизированном соединении PPP с помощью сервера, подключенного к Internet и действующего как сервер RAS, клиент применяет RAS для выполнения второго соединения. На этот раз в поле номера телефона указывается IP-адрес (имя или номер), и клиент, для того чтобы осуществить соединение, вместо COM-порта использует VPN-порт (VPN-порты конфигурируются на машинах клиента и сервера в процессе инсталляции PPTP).
Ввод IP-адреса инициирует передачу запроса серверу на начало сеанса. Клиент ожидает от сервера подтверждения имени пользователя и пароля и ответа сообщением, что соединение установлено. В этот момент начинает свою работу канал PPTP, и клиент может приступить к туннелированию пакетов серверу.
В основе обмена данными по протоколу PPTP лежит управляющее соединение PPTP - последовательность управляющих сообщений, которые устанавливают и обслуживают туннель. Полное соединение PPTP состоит только из одного соединения TCP/IP, которое требует передачи эхо-команд для поддержания его открытым, пока выполняются транзакции. В таблице 1.1 показаны эти сообщения и их функциональное назначение.
Таблица 1.1. Управляющие сообщения PPTP
Управляющее сообщение
|
Функция
|
Start-Control-Connection-Request
|
Запрос на установление управляющего соединения
|
Start-Control-Connection-Replay
|
Ответ на сообщение Start-Control-Connection-Request
|
Echo-Request
|
Сообщение "Keep-alive" ("все живы") для управляющего соединения
|
Echo-Replay
|
Ответ на сообщение Echo-Request
|
Set-Link-Info
|
Посылается сервером сети для задания PPP-параметров переговоров
|
Stop-Control-Connection-Request
|
Команда завершить управляющее соединение
|
Stop-Control-Connection-Replay
|
Ответ на сообщение Stop-Control-Connection-Request
|
1.1.3. L2TP
L2TP [7] [8] (англ. Layer 2 tunneling protocol) – протокол туннелирования второго уровня. Главное достоинство L2TP в том, что этот протокол позволяет создавать туннель не только в IP но и, к примеру, в ATM сетях (сети в которых используется асинхронный способ передачи данных).
Транспортной средой для протокола является – UDP (протокол пользовательских дейтаграмм). Шифрование данных обеспечивает комплекс средств, предлагаемый протоколом безопасности IPSec.
Не смотря на то, что L2TP действует на подобии канального уровня модели OSI, он является протоколом Сеансового уровня и использует зарегистрированный UDP порт – 1701.
L2TP использует два вида пакетов, управляющие и информационные сообщения.
Управляющие сообщения используются при установлении, поддержании и закрытии туннелей.
Информационные сообщения используются для инкапсуляции PPP-кадров пересылаемых по туннелю. Управляющие сообщения используют надежный контрольный канал в пределах L2TP, чтобы гарантировать доставку. Информационные сообщения если происходит их потеря, не пересылаются повторно.
Таблица 1.2. Структура протокола L2TP
PPP кадры
|
L2TP Информационные сообщения
|
|
L2TP Управляющие сообщения
|
L2TP Информационный канал (ненадежный)
|
L2TP Канал управления (надежный)
|
Транспортировка пакетов (UDP, FR, ATM, etc.)
|
В табл. 1.2. показано взаимоотношение PPP-кадров и управляющих сообщений по управляющему и информационному каналам L2TP. PPP-кадры передаются через ненадежный канал данных, инкапсулированные сначала в L2TP, а затем в транспортные пакеты, такие как UDP, Frame Relay, ATM и т.д. Управляющие сообщения посылаются через надежный управляющий канал L2TP, который передает пакеты в пределах того же пакетного транспорта.
Порядковые номера необходимы во всех управляющих сообщениях и используются в управляющем канале для обеспечения надежной доставки. Информационные сообщения могут использовать порядковые номера, чтобы восстановить порядок пакетов и детектировать потерю кадров. Все коды посылаются в порядке, принятом для сетей (старшие октеты первые).
Формат заголовка L2TP
Пакеты L2TP для контрольного и информационного каналов используют один и тот же формат заголовка. Заметим, что поля длина, Ns и Nr - опционные для информационных пакетов, являются обязательными для всех управляющих сообщений.
Заголовок имеет следующий формат:
Таблица 3. Формат заголовка L2TP
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
16
|
|
|
|
|
|
31
|
T
|
L
|
X
|
X
|
S
|
X
|
O
|
P
|
X
|
X
|
X
|
X
|
Версия
|
Длина (опц)
|
ID туннеля
|
ID сессии
|
Ns (опц)
|
Nr (опц)
|
Offset Size (опц)
|
Offset Pad (опц)......
|
Playload data
|
Бит тип (T) характеризует разновидность пакета. Он устанавливается равным 0 для информационных сообщений и 1 - для управляющих.
Если бит длины (L) равен 1, поле длина присутствует. Для управляющих сообщений этот бит должен быть равен 1.
Биты (X) зарезервированы для будущих применений. Все зарезервированные биты должны быть установлены равными 0 для исходящих сообщений и игнорироваться для входящих.
Если бит последовательности (S) равен 1, поля Ns и Nr присутствуют. Бит S для управляющих сообщений должен быть равен 1.
Если бит смещения (O) равен 1, поле величины смещения присутствует. Бит O для управляющих сообщений должен быть равен 0.
Если бит приоритета (Р) равен 1, это информационное сообщение должно обслуживаться с предпочтением при обработке очередей и передаче. Запрос эхо LCP (Link Control Protocol) используется для канала, в качестве контроля keepalive, его следует посылать с битом приоритета равным 1. Без этого, временные периоды локальной перегрузки могут вызвать интерференцию с сообщениями keepalive и потерю связи. Эта особенность характерна только для информационных сообщений. Бит P должен быть равен 0 для всех управляющих сообщений.
Поле “Версия” должно быть равно 2, указывая версию заголовка информационного сообщения L2TP. Значение 1 зарезервировано для детектирования пакетов L2F [RFC-2341], в условиях, когда они приходят вперемешку с L2TP-пакетами. Пакеты, полученные с неизвестным значением поля “Версия”, должны отбрасываться.
Поле “Длина” указывает общую длину сообщения в октетах.
ID-туннеля содержит идентификатор управляющего соединения. Идентификаторы туннеля L2TP имеют только локальное значение. То есть, разные концы одного туннеля должны иметь разные ID. ID-туннеля в каждом сообщении должно быть тем, которое ожидает получатель. ID-туннеля выбираются при формировании туннеля.
ID-сессии определяет идентификатор для сессии данного туннеля. Сессии L2TP именуются с помощью идентификаторов, которые имеют только локальное значение. ID-сессии в каждом сообщении должно быть тем, которое ожидает получатель. ID-сессии выбираются при формировании сессии.
(Ns) определяет порядковый номер информационного или управляющего сообщения, начиная с нуля и увеличиваясь на 1 (по модулю 216) для каждого посланного сообщения.
(Nr) содержит порядковый номер, который ожидается для следующего сообщения. Таким образом, Nr делается равным Ns последнего по порядку полученного сообщения плюс один (по модулю 216). В информационных сообщениях, Nr зарезервировано и, если присутствует (как это определяется S- битом), должно игнорироваться при получении.
Поле величина смещения (Offset Size), если имеется, специфицирует число октетов после заголовка L2TP, где должно начинаться поле данных. Содержимое заполнителя смещения не определено. Если поле смещения присутствует, заголовок L2TP завершается после завершающего октета заполнителя смещения.
представляющий собой комбинацию технологий PPTP и L2F (Layer Two Forwarding). Транспортная среда для протокола L2TP — UDP. Шифрование данных обеспечивает комплекс средств, предлагаемых протоколом безопасности IPSec. Доступны следующие методы шифрования: DES (Data Encryption Standard) с 56-бит ключом и 3DES (Triple DES) с тремя 56-бит ключами.
|
