L2TP

L2TP
Название	Layer 2 Tunneling Protocol
Уровень (по модели OSI)	Сеансовый
Семейство	TCP/IP
Создан в	1999
Порт/ID	1701/UDP,500/UDP(for IKE, to manage encryption keys),4500/UDP(for IPSEC NAT-Traversal mode),50/ESP(for IPSEC),51/AH(for IPSEC)
Назначение протокола	построение VPN
Спецификация	RFC 2661

L2TP (англ. Layer 2 Tunneling Protocol — протокол туннелирования второго уровня) — в компьютерных сетях туннельный протокол, использующийся для поддержки виртуальных частных сетей. Главное достоинство L2TP состоит в том, что этот протокол позволяет создавать туннель не только в сетях IP, но и в таких, как ATM, X.25 и Frame Relay.

Несмотря на то, что L2TP действует наподобие протокола канального уровня модели OSI, на самом деле он является протоколом сеансового уровня и использует зарегистрированный UDP-порт 1701.

История

• 1996—1997 — конкуренция между протоколами L2F (Cisco) и PPTP (Microsoft)
• 1997 — соглашение между разработчиками о совместной разработке протокола L2TP
• 1999 — опубликован стандарт RFC 2661, описывающий протокол L2TP

Считается^[кем?], что протокол L2TP вобрал в себя лучшие черты L2F и PPTP.

Схема работы

На диаграмме показана схема работы протокола L2TP.

• LAN — локальные сети (Local Area Network), к которым подключаются через L2TP;
• ЭВМ — компьютер(ы), подключённые к локальной сети напрямую;
• LNS — L2TP Network Server, сервер доступа к локальной сети по L2TP;
• LAC — L2TP Access Concentrator, устройство для прозрачного подключения своих пользователей к LNS через сеть той или иной архитектуры;
• Удалённая система — система, желающая подключиться к LAN через L2TP;
• Клиент LAC — ЭВМ, которая сама для себя исполняет роль LAC для подключения к LNS;
• PSTN — коммутируемая телефонная сеть (Public Switched Telephone Network);
• Интернет, сеть Frame Relay или ATM — сети разных архитектур.

Целью здесь является туннелирование кадров PPP между удаленной системой или клиентом LAC и LNS, размещенном в LAN.

Удаленная система инициирует PPP-соединение с LAC через коммутируемую телефонную сеть PSTN (Public Switched Telephone Network). LAC затем прокладывает туннель для PPP-соединения через Интернет, Frame Relay или ATM к LNS, и таким образом осуществляется доступ к исходной LAN. Адреса удаленной системе предоставляются исходной LAN через согласование с PPP NCP. Аутентификация, авторизация и аккаунтинг могут быть предоставлены областью управления LAN, как если бы пользователь был непосредственно соединен с сервером сетевого доступа NAS.

LAC-клиент (ЭВМ, которая исполняет программу L2TP) может также участвовать в туннелировании до исходной LAN без использования отдельного LAC, если ЭВМ, содержащая программу LAC-клиента, уже имеет соединение с интернетом. Создается «виртуальное» PPP-соединение, и локальная программа L2TP LAC формирует туннель до LNS. Как и в вышеописанном случае, адресация, аутентификация, авторизация и аккаунтинг будут обеспечены областью управления исходной LAN.

Обзор протокола

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

Структура протокола:

PPP-кадры
информационные сообщения L2TP	управляющие сообщения L2TP
информационный канал L2TP (ненадёжный)	канал управления L2TP (надёжный)
Транспортировка пакетов (UDP, FR, ATM и т.д.)

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

Формат заголовка

Пакеты 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 (опц)......
Payload data

• Бит тип (T) характеризует разновидность пакета.

Он устанавливается равным 0 для информационных сообщений и 1 — для управляющих.

• Если бит длины (L) равен 1, поле длина присутствует.

Для управляющих сообщений этот бит должен быть равен 1.

• Биты x зарезервированы для будущих применений.

Все зарезервированные биты должны быть установлены равными 0 для исходящих сообщений и игнорироваться для входящих.

• Если бит последовательности (S) равен 1, присутствуют поля Ns и Nr.

Бит S для управляющих сообщений должен быть равен 1.

• Если бит смещения (O) равен 1, поле величины смещения присутствует.

Бит O для управляющих сообщений должен быть равен 0.

• Бит приоритета (Р) должен быть равен 0 для всех управляющих сообщений. Для информационных сообщений — если этот бит равен 1, это информационное сообщение имеет приоритет в очереди.
• Поле Ver указывает версию заголовка информационного сообщения L2TP.

