L2TP

Протокол туннелирования уровня 2 (L2TP) — обычно используется для передачи сессий PPP от инициатора, известного как концентратор доступа L2TP (L2TP Access Concentrator, LAC), к серверу L2TP (L2TP Network Server, LNS). L2TP обычно используется для массового предоставления услуг широкополосного доступа абонентам. В этом сценарии LAC находится в сети провайдера и имеет подключение уровня 2 к мультиплексору доступа. LAC играет свою роль на этапе обнаружения (если используется PPPoE) и во время PPP согласования протокола управления соединением (Link Control Protocol, LCP). LAC также выполняет первоначальную аутентификацию абонента. Успешная аутентификация, обычно от RADIUS, указывает LAC, что кадры PPP от этого абонента должны быть туннелированы на LNS по указанному IP-адресу. Затем LAC туннелирует кадры PPP от этого абонента через туннель L2TP на LNS, где сессия PPP фактически завершается. Другими словами, для переноса сессий PPP требуются туннели L2TP.

L2TP использует два типа сообщений: управляющие сообщения и сообщения с данными. Управляющие сообщения используются для установления, обслуживания и разрыва туннелей и сессий. Для обеспечения расширяемости и максимальной совместимости полезная нагрузка управляющих сообщений кодируется с использованием пар атрибутов и значений (Attribute Value Pairs, AVP), некоторые из которых применимы ко всем управляющим сообщениям, а некоторые — к конкретным управляющим сообщениям. Заголовок L2TP содержит поля порядковых номеров, которые должны присутствовать в управляющих сообщениях для обеспечения надёжного канала управления L2TP, гарантирующего доставку. Сообщения с данными используются для инкапсуляции кадров PPP, передаваемых по туннелю. Сообщения с данными не передаются повторно в случае потери пакетов.

L2TP имеет общий фиксированный формат заголовка как для управляющих сообщений, так и для сообщений с данными, а бит типа (T) в заголовке используется для указания того, является ли пакет управляющим (1) или сообщением с данными (0). Пакет L2TP затем передаётся в транспортном протоколе, и хотя спецификации позволяют напрямую инкапсулировать L2TP через Frame Relay, ATM и UDP/IP, именно последний вариант используется практически повсеместно.

Установление управляющего туннеля L2TP

Перед передачей каких-либо пользовательских данных, LAC (инициатор) и LNS (терминатор) должны договориться о параметрах логического канала, который будет использоваться для управления. Этот процесс начинается с того, что LAC отправляет LNS пакет SCCRQ (Start-Control-Connection-Request) по UDP-порту 1701. В этом запросе содержатся базовые сведения об отправителе, такие как его имя хоста, а также список поддерживаемых атрибутов протокола, версия L2TP и предлагаемый идентификатор туннеля. Получив запрос, LNS формирует ответ SCCRP (Start-Control-Connection-Reply), в котором подтверждает или корректирует параметры и указывает собственный идентификатор туннеля. После обмена этими сообщениями LAC отправляет финальное подтверждение SCCCN (Start-Control-Connection-Connected), что завершает так называемое “рукопожатие” — туннель считается установленным.

Это управляющее соединение носит долгосрочный характер и существует отдельно от пользовательских сессий. Оно служит исключительно для обмена служебными сообщениями: поддержания связи (keepalive), уведомлений об ошибках и, что самое важное, для управления жизненным циклом пользовательских сессий внутри этого туннеля. Для поддержания активности туннеля узлы периодически асинхронно обмениваются служебными пакетами Hello и ZLB (Zero-Length Body).

Подготовка пользовательской сессии PPP

После создания туннеля L2TP становится возможным начать процесс установления сеанса PPP. Для установления сеанса в туннеле L2TP используется трёхсторонний обмен управляющими сообщениями, состоящий из входящего вызова ICRQ (Incoming Call Request), ответа на входящий вызов ICRP (Incoming Call Reply) и сообщения о соединении ICCN (Incoming Call Connected). Поскольку это управляющие сообщения, все они явно подтверждаются с помощью встроенных подтверждений или подтверждений ZLB.

Сообщение ICRQ отправляется от LAC к LNS, чтобы сообщить о получении входящего вызова (сеанса PPP) и о необходимости установления сеанса между двумя узлами в рамках этого вызова. Сообщение ICRQ предоставляет LNS достаточно информации о вызове, чтобы принять решение об ответе на него. Сообщение ICRQ содержит AVP типа сообщения Message Type и назначенного идентификатора сессии AVP Assigned Session ID, а также AVP серийного номера вызова Call Serial Number, которая может использоваться как на LAC, так и на LNS в качестве удобного указателя на вызов для устранения неполадок. ICRQ также может переносить дополнительные AVP, включая AVP номера вызывающего абонента Calling Number и информации о линии доступа (смотри RFC 5515), такие как идентификатор канала, удалённый идентификатор, фактическая скорость передачи данных в восходящем направлении и фактическая скорость передачи данных в нисходящем направлении.

