5.1.5.Типи пакетів

У специфікаціях PPTP наявні два основні типи пакетів протоколу PPTP: пакети даних і пакети управління. Перші розміщені в частині даних пакету, яка може мати змінну довжину. Другі містяться у зголовках пакету фіксованої довжини. Пакети даних містять звичайні дані користувача і команди застосувань. Пакети управління висилають періддичні запити статусу і керують сигналами між клієнтом, оснащеним PPTP, або FEP і сервером призначення разом із вбудованою інформацією управління, яка, у свою чергу складається із інформації для основного управління пристроєм і конфігураційної інформації. Пакети даних інкапсулюються всередину IP-данограми, а пакети управління пересилаються через сполучення TCP, по одному на пару NT Server – PPTP-клієнт або FEP.

На рис. показано типовий PPTP-пакет, інкапсульований із використанням GRE версії 2 (GRE v2). GRE v2 запропонований як розширення стандарту, викладеного в RFC 1701 і RFC 1702, яке полягає в додаванні специфічного октету для особливих функцій PPTP, таких як ідентифікатор протоколу і ідентифікатор виклику. З точки зору адміністратора цікаво відзначити, що запропонований протокол дозволяє підствердження, які пересилаються разом із даними, що заощаджує як час, так і міце в буфері. Отже, пакет корисного навантаження (Payload Packet) або данограма є по суті оригінальним PPP-пакетом, висланим клієнтом, якому бракує тільки елементів рамкування, специфічних для передавального середовища. Цю інформацію забезпечує заголовок середовища (Media Header).

Рис. . Типовий пакет PPTP.

Стандартна сесія PPTP

Пакети PPTP поширюються наскрізно через канал PPTP, однак, із точки зору користувача, тенелювання практично прозоре. Існують два сценарії, можливі з PPTP NT 4.0, один для PPP-клієнта із FEP, оснащеним PPTP, а другий – для клієнта PPP/PPTP із FEP, який допускає PPP-сполучення клієнта. Головна відмінність між ними полягає в тому, де наявний PPTP з боку клієнта – у робочій станції чи у Front End Processor у пункті доступу (POP) ISP.

1. Я к показано на рис. , клієнт PPP встановлює сесію з FEP провайдера, оснащеного PPTP, звичайно з раутером Internet або з мостом, до якого користувач має доступ через комутований канал за допомогою аналогового модема або ISDN. Коли клієнт робить запит на сполучення до сервера RAS, FEP встановлює віртуальну приватну мережу, стартуючи сесію PPTP і тунелюючи всю інформацію від PPP-клієнта через канал PPTP. Сервер NT обслуговує всі перевірки і керує шифруванням даних. Відзначимо, що сесія PPTP прозора для користувача і що клієнт для роботи потребує тільки PPP. Оскільки багато платформ, таких як UNIX, Mac та OS/2 підтримують PPP, то сервер RAS може сприймати сполучення PPTP від багатьох операційних систем із цією конфігурацією.

Рис.

2. На рис. показаний клієнт, який має встановлений протокол PPTP. Цей клієнт викликає ISP через комутований канал і встановлює PPP-сесію. Той самий клієнт у наступний момент сумісно із PPP-сесією встановлює канал PPTP і контактує із віддаленим RAS NT Server 4.0. Пакети PPP тоді тунелюються через нове віртуальне сполучення і клієнт тепер є віртуальним вузлом корпоративної LAN, однієї з тих , що виявилася знайденою через Internet. Відзначимо, що у цьому випадку FEP не мусить бути знавцем PPTP, однак тільки клієнти, оснащені PPTP, такі як NT Workstation 4.0 або NT Server 4.0, можуть використати цю конфігурацію. Як і в першому прикладі, NT обслуговує всі перевірки і може вимагати шифрування даних в обидвох напрямках. Оскільки PPTP розгорнено і виготівники обладнання ISP тестують свої впровадження протоколу, то розумно вважати, що перші використання PPTP відповідають другому сценарію. Якщо ISP має PPTP, то клієнт потребує тільки PPP, щоб здійснити PPTP-сполучення.

Р ис.