Значение 1 зарезервировано для детектирования пакетов L2F в условиях, когда они приходят вперемешку с L2TP-пакетами. Пакеты, полученные с неизвестным значением поля Ver, отбрасываются.

• Поле Длина (опционально) указывает общую длину сообщения в октетах.
• ID-туннеля содержит идентификатор управляющего соединения. Идентификаторы туннеля L2TP имеют только локальное значение. То есть, разные концы одного туннеля должны иметь разные ID. ID-туннеля в каждом сообщении должно быть тем, которое ожидает получатель. ID-туннеля выбираются при формировании туннеля.
• ID-сессии определяет идентификатор для сессии данного туннеля. Сессии L2TP именуются с помощью идентификаторов, которые имеют только локальное значение. ID-сессии в каждом сообщении должно быть тем, которое ожидает получатель. ID-сессии выбираются при формировании сессии.
• Поле Ns определяет порядковый номер информационного или управляющего сообщения, начиная с нуля и увеличиваясь на 1 (по модулю 2¹⁶) для каждого посланного сообщения.
• Поле Nr содержит порядковый номер, который ожидается для следующего сообщения. Таким образом, Nr делается равным Ns последнего по порядку полученного сообщения плюс 1 (по модулю 2¹⁶). В информационных сообщениях Nr зарезервировано и, если присутствует (это определяется S- битом), должно игнорироваться при получении.
• Поле величина смещения (Offset Size), если имеется, специфицирует число октетов после заголовка L2TP, где должно начинаться поле данных. Содержимое заполнителя смещения не определено. Если поле смещения присутствует, заголовок L2TP завершается после завершающего октета заполнителя смещения.

Типы управляющих сообщений

Тип сообщения AVP определяет специфический тип посылаемого управляющего сообщения.

Управление управляющим соединением

• 0 (зарезервировано)
• 1 (SCCRQ) Start-Control-Connection-Request
• 2 (SCCRP) Start-Control-Connection-Reply
• 3 (SCCCN) Start-Control-Connection-Connected
• 4 (StopCCN) Stop-Control-Connection-Notification
• 5 (зарезервировано)
• 6 (HELLO) Hello

Управление вызовами (Call Management)

• 7 (OCRQ) Outgoing-Call-Request
• 8 (OCRP) Outgoing-Call-Reply
• 9 (OCCN) Outgoing-Call-Connected
• 10 (ICRQ) Incoming-Call-Request
• 11 (ICRP) Incoming-Call-Reply
• 12 (ICCN) Incoming-Call-Connected
• 13 (зарезервировано)
• 14 (CDN) Call-Disconnect-Notify

Сообщения об ошибках

• 15 (WEN) WAN-Error-Notify

Управление сессией PPP

• 16 (SLI) Set-Link-Info

Протокольные операции

Необходимая процедура установления PPP-сессии туннелирования L2TP включает в себя два этапа:

• установление управляющего канала для туннеля
• формирование сессии в соответствии с запросом входящего или исходящего вызова.

Туннель и соответствующий управляющий канал должны быть сформированы до инициализации входящего или исходящего вызовов. L2TP-сессия должна быть реализована до того, как L2TP сможет передавать PPP-кадры через туннель. В одном туннеле могут существовать несколько сессий между одними и теми же LAC и LNS.

PPP-туннелирование:

Управляющее соединение

Является первичным, которое должно быть сделано между LAC и LNS перед запуском сессии. Установление управляющего соединения включает в себя безопасную идентификацию партнера, а также определение версии L2TP, возможностей канала, кадрового обмена и т. д.

L2TP включает в себя простую, опционную, CHAP-подобную систему аутентификации туннеля в процессе установления управляющего соединения.

Установление сессии

После успешного установления управляющего соединения могут формироваться индивидуальные сессии. Каждая сессия соответствует одному PPP информационному потоку между LAC и LNS. В отличие от установления управляющего соединения, установление сессии является асимметричным в отношении LAC и LNS. LAC запрашивает LNS доступ к сессии для входных запросов, а LNS запрашивает LAC запустить сессию для работы с исходящими запросами.

Когда туннель сформирован, PPP-кадры от удаленной системы, получаемые LAC, освобождаются от CRC, канальных заголовков и т. п., инкапсулированных в L2TP, и переадресуются через соответствующий туннель. LNS получает L2TP-пакет и обрабатывает инкапсулированный PPP-кадр, как если бы он был получен через локальный интерфейс PPP.

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

