Протокол тунелювання “пункт-пункт” ( Point-to-Point Tunneling Protocol – PPTP) .

           PPTP – це протокол Рівня 2, який інкапсулює рамки PPP у IP-данограми для пересилання через IP-мережі. PPTP також може застосовуватися у приватних об’єднаннях мереж LAN-LAN. PPTP удокументований у проекті RFC “Point-to-Point Tunneling Protocol ”. PPTP використовує TCP-сполучення для обслуговування тунелю і загальну раутінгову інкапсуляцію (Generic Routing Encapsulation – GRE) для інкапсуляції PPP-рамок для тунельованих даних. Корисне навантаженння інкапсульованих PPP-рамок може бути зашифроване і/або скомпресоване. На рис. показано, як PPTP-пакет асемблюється перед пересиланням. Рисунок показує утворення тунелю через об’єднання мереж для клієнта комутованого телефонного каналу. Ескіз останньої рамки показує інкапсуляцію для такого клієнта (PPP Device Driver).

 

Компоненти PPTP

Типи пакетів

           У специфікаціях 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.