Звичайно PPTP створює тунель для клієнтської PPP-сесії, яка розпочинається сполученням до FEP з боку клієнта (звичайно це раутер доступу через комутовані лінії ISP) і з’єднується через Internet із оснащеним PPTP призначенням NT Server 4.0. Зауважимо, що у цій конфігурації (перший сценарій описаний раніше) PPTP оперує тільки між FEP з боку клієнта і NT Server 4.0. З клієнтом, оснащеним PPTP, що розглядається у другому сценарії, тунелювання ідентичне, за вийнятком того, що тунелювання починається від клієнта і простягається через FEP до RAS-сервера. Від нього перевірки в корпоративній мережі і всі застосування, залежні від протоколів, оперують так, ніби користувач під’єднаний через комутовану лінію безпосередньо до RAS-сервера із використанням PPP. Рис. показує, як PPP-данограма включена до PPTP-сесії. Доцільовий сервер застосувань досяжний тільки тоді, коли RAS-сервер перевірить PPP-клієнта із використанням доменного захисту NT.

Рис. . Тунелювання PPTP.

Типова послідовність подій протягом PPTP-сесії показана на рис. . Вона ідентична для обидвох сценаріїв за одним вийнятком: всі особливі PPTP-команди, такі як Start Session, у другому сценарії повинні бути ініційовані клієнтом, а не FEP. У кожному випадку PPTP є тепер другим із двох кроків у клієнтській PPTP-сесії. Перший крок полягає у встановленні PPP-сполучення до Internet через ISP.

На другому кроці згідно з рис. , з’єднуючись із VPN протягом активної PPP-сесії, віддалений користувач знову “викликає” використання іншого входу. Метод виклику відрізняється в цих двох сценаріях. Якщо FEP має встановлений PPTP, то дійсне сполучення, зроблене, коли користувач запитував про звичайне сполучення із сервером у LAN, сигналізує до FEP про потребу старту PPTP-сесії. Якщо ж користувач використовує PPTP клієнта, то користувач повинен знову зробити виклик комутованого каналу. Тільки у цей час віддалений користувач визначає IP-адресу замість телефонного номера і VPN-порт замість пристрою доступу до комутованого каналу, такого, як модем.

Рис. . Послідовність подій протягом сесії PPTP.

Другий крок сигналізує FEP або PPTP-оснащеному клієнту про початок третього кроку, коли до доцільового NT 4.0-сервера висилається запит Start Session. Як тільки FEP або PPTP-оснащений клієнт приймає відповідь, то PPTP-канал ініціюється і клієнт може розпочати тунелювання навіть зашифрованих даних безпосередньо до NT 4.0-сервера. Перевірка або видалення клієнта може відбутися протягом цієї тунельованої сесії. На рис. , починаючи згори, показана типова послідовність подій між PPP-клієнтом, FEP і NT-сервером. У цьому випадку, оскільки FEP має заінстальований PPTP, то він встановлює та обслуговує PPTP-сесію. Якщо б PPP-клієнт мав би PPTP у складі інстальованих у нього протоколів, то всі вказані PPTP-комунікації могли б розпочинатися і завершуватися у цього клієнта. Оскільки всі комунікації могли б тунелюватися всередині IP-пакетів, то FEP міг би діяти тільки як пункт входу до Internet через сполучення PPP.

Як показано на рисунку, PPTP забезпечує всі інструменти для обслуговування сполучення “пункт-пункт” включно із запитами статусу обидвох PPTP-відповідників, керуючих викоиків, виділення каналів для вихідних викликів, запитів та реєстрацій вхідних викликів, повного контролю потоків, повідомлень NT-сервера про від’єднання VPN-порта, навіть коли сесія раптово припинена.

Переваги PPTP

Коротко підсумовуючи, PPTP має такі переваги:

• пропонує стандартний тунельний протокол для ISP і мереж;

• централізує Front End Processors, такі якInternet-раутери і модемні банки в пунктах доступу ISP;

• забезпечує вигоди від використання повсюдних послуг, таких як ISDN і загальнодержавних локальних номерів комутованих каналів, пропонованих ISP без збитків для інформаційної безпеки компанії;

• тунелює більшість поширених мережевих протоколів: IP, IPX, NetBEUI;