ICRP отправляется от LNS к LAC в ответ на ICRQ, чтобы указать, что параметры в ICRQ были приемлемы и что LAC может продолжить вызов. ICRP содержит только два AVP: тип сообщения Message Type и присвоенный идентификатор сессии Assigned Session ID. Значения присвоенного идентификатора сессии являются локальными для каждого абонента и не являются согласованными или утверждёнными.

Последним сообщением в трехстороннем обмене данными, используемом для установления сеансов внутри туннеля, является ICCN. Оно отправляется от LAC к LNS, чтобы указать, что вызов был принят, и сеанс L2TP переходит в состояние “установлен” (established ). Оно также предоставляет дополнительную информацию о параметрах, которые были использованы для ответа на вызов и которые могли быть недоступны на момент отправки ICRQ (хотя, в большинстве случаев они будут доступны). Как минимум, ICCN должен содержать AVP типа сообщения Message Type, типа кадрирования Framing Type и скорости соединения TX Connect Speed. TX Connect Speed определяет скорость в битах в секунду с точки зрения трафика, поступающего от LAC к абоненту (т.е. скорость нисходящего потока LAC) и, для максимальной точности, может быть получена LAC из тегов PPP Broadband Forum Access Line Characteristic, вставленных узлом доступа. Скорость соединения TX может быть полезна для косвенной установки агрегированной скорости иерархического QoS (H-QoS). Это косвенный процесс, поскольку LNS не может напрямую определить и установить суммарную скорость на основе параметра TX Connect Speed ​​AVP, а вместо этого скорость TX Connect Speed ​​передаётся на RADIUS-сервер (используя параметр include-radius-attribute access-loop-option в политике аутентификации), который, в свою очередь, может передать суммарную скорость на LNS в VSA (Vendor Specific Attributes) с переопределением QoS.

Также в сообщении ICCN может присутствовать ряд дополнительных параметров AVP, предоставляющих информацию из процесса согласования протокола управления соединением LCP (Link Control Protocol) между LAC и абонентом. К ним относятся Initial Receive, Last Transmit и Last Receive LCP Config Requests, вместе с Proxy Authentication Type, Name, Challenge, и Response. Эти параметры позволяют LNS либо принудительно пересогласовать LCP, либо продолжить сеанс PPP и перейти к фазе IPCP. Последний параметр AVP, присутствующий в ICCN, — это параметр RX Connect Speed ​​AVP, который противоположен параметру TX Connect Speed ​​и определяет скорость в битах в секунду с точки зрения трафика, поступающего от абонента к LAC.

После завершения трехстороннего обмена управляющими сообщениями, необходимого для установления сессии, LNS аутентифицирует пользователя. RADIUS возвращает стандартные и специфичные для поставщика атрибуты, ранее определённые в файле пользователей. Успешная аутентификация позволяет LNS перейти к фазе IPCP (IP Control Protocol, RFC 1332) с абонентом. После завершения фазы IPCP создаётся экземпляр абонента, и сеанс L2TP становится активным. Параметры Tunnel-ID и Session-ID представляют собой локально сгенерированные числа, которые передаются в управляющих сообщениях L2TP.

Пользовательская сессия PPP

Сессия PPP состоит из шести фаз.

”Мёртвая” фаза (Dead Phase)

Физический уровень недоступен во время “мёртвой” фазы. PPP-соединение начинается и заканчивается этой фазой.

Когда два устройства обнаруживают, что физическое соединение между ними активировано, например, когда на физическом канале обнаруживаются несущие сигналы, оба устройства переходят из “мёртвой” фазы в фазу установления соединения.

После завершения PPP-соединения оба устройства снова переходят в “мёртвую” фазу.

Фаза установления соединения

В фазе установления соединения два устройства выполняют согласование LCP для определения режима работы SP (Single-link PPP) или MP (Multilink PPP), MRU, режима аутентификации и “волшебного числа” (Magic Number). После завершения согласования LCP (Link Control Protocol) два устройства переходят к следующему этапу. На этапе установления соединения статус LCP изменяется следующим образом:

• если канал недоступен (в “мёртвой” фазе), LCP находится в “Начальном” состоянии или состоянии “Запуск”. Когда физический уровень обнаруживает доступность канала, он отправляет событие “Up” на канальный уровень. После получения события канальный уровень изменяет статус LCP на “Запрос отправлен”. Затем устройства на обоих концах отправляют друг другу пакеты Configuration Request для настройки канала передачи данных.
• Если локальное устройство сначала получает пакет Configure-Ack от другого устройства, статус LCP изменяется с “Запрос отправлен” на “Подтверждение получено”. После того, как локальное устройство отправляет пакет Configurаtion Ack другому устройству, статус LCP изменяется с “Подтверждение получено” на Open.
• Если локальное устройство сначала отправляет пакет Configure-Ack удалённому устройству, статус LCP изменяется с Request-Sent на Ack-Sent. После того, как локальное устройство получает пакет Configure-Ack от удалённого устройства, статус LCP изменяется с Ack-Sent на Open. После перехода LCP в состояние Open начинается следующая фаза. Следующая фаза — это фаза аутентификации или сетевой фазы, в зависимости от того, требуется ли аутентификация.

