Протокол управления каналом LCP

Рассмотрим реализацию первой схемы туннелирования (рис. 10.3). Удаленный пользователь устанавливает удаленное соединение с локальной сетью с помощью

Данный способ инкапсуляции обеспечивает независимость от протоколов сетевого уровня модели OSI и позволяет осуществлять защищенный удаленный доступ через открытые IP-сети к любым локальным сетям (IP, IPX или NetBEUI). Согласно прото­колу РРТР при создании защищенного виртуального канала производится аутенти­фикация удаленного пользователя и шифрование передаваемых данных (рис. 10.2).

Протокол РРТР (Point-to-Point Tunneling Protocol), разработанный компанией Microsoft при поддержке ряда других компаний, предназначен для создания защи­щенных виртуальных каналов при доступе удаленных пользователей к локальным сетям через Интернет. Протокол РРТР предполагает создание криптозащищенного туннеля на канальном уровне модели OSI для случая как прямого соединения уда­ленного компьютера с открытой сетью, так и подсоединения его к открытой сети по телефонной линии через провайдера [10, 28].

Все три протокола, РРТР, L2F и L2TP, обычно относят к протоколам формиро­вания защищенного канала, однако этому определению точно соответствует только протокол РРТР, который обеспечивает туннелирование и шифрование передавае­мых данных. Протоколы L2F и L2TP являются протоколами туннелирования, по­скольку поддерживают только функции туннелирования. Функции защиты данных (шифрование, целостность, аутентификация) в этих протоколах не поддерживают­ся. Для защиты туннелируемых данных в этих протоколах необходимо использо­вать некоторый дополнительный протокол, в частности IPSec.

Протоколы PPTP. L2F (Layer-2 Forwarding), L2TP(Layer-2Tunneling Protocol) канального уровня модели OSI. Общим свойством этих протоколов является то, что они используются для организации защищенного многопротокольного удаленного до­ступа к ресурсам корпоративной сети через открытую сеть, например через Интернет.

Протоколы формирования защищенных каналов на канальном уровне

Аутентификация

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

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

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

Клиентское программное обеспечение обычно использует для удаленного досту­па стандартный протокол канального уровня РРР (Point-to-Point Protocol). Про­токолы РРТР, L2F и L2TP основываются'на протоколе РРР и являются его расши­рениями. Первоначально протокол РРР, расположенный на канальном уровне, был разработан для инкапсуляции данных и их доставки по соединениям типа точка-точ­ка. Этот протокол служит также для организации асинхронных (например, комму­тируемых) соединений. В частности, в настройках коммутируемого доступа уда­ленных систем Windows 2000/9х обычно указывается подключение к серверу по протоколу РРР.

В набор РРР входят протокол управления соединением LCP (Link Control Protocol), ответственный за конфигурацию, установку, работу и завершение соединения точка-точка, и протокол управления сетью NCP (Network Control Protocol), способный инкапсулировать в РРР протоколы сетевого уровня для транспортировки через соединение точка-точка. Это позволяет одновременно передавать пакеты Novell IPX и Microsoft IP по одному соединению РРР.

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

После того как туннельный протокол доставляет пакеты из начальной точки тун­неля в конечную, выполняется деинкапсуляция.

На физическом и канальном уровнях протоколы РРТР и L2TP идентичны, но на этом их сходство заканчивается и начинаются различия.

Протокол РРТР

Протокол РРТР получил практическое распространение благодаря компании Microsoft, реализовавшей его в своих операционных системах Windows NT/2000. Не­которые производители межсетевых экранов и шлюзов VPN также поддерживают про­токол РРТР. Протокол РРТР позволяет создавать защищенные каналы для обмена дан­ными по протоколам IP, IPX или NetBEUI. Данные этих протоколов упаковываются в кадры РРР и затем инкапсулируются посредством протокола РРТР в пакеты протокола IP, с помощью которого переносятся в зашифрованном виде через любую сеть TCP/IP. Пакеты, передаваемые в рамках сессии РРТР, имеют следующую структуру (рис. 10.1):

Описание технологии рис

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

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