• дозволяє користувачам виконувати протокольно-залежні застосування через Internet без редагування застосувань або інтерфейсів користувача;

• дозоляє здійснювати захищену автентифікацію користувачів NT 4.0 включно з протоколами PAP, CHAP і MS-CHAP;

• сприймає зашифровані дані з допомогою RSA RC-4, вбудовані в тунельовані пакети, а також DES-шифрування, забезпечує використання 40-бітового ключа сесії, узгодженого, коли RAS-сервер і клієнт ініціюють своє PPP-сполучення;

• централізує і покращує захист і шифрування для віддалених сполучень через Internet, зокрема, централізує реєстрацію віддалених користувачів у захищеній архітектурі доменів NT; крім того, адміністратор може стратегічно ізольювати RAS-сервер від вхідних викликів, визначаючи, що тільки PPTP-сесії або зашифровані дані можуть допускатися до віддаленого сполучення із корпоративною мережею із Internet;

• надає можливість мережевому адміністратору моніторувати і контролювати індивідуальні віддалені сесії, встановлені через Internet;

• завершувати клієнтські PPP-сполучення безпосередньо на сервері замість на Front End Processor через канал PPTP;

• вживати складний контроль потоків для PPTP-сесії, створюючи більш стійке сполучення, яке може непомітно коректувати незначні переривання;

• уможливлює використання кратних зв’язків (multi-link), коли багато фізичних сполучень можуть бути об’єднані для створення каналу з більшою шириною смуги;

• сумісний із Restartable File Copy ОС NT 4.0 (RFC), яка, якщо сполучення встановлене повторно, автоматично відновлює пересилання файлу, переване ненавмисним переиванням сполучення;

• дозволяє використовувати наявні IP-адреси компанії, навіть якщо вони нестандартні;

• сумісний із OIS; оскільки Microsoft опублікував PPTP як відкритий стандарт, то розробнки можуть програмувати застосування PPTP-клієнта для довільних платформ;

• наявне обладнання ISP може потребувати лише модернізації програмного забезпечення, тоді як викотівники модифікуть своє обладнання для відповідності до специфікацій PPTP; тим часом якщо клієнт оснащений PPTP, то наявне обладнання ISP може підтримувати сесії PPTP;

• як тільки локальний ISP пропонує PPTP-сполучення, то клієнти PPTP не потребують додаткового програмного забезпечення для використання PPTP; процедули використання комутованих каналів суттєво не змінюються, так що користувачі не потребують вивчати нове програмне забезпечення, щоб мати користі від тунелювання через Internet.

Завдяки цим перевагам протокол PPTP варто впроваджувати, якщо адміністратори розглядають альтернативи з малими коштами для побудови приватної мережі для застосувань WAN і віддаленого доступу через комутовані канали. Однак варто зауважити, що використання комутованих каналі безпосередньо до RAS-сервера на сьогодні є найкращою альтернативою, бо службове навантаження, викликане використанням IPX, NetBEUI або TCP/IP всередині TCP/IP-обгортки, може мути мінімізоване. Затримки, обумовлені піками трафіку в Internet можуть бути більш помітними для типового користувача, ніж затримки, пов’язані з тунелюванням протоколів через PPTP.

Протокол пересилання для Рівня 2 (Layer 2 Forwarding – L2F).

L2F – це технологія, запропонована фірмою Cisco, яка використовує протокол пересилання, що дозволяє серверам доступу через комутовані канали здійснювати рамкування трафіку в PPP і пересилати його через WAN-сполучення до L2F-сервера (або раутера). Сервер L2F виділяє пакет і уводить його в мережу. На відміну від PPTP і L2TP, L2F не ідентифікує клієнта. Відзначимо, що L2F діє тільки в примусовому тунелі (детальне обговорення добровільних і вимушених тунелів здійснено нижче).

Протокол тунелювання для Рівня 2 (Layer 2 Tunneling Protocol – L2TP).

L2TP є поєднанням PPTP і L2F. Його проектанти вважають, що L2TP може мати кращі властивості від PPTP і L2F.

