L2TP (англ. Layer 2 Tunneling Protocol — протокол тунелювання другого рівня) — в комп'ютерних мережах тунельний протокол, використовується для підтримки віртуальних приватних мереж. L2TP не забезпечує шифрування та конфіденційність сам по собі, він спирається на інкапсульований протокол для забезпечення конфіденційності.
Попри те, що L2TP діє подібно протоколу Канального рівня моделі OSI, в дійсності він є протоколом Сеансового рівня і використовує зареєстрований UDP-порт 1701.
Історія і майбутнє
1996-1997 - конкуренція між протоколами L2F (Cisco) і PPTP (Microsoft) 1997 - угода між розробниками про спільну розробку протоколу L2TP 1999 - опублікований стандарт RFC 2661, що описує протокол L2TP Вважається, що протокол L2TP увібрав у себе найкращі риси PPTP і L2F. Опублікований у 1999 році як пропонований стандарт RFC 2661, L2TP базувався головним чином на двох більш ранніх тунельних протоколах для PPP: протоколі естафетної передачі на другому рівні () від 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, щоб гарантувати доставку. Інформаційні повідомлення при втраті не пересилаються повторно.
Структура протоколу:
PPP кадри | |
L2TP інформаційні повідомлення | L2TP управляючі повідомлення |
L2TP інформаційний канал (ненадійний) | L2TP канал управління (надійний) |
Транспортування пакетів (UDP, FR, ATM тощо) |
Керуюче повідомлення має порядковий номер, який використовується в керуючому каналі для забезпечення надійної доставки. Інформаційні повідомлення можуть використовувати порядкові номери, щоб відновити порядок пакетів і детектувати втрату кадрів. Всі коди надсилаються в порядку, прийнятому для мереж.
Опис
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 для контрольного та інформаційного каналів використовують один і той же формат заголовка:
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 (по модулю 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 (Hello)
Механізм 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 пакета
L2TP пакет складається з :
Біти 0-15 | Біти 16-31 |
---|---|
Flags and Version Info | Length (опціонально) |
Tunnel ID | Session ID |
Ns (опціонально) | Nr (опціонально) |
Offset Size (опціонально) | Offset Pad (опціонально)…… |
Payload data |
Значення полів:
- Flags and version
- Прапори, вказують тип пакету (керуючий або дані) і наявність полів з довжиною, номером послідовності і зрушенням.
- Length (опціонально)
- Повна довжина повідомлення в байтах, є лише якщо встановлено прапор довжини.
- Tunnel ID
- Відображає ідентифікатор керуючого з'єднання.
- Session ID
- Відображає ідентифікатор сесії всередині тунелю.
- Ns (опціонально)
- Послідовний номер для даних або керуючого повідомлення, починаючи з 0 і збільшуючись на одиницю (за модулем 2 16 ) для кожного відправленого повідомлення. Існує, коли встановлений відповідний прапор.
- Nr (опціонально)
- Послідовний номер повідомлення, очікуваного для прийняття. Nr встановлюється як Ns останнього отриманого повідомлення плюс один (за модулем 2 16 ). У повідомленнях з даними, Nr зарезервований, і, якщо існує, зобов'язаний бути проігноровано.
- Offset Size (опціонально)
- Визначає, де знаходяться дані після L2TP заголовка. Якщо це поле існує, L2TP заголовок закінчується після останнього байта offset padding. Існує, коли встановлений відповідний прапор.
- Offset Pad (опціонально)
- Змінної довжини, вказується offset size. Вміст поля невизначено.
- Payload data
- Самі передані дані. Змінної довжини (Максимальний розмір = Максимальному розміром UDP пакету - розмір заголовка L2TP)
Реалізація 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.
Посилання
- Список портів [ 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.]
- — (where future standardization work is being coordinated)
- — 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.]
Ця стаття потребує додаткових для поліпшення її . (січень 2016) |
Це незавершена стаття про комп'ютерні мережі. Ви можете проєкту, виправивши або дописавши її. |
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
L2TP angl Layer 2 Tunneling Protocol protokol tunelyuvannya drugogo rivnya v komp yuternih merezhah tunelnij protokol vikoristovuyetsya dlya pidtrimki virtualnih privatnih merezh L2TP ne zabezpechuye shifruvannya ta konfidencijnist sam po sobi vin spirayetsya na inkapsulovanij protokol dlya zabezpechennya konfidencijnosti Popri te sho L2TP diye podibno protokolu Kanalnogo rivnya modeli OSI v dijsnosti vin ye protokolom Seansovogo rivnya i vikoristovuye zareyestrovanij UDP port 1701 Istoriya i majbutnye1996 1997 konkurenciya mizh protokolami L2F Cisco i PPTP Microsoft 1997 ugoda mizh rozrobnikami pro spilnu rozrobku protokolu L2TP 1999 opublikovanij standart RFC 2661 sho opisuye protokol L2TP Vvazhayetsya sho protokol L2TP uvibrav u sebe najkrashi risi PPTP i L2F Opublikovanij u 1999 roci yak proponovanij standart RFC 2661 L2TP bazuvavsya golovnim chinom na dvoh bilsh rannih tunelnih protokolah dlya PPP protokoli estafetnoyi peredachi na drugomu rivni vid Cisco ta tunelnomu protokoli tochka tochka PPTP vid Microsoft Po zagalnij dumci protokol L2TP uvibrav v sebe vsi perevagi PPTP i L2F Nova versiya cogo protokolu L2TPv3 bula opublikovana yak zaproponovanij u 2005 roci standart RFC 3931 Golovnoyu perevagoyu L2TP ye te sho cej protokol dozvolyaye stvoryuvati tunel ne lishe v merezhah IP ale i v takih yak ATM X 25 ta frame relay Shema robotiDistancijna sistema iniciyuye PPP z yednannya z LAC cherez telefonnu merezhu PSTN LAC potim prokladaye tunel dlya PPP z yednannya cherez Internet Frame Relay abo ATM do LNS i takim chinom zdijsnyuyetsya dostup do pochatkovoyi LAN Adresi viddalenij sistemi nadayutsya vihidnoyu LAN cherez uzgodzhennya z PPP NCP Autentifikaciya avtorizaciya ta akkaunting mozhut buti nadani oblastyu upravlinnya LAN yak yaksho b koristuvach buv bezposeredno z yednanij z serverom merezhevogo dostupu NAS LAC kliyent EOM yaka vikonuye programu L2TP mozhe takozh brati uchast v tunelyuvanni do vihidnoyi LAN bez vikoristannya okremogo LAC yaksho EOM sho mistit programu LAC kliyenta vzhe maye z yednannya z Internet Stvoryuyetsya virtualne PPP z yednannya i lokalna programa L2TP LAC formuye tunel do LNS Yak i u visheopisanomu vipadku adresaciya autentifikaciya avtorizaciya ta akkaunting budut zabezpecheni oblastyu upravlinnya vihidnoyi LAN Oglyad protokoluL2TP vikoristovuye dva vidi paketiv keruyuchi ta informacijni povidomlennya Keruyuchi povidomlennya vikoristovuyutsya pri vstanovlenni pidtrimci ta anulyuvannya tuneliv i viklikiv Informacijni povidomlennya vikoristovuyutsya dlya inkapsulyaciyi PPP kadriv sho peresilayutsya po tunelyu Keruyuchi povidomlennya vikoristovuyut nadijnij kontrolnij kanal v mezhah L2TP shob garantuvati dostavku Informacijni povidomlennya pri vtrati ne peresilayutsya povtorno Struktura protokolu PPP kadri L2TP informacijni povidomlennya L2TP upravlyayuchi povidomlennya L2TP informacijnij kanal nenadijnij L2TP kanal upravlinnya nadijnij Transportuvannya paketiv UDP FR ATM tosho Keruyuche povidomlennya maye poryadkovij nomer yakij vikoristovuyetsya v keruyuchomu kanali dlya zabezpechennya nadijnoyi dostavki Informacijni povidomlennya mozhut vikoristovuvati poryadkovi nomeri shob vidnoviti poryadok paketiv i detektuvati vtratu kadriv Vsi kodi nadsilayutsya v poryadku prijnyatomu dlya merezh OpisL2TP zastosovuye yak transportnij protokol UDP i vikoristovuye odnakovij format povidomlen yak dlya upravlinnya tunelem tak i dlya peresilannya danih L2TP v realizaciyi Microsoft vikoristovuye yak kontrolnih povidomlen paketi UDP sho mistyat shifrovani paketi PPP L2TP chasto vikoristovuyut dlya stvorennya tunelyu cherez VPN dzherelo Dlya zabezpechennya bezpeki L2TP paketiv zazvichaj vikoristovuyut protokol IPsec yakij nadaye konfidencijnist autentifikaciyu ta cilisnist Kombinaciya cih dvoh protokoliv vidoma yak L2TP IPsec Kincevi vuzli L2TP tunelyu nazivayutsya LAC L2TP koncentratora dostupu i LNS L2TP Server Network LAC ye iniciatorom tunelyu todi LNS server yakij ochikuye novih tuneliv Koli tunel vstanovleno merezhevij trafik mizh vuzlami ye dvonapravlenim Potim protokoli bilsh visokih rivniv zapuskayutsya vseredini tunelyu L2TP Dlya cogo L2TP sesiya vstanovlyuyetsya vseredini tunelyu dlya kozhnogo protokolu vishogo rivnya napriklad dlya PKS Yak LAK tak i LNS mozhut iniciyuvati sesiyi Trafik dlya kozhnoyi sesiyi izolyuyetsya za dopomogoyu L2TP tomu mozhlivo nalashtuvati kilka virtualnih merezh cherez odin tunel Format zagolovka Paketi L2TP dlya kontrolnogo ta informacijnogo kanaliv vikoristovuyut odin i toj zhe format zagolovka 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 Versiya Dovzhina opc ID tunelyu ID sesiyi Ns opc Nr opc Offset Size opc Offset Pad opc Payload data Bit tip T harakterizuye riznovid paketa Vin vstanovlyuyetsya rivnim 0 dlya informacijnih povidomlen i 1 dlya upravlyayuchih Yakshobit dovzhini L dorivnyuye 1 pole dovzhina prisutnye Dlya keruyuchih povidomlen cej bit povinen buti rivnij 1 Biti x zarezervovani dlya majbutnih zastosuvan Vsi zarezervovani biti povinni buti vstanovleni rivnimi 0 dlya vihidnih povidomlen i ignoruvatisya dlya vhidnih Yakshobit poslidovnosti S dorivnyuye 1 prisutni polya Ns i Nr Bit S dlya keruyuchih povidomlen povinen buti rivnij 1 Yakshobit zsuvu O dorivnyuye 1 pole velichini zmishennya prisutnye Bit O dlya keruyuchih povidomlen povinen buti rivnij 0 Bit prioritetu R povinen buti rivnij 0 dlya vsih keruyuchih povidomlen Dlya informacijnih povidomlen yaksho cej bit dorivnyuye 1 ce informacijne povidomlennya maye prioritet v cherzi Pole Ver vkazuye versiyu zagolovka informacijnogo povidomlennya L2TP Znachennya 1 zarezervovano dlya detektuvannya paketiv L2F v umovah koli voni prihodyat uperemish z L2TP paketami Paketi otrimani z nevidomim znachennyam polya Ver vidkidayutsya Pole Dovzhina opcionalno vkazuye zagalnu dovzhinu povidomlennya v oktetah ID tunelyu mistit identifikator keruyuchogo z yednannya Identifikatori tunelyu L2TP mayut tilki lokalne znachennya Tobto rizni kinci odnogo tunelyu povinni mati rizni ID ID tunelyu v kozhnomu povidomlenni maye buti tim yake ochikuye otrimuvach ID tunelyu vibirayutsya pri formuvanni tunelyu ID sesiyi viznachaye identifikator dlya sesiyi danogo tunelyu Sesiyi L2TP imenuyutsya za dopomogoyu identifikatoriv yaki mayut tilki lokalne znachennya ID sesiyi v kozhnomu povidomlenni maye buti tim yake ochikuye otrimuvach ID sesiyi vibirayutsya pri formuvanni sesiyi Pole Ns viznachaye poryadkovij nomer informacijnogo abo keruyuchogo povidomlennya pochinayuchi z nulya i zbilshuyuchis na 1 po modulyu 216 dlya kozhnogo poslanogo povidomlennya Pole Nr mistit poryadkovij nomer yakij ochikuyetsya dlya nastupnogo povidomlennya Takim chinom Nr robitsya rivnim Ns ostannogo po poryadku otrimanogo povidomlennya plyus 1 po modulyu 216 V informacijnih povidomlennyah Nr zarezervovano i yaksho prisutnij ce viznachayetsya S bitom povinno ignoruvatisya pri otrimanni Pole velichina zsuvu Offset Size yaksho ye specifikuye chislo oktetiv pislya zagolovka L2TP de maye pochinatisya pole danih Vmist zapovnyuvacha zsuvu ne viznacheno Yaksho pole zmishennya prisutnij zagolovok L2TP zavershuyetsya pislya zavershalnogo oktetu zapovnyuvacha zsuvu Tipi upravlyayuchih povidomlen Tip povidomlennya AVP viznachaye specifichnij tip keruyuyuchogo povidomlennya sho vidpravlyayetsya Upravlinnya kontrolnim z yednannyam 0 zarezervovano 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 zarezervovano 6 HELLO Hello Upravlinnya viklikami 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 zarezervovano 14 CDN Call Disconnect Notify Povidomlennya pro pomilki 15 WEN WAN Error Notify Upravlinnya sesiyeyu PPP 16 SLI Set Link Info Protokolni operaciyi Neobhidna procedura vstanovlennya PPP sesiyi tunelyuvannya L2TP vklyuchaye v sebe dva etapi Vstanovlennya keruyuchogo kanalu dlya tunelyu Formuvannya sesiyi vidpovidno do zapitu vhidnogo abo vihidnogo vikliku Tunel i vidpovidnij keruyuchij kanal povinni buti sformovani do inicializaciyi vhidnogo abo vihidnogo vikliku L2TP sesiya povinna buti realizovana do togo yak L2TP zmozhe peredavati PPP kadri cherez tunel V odnomu tuneli mozhut isnuvati kilka sesij mizh odnimi i timi zh LAC i LNS Keruyuche z yednannya Ye pervinnim yake maye buti realizovano mizh LAC i LNS pered zapuskom sesiyi Vstanovlennya keruyuchogo z yednannya vklyuchaye v sebe bezpechnu identifikaciyu partnera a takozh viznachennya versiyi L2TP mozhlivostej kanalu kadrovogo obminu i t d L2TP vklyuchaye v sebe prostu opcionnu CHAP podibnu sistemu autentifikaciyi tunelyu v procesi vstanovlennya keruyuchogo z yednannya Vstanovlennya sesiyi Pislya uspishnogo vstanovlennya keruyuchogo z yednannya mozhut formuvatisya individualni sesiyi Kozhna sesiya vidpovidaye odnomu PPP informacijnogo potoku mizh LAC i LNS Na vidminu vid vstanovlennya keruyuchogo z yednannya vstanovlennya sesiyi ye asimetrichnim shodo LAC i LNS LAC zapituye LNS dostup do sesiyi dlya vhidnih zapitiv a LNS zapituye LAC zapustiti sesiyu dlya roboti z vihidnimi zapitami Koli tunel sformovanij PPP kadri vid viddalenoyi sistemi oderzhuvani LAC zvilnyayutsya vid CRC kanalnih zagolovkiv i t in inkapsulovanih v L2TP i pereadresovuyutsya cherez vidpovidnij tunel LNS otrimuye L2TP paket i obroblyaye inkapsulovanij PPP kadr yak yaksho b vin buv otrimanij cherez lokalnij interfejs PPP Vidpravnik povidomlennya asocijovanij z pevnoyu sesiyeyu i tunelem pomishaye ID sesiyi i tunelyu specifikovani partnerom u vidpovidni polya zagolovka vsih vihidnih povidomlen Vikoristannya poryadkovih nomeriv v kanali danih Poryadkovi nomeri viznacheni v zagolovku L2TP vikoristovuyutsya dlya organizaciyi nadijnogo transportuvannya keruyuchih povidomlen Kozhen partner pidtrimuye okremu numeraciyu dlya keruyuchogo z yednannya i dlya kozhnoyi informacijnoyi sesiyi v mezhah tunelyu Na vidminu vid kanalu upravlinnya L2TP informacijnij kanal L2TP vikoristovuye numeraciyu povidomlen ne dlya povtornoyi peresilki a dlya detektuvannya vtrat paketiv i abo vidnovlennya vihidnoyi poslidovnosti paketiv peremishanih pri transportuvanni LNS mozhe iniciyuvati zaboronu numeraciyi povidomlen v bud yakij chas v hodi sesiyi vklyuchayuchi pershe informacijne povidomlennya Mehanizm keepalive Hello Mehanizm keepalive vikoristovuyetsya L2TP dlya togo shob rozriznyati prostoyi tunelyu i trivali periodi vidsutnosti keruvannya abo informacijnoyi aktivnosti v tuneli Ce robitsya za dopomogoyu keruyuchih povidomlen Hello pislya zadanogo periodu chasu yakij minuv z momentu ostannogo oderzhannya keruyuchogo povidomlennya cherez tunel Pri nedostavlenni povidomlennya Hello tunel ogoloshuyetsya nerobochim i sistema povertayetsya v pochatkovij stan Mehanizm perevedennya transportnoyi seredovisha v pochatkovij stan shlyahom vvedennya povidomlen Hello garantuye sho rozriv z yednannya mizh LNS i LAC bude detektuvati na oboh kincyah tunelyu Pererivannya sesiyi Pererivannya sesiyi mozhe buti inicijovano LAC abo LNS i vikonuyetsya shlyahom posilki keruyuchogo povidomlennya CDN Pislya togo yak ostannya sesiya perervana keruyuche z yednannya mozhe buti takozh rozirvano Rozriv kontrolnogo z yednannya Rozriv kontrolnogo z yednannya mozhe buti inicijovanij LAC abo LNS i vikonuyetsya shlyahom posilki odnogo keruyuchogo povidomlennya StopCCN Inkapsulyaciya Inkapsulyaciya paketiv L2TP IPSec vikonuyetsya v dva etapi 1 Inkapsulyaciya L2TP Kadr PPP IP datagrama abo IPX datagrama polyagaye v obolonku z zagolovkom L2TP i zagolovkom UDP 2 Inkapsulyaciya IPSec Potim otrimane L2TP povidomlennya polyagaye v obolonku z zagolovkom i trejlerom IPSec ESP Inkapsulyaciya Security Payload trejlerom perevirki avtentichnosti IPSec sho zabezpechuye cilisnist povidomlennya ta perevirku spravzhnosti i zagolovkom IP U zagolovku IP adresi dzherela i prijmacha vidpovidayut VPN kliyenta i VPN servera Na zavershennya L2TP vikonuye drugij PPP inkapsulyaciyu dlya pidgotovki danih do peredachi Struktura L2TP paketaL2TP paket skladayetsya z Biti 0 15 Biti 16 31 Flags and Version Info Length opcionalno Tunnel ID Session ID Ns opcionalno Nr opcionalno Offset Size opcionalno Offset Pad opcionalno Payload data Znachennya poliv Flags and version Prapori vkazuyut tip paketu keruyuchij abo dani i nayavnist poliv z dovzhinoyu nomerom poslidovnosti i zrushennyam Length opcionalno Povna dovzhina povidomlennya v bajtah ye lishe yaksho vstanovleno prapor dovzhini Tunnel ID Vidobrazhaye identifikator keruyuchogo z yednannya Session ID Vidobrazhaye identifikator sesiyi vseredini tunelyu Ns opcionalno Poslidovnij nomer dlya danih abo keruyuchogo povidomlennya pochinayuchi z 0 i zbilshuyuchis na odinicyu za modulem 2 16 dlya kozhnogo vidpravlenogo povidomlennya Isnuye koli vstanovlenij vidpovidnij prapor Nr opcionalno Poslidovnij nomer povidomlennya ochikuvanogo dlya prijnyattya Nr vstanovlyuyetsya yak Ns ostannogo otrimanogo povidomlennya plyus odin za modulem 2 16 U povidomlennyah z danimi Nr zarezervovanij i yaksho isnuye zobov yazanij buti proignorovano Offset Size opcionalno Viznachaye de znahodyatsya dani pislya L2TP zagolovka Yaksho ce pole isnuye L2TP zagolovok zakinchuyetsya pislya ostannogo bajta offset padding Isnuye koli vstanovlenij vidpovidnij prapor Offset Pad opcionalno Zminnoyi dovzhini vkazuyetsya offset size Vmist polya neviznacheno Payload data Sami peredani dani Zminnoyi dovzhini Maksimalnij rozmir Maksimalnomu rozmirom UDP paketu rozmir zagolovka L2TP Realizaciya L2TP cherez specifichne seredovisheProtokol L2TP ye samodokumentovanim sho pracyuyut poverh rivnya yakij sluzhit dlya transportuvannya Odnak neobhidni deyaki detali pidklyuchennya do seredovisha dlya togo shob zabezpechiti sumisnist riznih realizacij Mirkuvannya bezpekiProtokol L2TP stikayetsya pri svoyij roboti z kilkoma problemami bezpeki Nizhche rozglyanuti deyaki pidhodi dlya virishennya cih problem Bezpeka na kinci tunelyu Kinci tunelyu mozhut opcijno vikonuvati proceduru autentifikaciyi odin odnogo pri vstanovlenni tunelyu Cya autentifikaciya maye ti zh atributi bezpeki sho i CHAP i volodiye rozumnim zahistom proti atak vidtvorennya i spotvorennya v procesi vstanovlennya tunelyu Dlya realizaciyi autentifikaciyi LAC i LNS povinni vikoristovuvati zagalnij sekretnij klyuch Bezpeka paketnogo rivnya Zabezpechennya bezpeki L2TP vimagaye shob transportna seredu mogla zabezpechiti shifruvannya peredanih danih cilisnist povidomlen i autentifikaciyu poslug dlya vsogo L2TP trafiku Sam zhe L2TP vidpovidalnij za konfidencijnist cilisnist i autentifikovanist L2TP paketiv vseredini tunelyu L2TP i IPsec Pri roboti poverh IP IPsec bezpechnij IP nadaye bezpeku na paketnomu rivni Vsi keruyuchi ta informacijni paketi L2TP v konkretnomu tuneli viglyadayut dlya sistemi IPsec yak zvichajni informacijni UDP IP paketi Krim transportnoyi bezpeki IP IPsec viznachaye rezhim roboti yakij dozvolyaye tunelyuvati IP paketi a tak samo zasobi kontrolyu dostupu yaki neobhidni dlya dodatkiv sho pidtrimuyut IPsec Ci zasobi dozvolyayut filtruvati paketi na osnovi harakteristik merezhevogo i transportnogo rivniv U modeli L2TP tunelyu analogichna filtraciya vikonuyetsya na PPP rivni abo merezhevomu rivni poverh L2TP PosilannyaSpisok portiv 4 chervnya 2001 u Wayback Machine na sajti IANA Protokol L2TP Layer Two Tunneling Protocol 4 chervnya 2011 u Wayback Machine vibirayemo protokol VPN 11 kvitnya 2011 u 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 z dopomogoyu L2TP RFC 3070 Layer Two Tunneling Protocol L2TP cherez Frame Relay RFC 3145 L2TP Disconnect Cause Information RFC 3193 Zashishaya L2TP vikoristovuyuchi 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 travnya 2011 u Wayback Machine where future standardization work is being coordinated L2TP IPSec from XP client to Windows 2003 Server angl Nastrojka L2TP VPN v Windows 20 travnya 2011 u Wayback Machine ros ros Protokol L2TP Layer Two Tunneling Protocol 4 chervnya 2011 u Wayback Machine v Microsoft Technet ros Nastrojka L2TP VPN v Windows 20 travnya 2011 u Wayback Machine Cya stattya potrebuye dodatkovih posilan na dzherela dlya polipshennya yiyi perevirnosti Bud laska dopomozhit udoskonaliti cyu stattyu dodavshi posilannya na nadijni avtoritetni dzherela Zvernitsya na storinku obgovorennya za poyasnennyami ta dopomozhit vipraviti nedoliki Material bez dzherel mozhe buti piddano sumnivu ta vilucheno sichen 2016 Ce nezavershena stattya pro komp yuterni merezhi Vi mozhete dopomogti proyektu vipravivshi abo dopisavshi yiyi