Описание этих трех протоколов второго (канального) уровня традиционно объединяется из-за их функционального сходства. Layer 2 Forwarding (L2F) – это продукт компании Cisco Systems, Inc. [RFC-2341], Point-to-Point Tunneling Protocol (PPTP) – компании Microsoft [RFC-2637], a Layer 2 Tunneling Protocol (L2TP) – это совместная разработка Cisco Systems, Inc. и Microsoft в рамках рабочей группы IETF [RFC-2661]. Совместная разработка была предпринята как раз по причине сходной функциональности для развития преимуществ первых двух протоколов.
Основной отличительной чертой этих трех протоколов является их способность работать по телефонным (dial-up) линиям поверх протоколов РРР (Point-to-Point Protocol), SLIP (Serial Line Internet Protocol) и предоставлять возможность независимой работы протоколам третьего (сетевого) уровня – IP, IPX, AppleTalk. Поскольку речь идет все же о телефонных линиях, сети, основанные на использовании этих протоколов, называют VPDN (Virtual Private Dial-up Network – Виртуальная частная сеть с коммутируемым доступом), в отличие от интернет-ориентированных частных сетей VPN (Virtual Private Network).
L2F
Описывая L2F, разработчики из компании Cisco Systems, Inc. выделяют следующие три протокола, или группы протоколов, необходимых для создания туннелей в защищенной сети:
- пассажирский протокол (англ. passenger protocol) – это тот протокол, который будет инкапсулирован (РРР, SLIP и т. п.);
- инкапсулирующий протокол (англ. encapsulating protocol) – это тот протокол, который отвечает за создание, поддержание и снятие туннеля (в нашем случае – L2F);
- несущий протокол (англ. carrier protocol) – используется для транспортировки инкапсулированного протокола (чаще всего это IP), транспортный протокол для L2F – это UDP, порт 1701.
Типовой сценарий построения туннеля следующий:
1. Удаленный пользователь устанавливает соединение по телефонной линии (например, РРР) к серверу сетевого доступа {Network Access Server – NAS) провайдера, предоставляющего услуги несущего протокола (например, интернет-провайдер с IP).
2. NAS производит идентификацию/аутентификацию пользователя на основе данных самого провайдера. Для уменьшения размера базы данных по пользователям у провайдера можно, если это допускается корпоративной политикой организации пользователя, производить идентификацию на основе не индивидуального имени пользователя, а общекорпоративного, доменного имени.
3. NAS инициирует создание туннеля (L2F) к шлюзу доступа (gateway) сети, к которой хочет получить доступ удаленный пользователь.
4. Шлюз анализирует аутентификационные данные пользователя на основе собственной базы безопасности и допускает или не допускает создание туннеля (в нашем примере – допускает).
5. NAS регистрирует создание туннеля и, при необходимости, объем передаваемого трафика.
6. Шлюз производит необходимый обмен информацией с удаленным пользователем в рамках РРР (например, присваивает IP-адрес).
7. Устанавливается туннель между удаленным пользователем и шлюзом.
Следует понимать, что здесь "туннель" используется для обозначения того, что протокол РРР функционирует прозрачно от удаленного пользователя до шлюза, как если бы пользователь устанавливал соединение напрямую со шлюзом, минуя NAS. При этом данные не обязательно защищены криптографически на всем пути от пользователя до шлюза, туннель только предоставляет возможность применения всех механизмов аутентификации, авторизации и учета, поддерживаемых РРР.
РРТР
Говоря о РРТР, используют понятия Концентратор доступа РРТР (РРТР Access Concentrator – РАС) и Сетевой сервер РРТР (РРТР Network Server – PNS), которые образуют оконечные точки туннеля. При этом функционально разделяют обязанности NAS:
по обеспечению физического интерфейса к телефонной линии;
логическое окончание (termination) сессии Протокола управления связью (LCP – Link Control Protocol) и Протокола управления сетью (NCP – Network Control Protocol) в РРР;
аутентификации средствами РРР;
агрегирование и связывание каналов в Мультиканальном протоколе РРР;
мультипротокольную маршрутизацию;
переключение (англ. bridging) между физическими интерфейсами.
Таким образом, РАС присоединяется к телефонной линии, a PNS выполняет серверную часть.
В РРТР-соединении существуют две основных составляющих:
- Управляющее соединение (англ. Control Connection) – обычное TCP-соединение по порту 1723; и
- IP-туннель между РАС и PNS, который инкапсулирует РРР-пакеты по протоколу GRE (General Routing Encapsulation – Общая маршрутная инкапсуляция).
Управляющее соединение отвечает за установление, управление и прекращение туннелируемой сессии, по нему PNS информируется о входящем вызове, а РАС уведомляется о необходимости сделать исходящий вызов. Туннель обеспечивает перенос РРР-пакетов, принадлежащих данной сессии, мультиплексирование различных сессий в одном туннеле, а также включает методы управления коллизиями и контроля ошибок.
Коснемся немного протокола GRE по последней доступной спецификации [RFC-2784]. Он предназначен для инкапсуляции некоего протокола сетевого уровня по другому протоколу сетевого уровня.
Управляющий канал РРТР
Управляющие сообщения пересылаются между клиентом и сервером РРТР для создания туннеля РРТР и управления им. Хотя РРТР позволяет туннелировать поверх РРР различные сетевые протоколы, для сообщений управления служат ТСР-датаграммы. После установки TCP-соединения между клиентом и сервером TCP происходит обмен следующими управляющими сообщениями РРТР:
Start-Control-Connection-Request (Запрос на создание управляющего канала);
Start-Control-Connection-Reply (Ответ на запрос о создании управляющего канала);
Stop-Control-Connection-Request (Запрос на закрытие управляющего канала);
Stop-Control-Connection-Reply (Ответ на запрос о закрытии управляющего канала);
Echo-Request (Эхо-запрос);
Echo-Reply (Эхо-ответ);
Outgoing-Call-Request (Запрос исходящего вызова);
Outgoing-Call-Reply (Ответ на запрос исходящего вызова);
Incoming-Call-Request (Запрос входящего вызова);
Incoming-Call-Reply (Ответ на запрос входящего вызова);
Incoming-Call-Connected (Подтверждение установки входящего соединения);
Call-Clear-Request (Запрос на отмену вызова);
Call-Disconnect-Notify (Извещение о разрыве соединения);
WAN-Error-Notify (Извещение об ошибке глобальной сети);
Set-Link-Info (Запись информации о канале).
Запрос на создание и закрытие канала и соответствующие ответы предназначены для установки соединения и обмена информацией о свойствах клиента и сервера, в том числе о версии РРТР, о максимальном числе индивидуальных сеансов и об имени пославшего запрос узла. Сообщения о закрытии канала предназначены для завершения соединения. После закрытия управляющего канала все связанные с соответствующим туннелем сеансы также завершаются.
Эхо-сообщения позволяют контролировать управляющий канал и обнаруживать отказ. Если в течение 60 с после эхо-запроса не приходит ответ, соединение разрывается.
После установки соединения существующий виртуальный туннель может служить для обмена данными между клиентом и сервером РРТР. Посылаемый клиентом пакет сначала шифруется, а затем помещается внутрь IP-пакета и направляется серверу РРТР Поскольку исходный РРР-пакет зашифрован, его пересылка по Internet безопасна. Даже перехватив IP-пакет, нарушитель будет располагать только информацией из заголовка пакета. Содержащиеся в РРР-пакете данные защищаются криптографическим алгоритмом.
Различие между методами туннелирования, применяемыми протоколами РРТР и IPSec, состоит в том, что в случае IPSec для каждого сеанса между клиентом и сервером создается новая защищенная связь, а РРТР мультиплексирует множество сеансов связи между клиентом и сервером в единственном туннеле.
L2TP
Поскольку L2TP является совместным творчеством компаний Cisco Systems, Inc. и Microsoft, предназначенным для объединения всего лучшего, что было в двух исходных протоколах, будем надеяться, что он является наиболее перспективным и остановимся на нем подробнее.
Из РРТР взято понятие двух оконечных точек туннеля – Концентратора Доступа и Сетевого Сервера, терминология взята применительно к L2TP – LAC (L2TP Access Concentrator) и LNS (L2TP Network Server). Из L2F взято использование UDP с номером порта 1701 в качестве транспорта по IP.
LAC – узел, который действует в качестве одной из сторон L2TP-туннеля и является партнером для LNS (L2TP Network Server). LAC размещается между LNS и удаленной системой, переадресуя им пакеты. Пакеты, посланные от LAC к LNS, требуют туннелирования с помощью протокола L2TP, как это определено в данном документе. Соединение между LAC и удаленной системой является локальным (смотри: клиент LAC) или осуществляется через канал PPP.
LNS – у зел, который работает в качестве одного из концов L2TP туннеля, и является партнером для LAC (L2TP Access Concentrator). LNS является логической терминальной точкой PPP-сессии, которая организует туннель между удаленной системой и LAC.
L2TP (рис. 22.34) использует два типа сообщений:
1. Управляющие сообщения для установления, поддержания и снятия туннеля и вызовов.
2. Сообщения данных для инкапсуляции РРР пакетов в туннель.
В качестве транспорта пакетов используется UDP для IP, но также возможно использование ATM, Frame Relay и т. п.
Канал данных описывается в общем случае как канал ненадежной доставки (потерянные сообщения данных не передаются заново). Управляющий канал описывается как надежный за счет последовательной нумерации пакетов и повторной передачи пропущенных. Опционально такую нумерацию возможно поддерживать и для канала данных.
Необходимая процедура установления PPP-сессии туннелирования L2TP включает в себя два этапа:
1. Установление управляющего канала для туннеля.
2. Формирование сессии в соответствии с запросом входящего или исходящего вызова.
На диаграмме показана схема работы протокола L2TP. Целью здесь является туннелирование кадров PPP между удаленной системой или клиентом LAC и LNS, размещенной в LAN.
Удаленная система инициирует PPP-соединение с LAC через коммутируемую телефонную сеть PSTN. LAC затем прокладывает туннель для PPP-соединения к LNS, посредством чего осуществляется доступ к исходной LAN (Home LAN). Адреса удаленной системе предоставляются исходной LAN через согласование с PPP NCP. Аутентификация, авторизация и аккоунтинг могут быть предоставлены областью управления LAN, как если бы пользователь был непосредственно соединен с сервером сетевого доступа NAS.
LAC-клиент (ЭВМ, которая исполняет программу L2TP) может также участвовать в туннелировании до исходной LAN без использования отдельного LAC. В этом случае, ЭВМ, содержащая программу LAC клиента, уже имеет соединение с Интернет. Затем создается "виртуальное" PPP-соединение и локальная программа L2TP LAC формирует туннель до LNS. Как и в выше описанном случае, адресация, аутентификация, авторизация и аккоунтинг будут обеспечены областью управления исходной LAN.
Управляющее соединение является первичным, которое должно быть реализовано между LAC и LNS, прежде чем запускать сессию. Установление управляющего соединения включает в себя безопасную идентификацию партнера, а также определение версии L2TP, возможностей канала, кадрового обмена и т.д.. Для установления управляющего соединения осуществляется обмен тремя сообщениями.
После успешного установления управляющего соединения, могут формироваться индивидуальные сессии. Каждая сессия соответствует одному PPP информационному потоку между LAC и LNS. В отличие от установления управляющего соединения, установление сессии является асимметричным в отношении LAC и LNS. LAC запрашивает LNS доступ к сессии для входных запросов, а LNS запрашивает LAC запустить сессию для работы с исходящими запросами.