Использование порядковых номеров в канале данных

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

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

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

Механизм keepalive (Hello)

Механизм keepalive используется L2TP для того, чтобы различать простои туннеля и длительные периоды отсутствия управления или информационной активности в туннеле. Это делается с помощью управляющих сообщений Hello после заданного периода времени, истекшего с момента последнего получения управляющего сообщения через туннель. При недоставке сообщения Hello туннель объявляется нерабочим, и система возвращается в исходное состояние. Механизм перевода транспортной среды в исходное состояние путём введения сообщений Hello гарантирует, что разрыв соединения между LNS и LAC будет детектирован на обоих концах туннеля.

Прерывание сессии

Прерывание сессии может быть инициировано LAC или LNS и выполняется путём посылки управляющего сообщения CDN. После того как последняя сессия прервана, управляющее соединение может быть также разорвано.

Разрыв управляющего соединения

Разрыв управляющего соединения может быть инициирован LAC или LNS и выполняется путём посылки одного управляющего сообщения StopCCN.

Реализация L2TP через специфическую среду

Протокол L2TP является самодокументируемым, работающим поверх уровня, который служит для транспортировки. Однако, необходимы некоторые детали^{[какие?]} подключения к среде, для того, чтобы обеспечить совместимость различных^{[каких?]} реализаций.

Соображения безопасности

Протокол L2TP сталкивается при своей работе с несколькими проблемами безопасности. Ниже рассмотрены некоторые подходы для решения этих проблем.

Безопасность на конце туннеля

Концы туннеля могут опционно выполнять процедуру аутентификации друг друга при установлении туннеля. Эта аутентификация имеет те же атрибуты безопасности, что и CHAP, и обладает разумной защитой против атак воспроизведения и искажения в процессе установления туннеля. Для реализации аутентификации LAC и LNS должны использовать общий секретный ключ.

Безопасность пакетного уровня

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

L2TP и IPsec

При работе поверх IP, IPsec (безопасный IP) предоставляет безопасность на пакетном уровне. Все управляющие и информационные пакеты L2TP в конкретном туннеле выглядят для системы IPsec как обычные информационные UDP/IP-пакеты. Помимо транспортной безопасности IP, IPsec определяет режим работы, который позволяет туннелировать IP-пакеты, а также средства контроля доступа, которые необходимы для приложений, поддерживающих IPsec. Эти средства позволяют фильтровать пакеты на основе характеристик сетевого и транспортного уровней. В модели L2TP-туннеля аналогичная фильтрация выполняется на PPP-уровне или сетевом уровне поверх L2TP.

Ссылки

•  (рус.) Протокол L2TP (Layer Two Tunneling Protocol) в Microsoft Technet
•  (рус.) Настройка L2TP VPN в Windows
•  (англ.) RFC 2661 Layer Two Tunneling Protocol «L2TP».
•  (англ.) RFC 2341 Cisco Layer Two Forwarding (Protocol) «L2F». (Предшественник L2TP.)
•  (англ.) RFC 2637 Point-to-Point Tunneling Protocol (PPTP). (Предшественник L2TP.)
•  (англ.) RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUS.
•  (англ.) RFC 2888 Secure Remote Access с помощью L2TP.
•  (англ.) RFC 3070 Layer Two Tunneling Protocol (L2TP) через Frame Relay.
•  (англ.) RFC 3145 L2TP Disconnect Cause Information.
•  (англ.) RFC 3193 Защита L2TP используя IPsec.
•  (англ.) RFC 3301 Layer Two Tunnelling Protocol (L2TP): ATM access network.
•  (англ.) RFC 3308 Layer Two Tunneling Protocol (L2TP) Differentiated Services.
•  (англ.) RFC 3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5).
•  (англ.) RFC 3371 Layer Two Tunneling Protocol «L2TP» Management Information Base.
•  (англ.) RFC 3437 Layer Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation.
•  (англ.) RFC 3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers: Internet Assigned Numbers Authority (IANA) Considerations Update.
•  (англ.) RFC 3573 Signaling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP).
•  (англ.) RFC 3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE).
•  (англ.) RFC 3931 Layer Two Tunneling Protocol — Version 3 (L2TPv3).
•  (англ.) RFC 4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP).
•  (англ.) IANA assigned numbers for L2TP.
•  (англ.) L2TP Extensions Working Group (l2tpext) — (where future standardization work is being coordinated).
•  (англ.) L2TP/IPSec from XP client to Windows 2003 Server — L2TP/IPSec from XP client to Windows 2003 Server.