Наличие и тип (PAP/CHAP) аутентификации согласуются в сообщениях Configureation Request и Configurаtion Ack.

Фаза аутентификации

Фаза аутентификации является необязательной. По умолчанию PPP не выполняет аутентификацию во время установления PPP-соединения. Если аутентификация требуется, протокол аутентификации должен быть указан в фазе установления соединения.

PPP предоставляет два режима аутентификации по паролю: аутентификация PAP и аутентификация CHAP.

Доступны два метода аутентификации: односторонняя и двусторонняя. При односторонней аутентификации устройство на одном конце выступает в роли аутентифицирующего устройства, а устройство на другом конце — в роли аутентифицируемого устройства. При двусторонней аутентификации каждое устройство выступает одновременно и в роли аутентифицирующего, и в роли аутентифицируемого устройства. На практике используется только односторонняя аутентификация.

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

PAP (Password Authentication Protocol) — это протокол двухшаговой аутентификации, передающий пароли в простом текстовом виде. Аутентифицируемое устройство отправляет локальное имя пользователя и пароль аутентифицирующему устройству. Аутентифицирующее устройство проверяет, находится ли полученное имя пользователя в списке пользователей. Если полученное имя пользователя присутствует в списке пользователей, аутентифицирующее устройство проверяет правильность полученного пароля.

Если пароль правильный, аутентификация проходит успешно. Если пароль неправильный, аутентификация завершается неудачно. Если полученное имя пользователя отсутствует в списке пользователей, аутентификация завершается неудачно.

Пакет PAP инкапсулирован в поле Information пакета PPP со значением поля Protocol 0xC023.

Пакет PAP содержит следующие поля:

• В поле Code значение 0x01 означает сообщение Authenticate-Request, 0x02 означает сообщение Authenticate-Ack, 0x03 означает сообщение Authenticate-Nak.
• Поле identifer — порядковый номер сообщения для его идентификации.
• Поле Length — длина PAP-пакета, включая длины полей Code, Identifier, Length и Data.
• Поле Data — содержит передаваемые данные в зависимости от поля Code.

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

CHAP (Challenge Handshake Authentication Protocol) — это протокол трёхшаговой аутентификации, когда в открытом виде передаются только имена пользователей, но не пароли, что обеспечивает бóльшую безопасность.

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

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

В этом сценарии аутентифицирующее устройство инициирует запрос на аутентификацию, отправляя аутентифицируемому устройству пакет Challenge, содержащий случайное число и локальное имя пользователя.

После получения пакета Challenge через интерфейс аутентифицируемое устройство проверяет, настроен ли пароль CHAP на интерфейсе. Если пароль настроен, аутентифицируемое устройство использует алгоритм хеширования для вычисления хеш-значения на основе идентификатора пакета, пароля CHAP и случайного числа в пакете, а затем отправляет аутентифицирующему устройству пакет Response, содержащий хеш-значение и локальное имя пользователя.

Если пароль не задан, аутентифицируемое устройство ищет пароль, соответствующий имени пользователя аутентифицирующего устройства в полученном пакете, использует алгоритм хеширования для вычисления хеш-значения на основе идентификатора пакета, пароля, соответствующего имени пользователя, и случайного числа в пакете, а затем отправляет Response-пакет, содержащий хеш-значение и локальное имя пользователя, аутентифицирующему устройству.

Аутентифицирующее устройство использует алгоритм хеширования для вычисления хеш-значения на основе идентификатора пакета, локально сохраненного пароля аутентифицируемого устройства и случайного числа в пакете Challenge, а затем сравнивает хеш-значение с хеш-значением в пакете Response. Если два хеш-значения совпадают, аутентификация проходит успешно. В противном случае аутентификация завершается неудачей.

Если на аутентифицирующему устройству не известно имя пользователя, аутентифицирующее устройство инициирует запрос на аутентификацию, отправляя аутентифицируемому устройству пакет Challenge, содержащий случайное число.

После получения пакета запроса (Challenge packet) аутентифицируемое устройство использует алгоритм хеширования для вычисления хеш-значения на основе идентификатора пакета, пароля CHAP и случайного числа в пакете, а затем отправляет ответный пакет (Response packet), содержащий хеш-значение и имя пользователя, аутентифицирующему устройству.