В соответствии с моделью OSI протоколы инкапсулируют блоки данных protocol data unit (PDU) по принципу матрешки: TCP (транспортный уровень) инкапсулируется протоколом IP (сетевой уровень), который затем инкапсулируется PPP (на канальном уровне).

После того как туннельный протокол доставляет пакеты из начальной точки туннеля в конечную, выполняется деинкапсуляция.

Старина PPTP

PPTP инкапсулирует пакеты IP для передачи по IP-сети. Клиенты PPTP используют порт назначения 1723 для создания управляющего туннелем соединения. Этот процесс происходит на транспортном уровне модели OSI. После создания туннеля компьютер-клиент и сервер начинают обмен служебными пакетами.

В дополнение к управляющему соединению PPTP, обеспечивающему работоспособность канала, создается соединение для пересылки по туннелю данных. Инкапсуляция данных перед пересылкой через туннель происходит несколько иначе, чем при обычной передаче (например, при работе telnet). Инкапсуляция данных перед отправкой в туннель включает два этапа.

Сначала создается информационная часть PPP. Данные проходят сверху вниз, от прикладного уровня OSI до канального. Затем полученные данные отправляются вверх по модели OSI и инкапсулируются протоколами верхних уровней.

Таким образом, во время второго прохода данные достигают транспортного уровня. Однако информация не может быть отправлена по назначению, так как за это отвечает канальный уровень OSI. Поэтому PPTP шифрует поле полезной нагрузки пакета и берет на себя функции второго уровня, обычно принадлежащие PPP, т. е. добавляет к PPTP-пакету PPP-заголовок (header) и окончание (trailer). На этом создание кадра канального уровня заканчивается. Далее, PPTP инкапсулирует PPP-кадр в пакет Generic Routing Encapsulation (GRE), который принадлежит сетевому уровню. GRE инкапсулирует протоколы сетевого уровня, например IPX, AppleTalk, DECnet, чтобы обеспечить возможность их передачи по IP-сетям. Однако GRE не имеет возможности устанавливать сессии и обеспечивать защиту данных от злоумышленников. Для этого используется способность PPTP создавать соединение для управления туннелем. Применение GRE в качестве метода инкапсуляции ограничивает поле действия PPTP только сетями IP.

После того как кадр PPP был инкапсулирован в кадр с заголовком GRE, выполняется инкапсуляция в кадр с IP-заголовком. IP-заголовок содержит адреса отправителя и получателя пакета. В заключение PPTP добавляет PPP заголовок и окончание. На Рисунке 1 показана структура данных для пересылки по туннелю PPTP.

Рисунок 1. Структура данных для пересылки по туннелю PPTP.

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

-заголовок канального уровня, используемый внутри Интернета, например

заголовок кадра Ethernet;

- заголовок IP, содержащий адреса отправителя и получателя пакета;

-заголовок общего метода инкапсуляции для маршрутизации GRE (Generic Routing Encapsulation);

- исходный пакет РРР, включающий пакет IP, IPX или NetBEUI.

Принимающий узел сети извлекает из пакетов IP кадры РРР, а затем извлекает из кадра РРР исходный пакет IP, IPX или NetBEUI и отправляет его по локальной сети конкретному адресату. Многопротокольность инкапсулирующих протоколов канального уровня, к которым относится протокол РРТР, является их важным преимуществом перед протоколами защищенного канала более высоких уровней. Например, если в корпоративной сети используются IPX или NetBEUI, примене­ние протоколов IPSec или SSL просто невозможно, поскольку они ориентированы только на один протокол сетевого уровня IP.

Для аутентификации удаленного пользователя могут использоваться различные протоколы, применяемые для РРР. В реализации РРТР, включенной компанией Microsoft в Windows 98/NT/2000, поддерживаются следующие протоколы аутен­тификации: протокол распознавания по паролю PAP (Password Authentication Protocol), протокол распознавания при рукопожатии MSCHAP (Microsoft Challenge-Handshaking Authentication Protocol) и протокол распознавания EAP-TLS (Extensible Authentication Protocol - Transport Layer Security). При использовании протокола PAP идентификаторы и пароли передаются по линии связи в незашифрованном виде, при этом только сервер проводит аутентификацию клиента. При использо­вании протоколов MSCHAP и EAP-TLS обеспечиваются защита от повторного использования злоумышленником перехваченных пакетов с зашифрованным паро­лем и взаимная аутентификация клиента и VPN-сервера.

