Вивчення з’єднання LTP тунелю. Налаштування L2TP сервера на базі ОС Linux і клієнта на базі ОС Windows XP зі встановленням з'єднання до сервера

Протокол передачі L2TP

L2TP (Layer Two Tunneling Protocol – протокол тунелювання другого рівня) – це тунельний протокол на основі RFC – 2661, що є промисловим стандартом, підтримка якого уперше була реалізована в клієнтських і серверних операційних системах Windows 2000, але уперше з'явилася в сімействі устаткування Cisco і в операційних системах Unix, Linux. На відміну від PPTP, L2TP на серверах під управлінням Windows Server 2003 не використовує методу MPPE (Microsoft Point - to - Point Encryption) для шифрування датаграм PPP. L2TP використовує засоби шифрування, що надаються методом IPSec (IP – безпека). Комбінацію L2TP і IPSec називають L2TP/IPSec [1]. Комбінація L2TP/IPSec забезпечує роботу служб VPN (virtual private network – віртуальна приватна мережа), виконуючу інкапсуляцію і шифрування приватних даних.

Інкапсуляція

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

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

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

На поданому нижче малюнку показана інкапсуляція протоколами L2TP і IPSec кадру PPP.

Рисунок 1 – шифрування IPSec

Шифрування

Повідомлення L2TP шифрується з використанням стандарту DES (Data Encryption Standard – стандарт шифрування даних), 3DES за допомогою ключів шифрування, створених в процесі узгодження IKE (Internet Key Exchange – обмін ключами в Інтернеті) або інших стандартизованих алгоритмів шифрування.

Протокол L2TP і метод IPSec повинні підтримуватися як на VPN – клієнті, так і на VPN -сервері. Клієнтська підтримка L2TP вбудована в клієнт видаленого доступу Windows XP, а підтримка L2TP VPN – серверами – в операційні системи сімейства Windows Server 2003.

L2TP через UDP/IP

L2TP використовує зареєстрований UDP -порт 1701 (RFC1700). Увесь L2TP -пакет, включаючи поле даних і L2TP – заголовок, пересилається усередині UDP – дейтограми. Творець L2TP – тунелю вибирає доступний UDP – порт (який може бути або не бути 1701), і посилає пакет за потрібною адресою місця призначення з номером порту 1701. Одержувач вибирає вільний номер порту у своїй системі (який може бути або не бути 1701), і посилає відгук ініціаторові за його номером порту і адреси. Раз номера портів відправника і одержувача визначені, вони повинні залишатися незмінними впродовж усього життя тунелю.

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

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

Порт 1701 використовується як пакетами L2F (RFC2341), так і L2TP. Поле версія в кожному із заголовків може використовуватися, щоб відрізнити пакети цих двох типів (L2F використовує значення 1, а версія L2TP, описана в цьому документі, використовує 2). Реалізація L2TP, працююча в системі, яка не підтримує L2F, повинна відкидати усі L2F - пакети.

Для PPP - клієнтів, що використовують тунель L2TP -поверх-UDP/IP, PPP – з’єднання має можливість міняти порядок або відкидати пакети. У першому випадку можуть порушуватися протоколи, відмінні від IP і PPP, що використовують для транспортування. У другому - можуть порушуватися протоколи, в яких передбачається по пакетний контроль помилок, такий як TCP із стискуванням заголовків. Контроль порядка можна здійснити, використовуючи номери інформаційних L2TP - повідомлень, якщо якийсь протокол, що транспортується через PPP -тунель, не здатний впоратися зі зміною порядка пакетів.

Мовчазне відкидання пакетів може виявитися проблематичним для деяких протоколів. Якщо в PPP дозволена надійна доставка (RFC1663), ніякий вище розташований протокол не може зіткнутися із втратою пакетів. Якщо в L2TP дозволена нумерація пакетів, L2TP може контролювати втрату пакетів. У разі LNS, PPP і L2TP стеки є присутніми в LNS, і втрата пакета може реєструватися, начебто пакет отриманий з невірною CRC. Коли клієнти LAC і PPP фізично різні, можлива аналогова сигналізація, що реалізовується шляхом посилки PPP - клієнту пакета з невірною контрольною сумою. Це сильно ускладнить відладку канальних програм клієнта, оскільки статистика клієнта не зможе відрізнити істинні помилки транспортного середовища від помилок, ініційованих LAC. Ця техніка не реалізовується на апаратному рівні.

Якщо використовується компресія заголовка Van Jacobson, і не дозволена ні надійна доставка в PPP, ні нумерація пакетів, кожен втрачений пакет призводитиме до вірогідності 2^-16 того, що сегмент TCP буде переадресований з невірним вмістом (RFC1144). Там де вірогідність втрати велика, не слід використовувати стискування заголовків TCP - сегментів.

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