Аутентифицирующее устройство использует алгоритм хеширования для вычисления хеш-значения на основе идентификатора пакета, локально сохранённого пароля аутентифицируемого устройства и случайного числа в пакете запроса, а затем сравнивает хеш-значение с хеш-значением в пакете ответа. Если оба хеш-значения совпадают, аутентификация проходит успешно. В противном случае аутентификация завершается неудачно.

Пакет CHAP содержит следующие поля:

• В поле Code значение 0x01 означает сообщение Challenge, 0x02 означает сообщение Response, 0x03 означает сообщение Success, 0x04 означает сообщение Failure.
• Identifier — порядковый номер сообщения для сопоставления Challenge и Response (какой запрос к какому ответу относится).
• Length — длина пакета CHAP, включая длину полей Code, Identifier, Length и Data.
• Data — содержит передаваемые данные в зависимости от поля Code.

Сетевая фаза

Фаза Network Layer Protocol, или сетевая фаза протокола PPP, является заключительным этапом установления соединения перед началом передачи пользовательских данных. Её основная цель — независимо настроить параметры для каждого сетевого протокола, который должен работать поверх уже созданного и аутентифицированного PPP-канала. Для этого используются специализированные подпротоколы, объединённые общим названием NCP (Network Control Protocol). Каждый сетевой протокол имеет свой NCP: например, IPCP для IPv4, IPv6CP для IPv6 или IPXCP для устаревшего IPX.

Процесс согласования для каждого NCP следует чёткой последовательности, аналогичной фазе установления канала LCP. Инициатор, которым часто выступает клиентское оборудование, отправляет пакет Configure-Request, содержащий список опций для настройки. В случае с IPCP это обычно запрос на назначение IP-адреса (часто обозначаемый как 0.0.0.0), адресов DNS-серверов и, возможно, параметров сжатия заголовков. Удалённая сторона анализирует запрос и может ответить несколькими способами: Configure-Ack для подтверждения приемлемой конфигурации, Configure-Nak для предложения альтернативных значений, или Configure-Reject для отклонения неподдерживаемых опций. Сетевая фаза не является строго одноразовым событием. В течение всей жизни соединения NCP может быть повторно активирован для динамического обновления параметров, например, при получении новых адресов DNS.

Завершение использования конкретного протокола также управляется через NCP с помощью обмена пакетами Terminate-Request и Terminate-Ack, что не обязательно приводит к разрыву всего PPP-соединения. На практике успешное завершение сетевой фазы, особенно для IPCP, является тем моментом, когда на интерфейсе маршрутизатора появляется IP-адрес и устанавливаются маршруты, делая PPP-канал полностью работоспособным для передачи данных.

Завершающая (Termination) фаза

Завершающая фаза (Termination) протокола PPP — это контролируемый процесс разрыва установленного соединения. Её инициирует любая из сторон, когда необходимо завершить сессию — будь то плановое отключение, потеря физической связи, тайм-аут или неудачная аутентификация. Ключевым протоколом на этом этапе снова выступает LCP (Link Control Protocol), который обеспечивает упорядоченный демонтаж канала.

Устройство, инициирующее разрыв, отправляет пакет LCP Terminate-Request. Получив его, противоположная сторона обязана ответить пакетом LCP Terminate-Ack, подтверждая получение запроса на разрыв. Этот обмен гарантирует, что обе стороны синхронно понимают факт завершения сессии, предотвращая состояния «полуразорванного» соединения.

После успешного обмена Terminate-Request и Terminate-Ack протокол PPP выполняет ряд важных финальных действий. Он уведомляет все активные NCP (Network Control Protocol), такие как IPCP, о необходимости завершить свою работу, что приводит к удалению сетевых настроек (например, IP-адресов). Затем соединение официально возвращается в исходное состояние — в “мёртвую” фазу, ожидая нового сигнала физического уровня для возможного последующего установления связи.

Передача данных

С момента установления пользовательской сессии PPP-кадры будут передаваться внутри L2TP-туннеля. LAC выполняет инкапсуляцию: он “оборачивает” исходный PPP-кадр (содержащий, например, IP-пакет) в заголовок L2TP. Этот заголовок содержит два ключевых поля: Tunnel ID и Session ID. Tunnel ID позволяет маршрутизаторам в сети правильно направить пакет к нужному LNS, а на самом LNS именно Session ID указывает, какому конкретному пользователю и виртуальному интерфейсу принадлежат данные. Полученный L2TP-пакет затем помещается в стандартную UDP-дейтаграмму и передаётся по IP-сети. LNS выполняет обратную операцию: принимает UDP-пакет, по Tunnel ID находит нужный туннель, а по Session ID — конкретную сессию, после чего извлекает исходный PPP-кадр, обрабатывает его и направляет “чистый” IP-трафик во внутреннюю сеть.