Шифрование с помощью РРТР гарантирует, что никто не сможет получить дос­туп к данным при пересылке через Интернет. Протокол шифрования МРРЕ (Microsoft Point-to-Point Encryption) совместим только с MSCHAP (версии 1 и 2) и EAP-TLS и умеет автоматически выбирать длину ключа шифрования при со­гласовании параметров между клиентом и сервером. Протокол МРРЕ поддержи­вает работу с ключами длиной 40, 56 или 128 бит. Протокол РРТР изменяет зна­чение ключа шифрования после каждого принятого пакета.

Для протокола РРТР определены две основные схемы применения:

О схема туннелирования при прямом соединении удаленного компьютера с Интернетом;

О схема туннелирования при подключении удаленного компьютера к Интерне­ту по телефонной линии через провайдера [28, 43].

Протокол PPP (Point-to-Point Protocol; RFC-2716, -2701, -2688, -2687, -2686, -2615, -2516, -2509, -2508, -2507, -2484, -2472, -2433, -2420, -2419, -2364, -2363, -2290, -2284, -2153, -2125, -2097, -2043, -1994, -1993, -1990, -1989, -1979, -1978, -1977, -1976, -1975, -1974, -1973, -1969, -1968, -1967, -1963, -1962, -1915, -1877, -1841, -1764, -1763, -1762, -1663, -1662, -1661, -1638, -1619, -1618, -1598, -1570, -1552, -1378, -1377, -1334, -1332, -1331, и STD-51, cмотри также www.spitbrook.destek.com:81/pptp.txt) предназначен для решения тех же задач, что и SLIP, но лишен многих его недостатков, он служит для передачи мультипротокольных дейтограмм от одного узла к другому. Сам по себе список RFC, приведенный выше, впечатляющ. Он говорит о том, что данный протокол относится к числу наиболее важных и широко используемых.

Рис. 10.3. Схема туннелирования при прямом подсоединении компьютера удаленного пользователя к Интернету

Это и понятно, большинство региональных сетей строится с использованием соединений точка-точка. PPP поддерживает, как асинхронный режим с 8 битами данных без бита четности (согласуется со свойствами последовательного интерфейса, имеющегося практически на всех ЭВМ), так и побитовый синхронный режим. Протокол содержит в себе три составные части:

· Метод инкапсуляции дейтограмм при передаче по последовательным коммуникационным каналам.

· Протокол LCP для установления, конфигурирования и тестирования информационных каналов

· Набор протоколов NCP для установки и конфигурирования различных протоколов сетевого уровня.

Протокол управления каналом (LCP - Link Control Protocol) является частью PPP. Идеология NCP реализована и в протоколе TCP. Каждый кадр PPP начинается и завершается флагом 0x7E. За стартовым флагом-октетом следует байт адреса, который всегда равен 0xFF. Формат кадра PPP представлен на рисунке 3.5.1. Кадр PPP может содержать только целое число байт. При инкапсуляции других пакетов в PPP используется бит-ориентированный протокол HDLC (High-level Data Link Control).

Рис. 3.5.1 Формат кадра в протоколе PPP