L2TP – це мережевий протокол, який інкапсулює PPP-рамки, які висилаються через мережі IP, X.25, Frame Relay або ATM. Якщо протокол сконфігурований для використання IP як транспорту данограм, то L2TP можна використати як протокол тунелювання через Internet. L2TP також можна вживати безпосередньо через різні середовища WAN (як Frame Relay) без IP як транспортного рівня. L2TP документований в RFC “Layer 2 Tunneling Protocol “L2TP””.

L2TP понад об’єднанням IP-мереж використовує UDP і послідовність L2TP-повідомлень для обслуговування тунелю. L2TP також використовує UDP для висилання L2TP-інкапсульованих PPP-рамок як тунельованих даних. Корисне навантаження інкапсульованих PPP-рамок може бути зашифроване і/або компресоване. Рис. 8 показує, як асембльовано L2TP-пакет перед пересиланням. На рисунку показаний клієнт комутованого каналу, який створює тунель через об’єднання мереж. Ескіз кінцевої рамки показує інкапсуляцію для клієнта комутованого каналу (PPP Device Driver). Інкапсуляція приймає, що здійснюється дія L2TP понад IP.

Р ис. 8. Конструкція пакету L2TP.

Порівняння PPTP та L2TP

Як PPTP, так і L2TP використовують PPP для забезпечення початкового упакування даних і потім додаються заголовки для транспортування через мережу. Ці два протоколи дуже подібні, однак існують певні відмінності:

• PPTP вимагає, щоб об’єднання мереж було IP-мережею. L2TP потребує тільки, щоб тунельне середовище забезпечувало пакетно-орієнтоване сполучення “пункт-пункт”. L2TP можна використовувати понад IP (із застосуванням UDP), постійними віртуальними колами Frame Relay (PVC), постійними віртуальними колами X.25 або ATM.

• PPTP може підтримувати тільки один тунель між кінцевими пунктами, тоді як L2TP дозволяє використання багатьох тунелів. L2TP може створювати різні тунелі з різною якістю послуг (QoS).

• L2TP забезпечує компресію заголовків. Коли вона наявна, то L2TP оперує із 4 байтами службового навантаження порівняно із 6 байтами для PPTP.

• L2TP забезпечує автентифікацію тунелю, тоді як у PPTP це відсутнє. Однак, якщо певний протокол вживається понад IPSec, то автентифікація тунелю здійснює IPSec, так що автентифікація тунелю на Рівні 2 не потрібна.

Режим тунелю IPSec

IPSec – це стандарт протоколу Рівня 3, який підтримує захищене пересилання інформації через об’єднання IP-мереж і більш детально описаний нижче. Однак, один аспект IPSec слід розглянути у контексті протоколів тунелювання. Крім механізму шифрування IP-трафіку, IPSec визначає формат пакету для IP через режим IP-тунелювання, який загалом називають режимом тунелювання IPSec. Тунель IPSec складається з тунельного клієнта і тунельного сервера, які обидва конфігуруються з використанням тунелювання IPSec і шифрованого механізму узгодження. Режим тунелювання IPSec використовує узгоджений метод захисту для інкапсуляції і шифрування цілих IP-пакетів для захищеного пересилання через приватну або публічну IP-мережу. Зашифроване корисне навантаження інкапсулюється разом із відкритим IP-заголовком і висилається через об’єднання мереж до тунельного сервера. Після прийняття данограми тунельний сервер обробляє її, відкидає відкритий IP-заголовок і дешифрує вміст для отримання початкового корисного навантаження IP-пакету. Цей пакет далі обробляється звичайним чином і маршрутується до свого призначення у доцільовій мережі.

Режим тунелювання IPSec має такі властивості та обмеження:

• підтримує тільки IP-трафік;

• діє на нижньому рівні IP-стеку; тому застосування та протоколи вищого рівня успадковують його поведінку;

• керований політикою безпеки – системою правил фільтрування-узгодження. Ця політика безпеки встановлює наявні механізми шифрування та тунелювання у пріорітетному порядку і наявні методи автентифікації також у пріорітетному порядку. Як тільки наявний трафік, два комп’ютери здійснюють взаємну автентифікацію і тоді узгоджують метод шифрування. Після цього весь трафік шифрується з використанням узгодженого механізму і вставляється у заголовок тунелю.