L2TP

1996-1997 - конкуренція між протоколами L2F (Cisco) і PPTP (Microsoft) 1997 - угода між розробниками про спільну розробку протоколу L2TP 1999 - опублікований стандарт RFC 2661, що описує протокол L2TP Вважається, що протокол L2TP увібрав у себе найкращі риси PPTP і L2F. Опублікований у 1999 році як пропонований стандарт RFC 2661, L2TP базувався головним чином на двох більш ранніх тунельних протоколах для PPP: протоколі естафетної передачі на другому рівні (L2F) від Cisco та тунельному протоколі точка-точка (PPTP) від Microsoft. По загальній думці, протокол L2TP увібрав в себе всі переваги PPTP і L2F. Нова версія цього протоколу, L2TPv3, була опублікована як запропонований у 2005 році стандарт RFC 3931. Головною перевагою L2TP є те, що цей протокол дозволяє створювати тунель не лише в мережах IP, але і в таких, як ATM, X.25 та frame relay.

Дистанційна система ініціює PPP-з'єднання з LAC через телефонну мережу PSTN. 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, щоб гарантувати доставку. Інформаційні повідомлення при втраті не пересилаються повторно.

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

Керуюче повідомлення має порядковий номер, який використовується в керуючому каналі для забезпечення надійної доставки. Інформаційні повідомлення можуть використовувати порядкові номери, щоб відновити порядок пакетів і детектувати втрату кадрів. Всі коди надсилаються в порядку, прийнятому для мереж.

L2TP застосовує як транспортний протокол UDP і використовує однаковий формат повідомлень як для управління тунелем, так і для пересилання даних. L2TP в реалізації Microsoft використовує як контрольних повідомлень пакети UDP, що містять шифровані пакети PPP.

L2TP часто використовують для створення тунелю через VPN^{[джерело?]}.

Для забезпечення безпеки L2TP-пакетів зазвичай використовують протокол IPsec, який надає конфіденційність, аутентифікацію та цілісність. Комбінація цих двох протоколів відома як L2TP/IPsec.

Кінцеві вузли L2TP тунелю називаються LAC (L2TP концентратора доступу) і LNS (L2TP Server Network). LAC є ініціатором тунелю, тоді LNS - сервер, який очікує нових тунелів. Коли тунель встановлено, мережевий трафік між вузлами є двонаправленим. Потім, протоколи більш високих рівнів запускаються всередині тунелю L2TP. Для цього, L2TP сесія встановлюється всередині тунелю для кожного протоколу вищого рівня (наприклад, для ПКС). Як ЛАК, так і LNS можуть ініціювати сесії. Трафік для кожної сесії ізолюється за допомогою L2TP, тому можливо налаштувати кілька віртуальних мереж через один тунель.

Пакети L2TP для контрольного та інформаційного каналів використовують один і той же формат заголовка:

• Біт тип (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 (по модулю 216) для кожного посланого повідомлення.
• Поле Nr містить порядковий номер, який очікується для наступного повідомлення. Таким чином, Nr робиться рівним Ns останнього по порядку отриманого повідомлення плюс 1 (по модулю 216). В інформаційних повідомленнях, 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.

Є первинним, яке має бути реалізовано між 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 використовується L2TP для того, щоб розрізняти простої тунелю і тривалі періоди відсутності керування або інформаційної активності в тунелі. Це робиться за допомогою керуючих повідомлень Hello після заданого періоду часу, який минув з моменту останнього одержання керуючого повідомлення через тунель. При недоставленні повідомлення Hello тунель оголошується неробочим, і система повертається в початковий стан. Механізм переведення транспортної середовища в початковий стан шляхом введення повідомлень Hello гарантує, що розрив з'єднання між LNS і LAC буде детектувати на обох кінцях тунелю.

Переривання сесії може бути ініційовано LAC або LNS і виконується шляхом посилки керуючого повідомлення CDN. Після того як остання сесія перервана, керуюче з'єднання може бути також розірвано.

Розрив контрольного з'єднання може бути ініційований LAC або LNS і виконується шляхом посилки одного керуючого повідомлення StopCCN.

Інкапсуляція пакетів L2TP/IPSec виконується в два етапи.

1. Інкапсуляція L2TP. Кадр PPP (IP-датаграма або IPX-датаграма) полягає в оболонку з заголовком L2TP і заголовком UDP.

2. Інкапсуляція IPSec. Потім отримане L2TP-повідомлення полягає в оболонку з заголовком і трейлером IPSec ESP (Інкапсуляція Security Payload), трейлером перевірки автентичності IPSec, що забезпечує цілісність повідомлення та перевірку справжності, і заголовком IP. У заголовку IP-адреси джерела і приймача відповідають VPN-клієнта і VPN-сервера.

На завершення L2TP виконує другий PPP-інкапсуляцію для підготовки даних до передачі.

L2TP пакет складається з :

Значення полів:

Flags and version

Прапори, вказують тип пакету (керуючий або дані) і наявність полів з довжиною, номером послідовності і зрушенням.

Length (опціонально)

Повна довжина повідомлення в байтах, є лише якщо встановлено прапор довжини.

Tunnel ID

Відображає ідентифікатор керуючого з'єднання.

Session ID

Відображає ідентифікатор сесії всередині тунелю.

Ns (опціонально)

Послідовний номер для даних або керуючого повідомлення, починаючи з 0 і збільшуючись на одиницю (за модулем 2 ¹⁶ ) для кожного відправленого повідомлення. Існує, коли встановлений відповідний прапор.

Nr (опціонально)

Послідовний номер повідомлення, очікуваного для прийняття. Nr встановлюється як Ns останнього отриманого повідомлення плюс один (за модулем 2 ¹⁶ ). У повідомленнях з даними, Nr зарезервований, і, якщо існує, зобов'язаний бути проігноровано.

Offset Size (опціонально)

Визначає, де знаходяться дані після L2TP заголовка. Якщо це поле існує, L2TP заголовок закінчується після останнього байта offset padding. Існує, коли встановлений відповідний прапор.

Offset Pad (опціонально)

Змінної довжини, вказується offset size. Вміст поля невизначено.

Payload data

Самі передані дані. Змінної довжини (Максимальний розмір = Максимальному розміром UDP пакету - розмір заголовка L2TP)

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

Протокол L2TP стикається при своїй роботі з кількома проблемами безпеки. Нижче розглянуті деякі підходи для вирішення цих проблем.

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

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

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

• Список портів [Архівовано 4 червня 2001 у Wayback Machine.] на сайті IANA
• Протокол L2TP (Layer Two Tunneling Protocol) [Архівовано 4 червня 2011 у Wayback Machine.]
• вибираємо протокол VPN [Архівовано 11 квітня 2011 у Wayback Machine.]
• RFC 2661 Layer Two Tunneling Protocol «L2TP»
• RFC 2341 Cisco Layer Two Forwarding (Protocol) «L2F». (A predecessor to L2TP)
• RFC 2637 Point-to-Point Tunneling Protocol (PPTP). (A predecessor to 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 [Архівовано 24 травня 2011 у Wayback Machine.]
• 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 (англ.)
• Настройка L2TP VPN в Windows [Архівовано 20 травня 2011 у Wayback Machine.] (рос.)
• (рос.) Протокол L2TP (Layer Two Tunneling Protocol) [Архівовано 4 червня 2011 у Wayback Machine.] в Microsoft Technet
• (рос.) Настройка L2TP VPN в Windows [Архівовано 20 травня 2011 у Wayback Machine.]

Це незавершена стаття про комп'ютерні мережі. Ви можете допомогти проєкту, виправивши або дописавши її.