Поле адрес всегда содержит байт 0xFF (смотри также HDLC). Это указывает на то, что все станции должны принять этот кадр, и исключает необходимость выделения каких-то специальных адресов. Байт управления всегда равен 0x03, что указывает на ненумерованный тип кадра. По умолчанию кадры PPP передаются в режиме "без установления соединения". Если требуется надежная доставка, используется версия, описанная в RFC-1663. Двухоктетное поле протокол сходно по функции с полем тип в кадре Ethernet и определяет то, как следует интерпретировать информационное поле (см. табл. 3.5.1). Значение 0x0021 этого поля говорит о том, что последующее информационное поле содержит в себе IP-дейтограмму. Поле CRC (Cyclic Redundancy Check) представляет собой циклическую контрольную сумму, предназначенную для выявления ошибок при транспортировке PPP-кадра. Применение флагов-ограничителей кадра (0x7E) создает те же проблемы, о которых говорилось при описании SLIP-протокола, - эти байты не могут присутствовать в информационном поле. В синхронном режиме эта проблема решается на аппаратном уровне. При работе в асинхронном режиме для этого используется специальный ESC-символ, равный 0x7D. Когда этот esc-символ встречается в информационном поле, шестой бит в следующем за ним байте инвертируется. Так байт 0x7E будет преобразован в последовательность 0x7D, 0x5E, а байт 0x7D - в два байта 0x7D, 0x5D. Все символы с кодами меньше 0x20 также преобразуются в ESC-последовательности. Например, 0x07 будет преобразован в 0x7D, 0x27. Это необходимо делать, так как управляющие символы могут оказать непредсказуемые воздействия на режим работы драйверов или модемов, используемых в канале. Протокол PPP в отличие от SLIP допускает мультипротокольность и динамическое определение IP-адресов партнеров. Несмотря на определенные преимущества протокола PPP перед SLIP, последний распространен достаточно широко. Не трудно видеть, что все перечисленные физические среды используют последовательный формат передачи информации.

Протокол PPP при установлении соединения предусматривает процедуру аутентификации, которая является опционной (смотри рис. 3). После перехода на сетевой уровень вызывается NCP-протокол, который выполняет необходимую конфигурацию канала.

Рис. 3 Алгоритм установления соединения PPP

При обнаружении несущей или по инициативе клиента система может попытаться установить соединение. В случае успеха система переходит в фазу аутентификации. Если же и фаза аутентификации завершается благополучно, система выполняет подключение к сети (IP, IPX, Appletalk и т.д.), настройка сетевого уровня производится в рамках протокола NCP. Во всех остальных случаях производится возврат в исходное состояние. Процедура закрытия соединения осуществляется протоколом LCP.

В поле данных PPP-пакета может быть вложен один LCP-пакет, в этом случае в поле протокол должен быть записан код 0xC021 (Link Control Protocol). LCP-протокол служит для установления соединения путем обмена конфигурационными пакетами. По завершении этого обмена система переходит в фазу аутентификации (рис.3.5.2). Формат LCP-пакета показан на рис. 3.5.3.

Рис. 3.5.3. Формат заголовка LCP-пакета

Вслед за заголовком следует поле данных. Поле код (1 октет) идентифицирует модификацию LCP-пакета. Если получен пакет с неизвестным полем код, посылается пакет-отклик “отклонение кода”. Поле идентификатор (1 октет) служит для нахождения соответствия между запросами и откликами. Если получен пакет с неправильным идентификатором, он просто уничтожается. Двухоктетное поле длина определяет размер LCP-пакета, включая размер заголовка. Октеты принятого пакета за пределами, заданными полем длина игнорируются.

В качестве примера можно рассмотреть процедуру подключения персональной ЭВМ к серверу через модем. После того как модем маршрутизатора ответит на вызов модема-клиента и установит физическое соединение, ЭВМ посылает последовательность LCP-пакетов, вложенных в поля данных одного или нескольких PPP-кадров. Это позволяет выбрать необходимые параметры PPP. По завершении этой процедуры посылается последовательность NCP-пакетов, которые конфигурируют сетевой уровень. Вероятно, ЭВМ захочет работать со стеком протоколов TCP/IP, и по этой причине нуждается в IP-адресе. Если провайдер имеет N IP-адресов в резерве, он может подключить одновременно N ЭВМ. Присвоение IP-адреса осуществляется также в рамках NCP-протокола. После этого ЭВМ становится узлом Интернет. Завершение сессии и освобождение IP-адреса выполняется также через NCP-протокол. Разрыв соединения осуществляет протокол LCP.

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

Значение кода поля типа	Назначение опции
	Зарезервировано
	Maximum-Receive-Unit (указывает максимальный размер блока данных, который может быть принят)
	Authentication-Protocol (протокол аутентификации)
	Quality-Protocol (протокол качества)
	Magic-Number (магическое число, опция служит для выявления каналов с петлями обратной связи)
	Protocol-Field-Compression
	Address-and-Control-Field-Compression

Дата добавления: 2013-12-13