Віртуальні мережі Мережевого рівня.

М. Павликевич

ТЕЛЕКОМУНІКАЦІЙНІ МЕРЕЖІ

4

ВІРТУАЛЬНІ ПРИВАТНІ МЕРЕЖІ

Лекції для студентів cпеціальності

7.092402 “Інформаційні мережі зв ’ язку”

Львів, 2002

Вступ

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

           Найпростіше трактувати термін “приватна” у тому сенсі, що комунікації між двома (або більше) пристроями є певним чином секретними, що пристрої, які не беруть участі у “приватній” природі комунікацій, не мають доступу до вмісту комунікації і повністю вільні від особливих (приватних) взаємовідносин з будь-ким. Інше трактування терміну “приватна” витікає з його протиставлення поняттю “публічна”. Публічні засоби доступні відкрито та адмініструються через публічні адміністративні органи як загальнодоступні публічні ресурси. На відміну від цього, доступ до приватних засобів обмежений до визначеної множини учасників та адмініструється органами, які мають вийняткове право доступу. Ще один важливий аспект “приватності” VPN полягає в технічному визначенні, яке описує приватність систем адресації та раутінгу в тому сенсі, що адресація всередині спільноти VPN є окремою і відмінною від адресації в основній спільній мережі та від VPN інших спільнот. Це саме справедливе для систем раутінгу у VPN та в основній спільній мережі.

Термін “приватна” досить складним чином пов’язаний із концепцією “віртуалізації”. Значення терміну “віртуальна мережа” слід в даному контексті трактувати як “симульована” або “модельована”, тобто така, що здійснює функції чогось, чим вона не є в дійсності. Аспект “віртуалізації” подібний до вже описаної “приватності”, однак сценарій тут дещо модифікований –приватна комунікація здійснюється через мережеву інфраструктуру, яка спільно використовується більше, ніж однією організацією. Приватні ресурси тепер будуються із використанням логічного поділу певних основних спільних ресурсів замість створення окремих виділених фізичних кіл та комунікаційних послуг, тобто “приватній” мережі не відповідаає “приватна” комунікаційна система. Тому “приватна” мережа” є віртуальним твором, яка не має фізичного відовідника. Віртуальна комунікація між двома (або більше) пристроями обумовлена тим фактом, що пристрої, які не є учасниками віртуальної комунікації, не мають доступу до вмісту даних і не пов’язані приватними відносинами між віртуальними партнерами.

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

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

           Слід також відзначити, що оскільки віртуальні приватні мережі можуть бути побудовані відповідно до будь-якої кількості певних бізнесових потреб або технічних вимог, то сучасні VPN-розв’язання повинні підтримувати доступ через комутовані канали, доступ до багатьох віддалених пунктів через виділені лінії, здатність надавачів VPN-послуг надавати різні послуги замовникам VPN і датність VPN-провайдерів підтримувати сполучення не тільки всередині VN, але і між VPN, включно із сполученнями до Internet.

           Існує декілька мотивів для побудови VPN. Основна мотивація міститься в економіці комунікацій. Сьогоднішні комунікаційні системи характерні високими коштами фіксованої компоненти та значно меншими коштами змінних компонент, які змінюються із перепускною здатністю або шириною смуги системи. З фінансової точки зору становить інтерес об’єднання певної кількості окремих комунікаційних послуг у спільну високопродуктивну комунікаційну платформу, дозволяючи амортизацію високих коштів, пов’язаних із цією платформою, за рахунок більшої кількості клієнтів. Множина віртуальних мереж, вбудованих в окрему комунікаційну систему, коштує дешевше від еквівалентної множини менших фізично окремих комунікаційних систем, кожна з яких обслуговує окремого мережевого клієнта. Тому, якщо агрегування комунікацій провадить до більш ефективної в коштах комунікаційної інфраструктури, то об’єднання всіх необхідних послуг в межах однієї публічної комунікаційної системи повинне дати найбільший економічний ефект.

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

           Історичним попередником VPN є публічна мережа даних (Public Data Network – PDN); на сьогодні найбільш відомим представником такої мережі є глобальний Internet. Internet створив повсюдний взірець (парадигму) сполучності, у якому мережа дозволяє будь-якій сполученій групі мереж обмінюватися даними з довільною іншою сполученою групою. Паралелі з публічною комутованою телефонною мережею є очевидними, бо парадигма повсюдності публічного доступу є основною характеристикою цієї мережі. Однак публічна мережа даних не має вбудованої політики розділення трафіку. Мережеве середовище побудоване із використанням одної схеми адресації та спільної ієрархії раутінгу, які дозволяють елементам комутації мережі визначати розташування всіх груп, які з’єднуються. Всі ці сполучені групи також спільно використовують загальну інфраструктуру кіл та комутації. Проте модель повсюдності в Internet не задовільняє всіх можливих вимог, зокрема потреби приватності даних. Існує ряд факторів, крім приватності, які включають питання якості послуг (Quality of Service – QoS), доступності та надійності, використання публічних схем адресації, публічних протоколів, захисту пунктів та цілісності даних. Крім того, застосування для приватних мереж можуть потребувати вищого рівня управління характеристиками, ніж наявний у публічному Internet’і, або можуть визначати режими управління, які відрізняються від чинних у основному Internet’і.

           Альтернативою до використання Internet як VPN на сьогодні є виділення кіл та окремих призначених комунікаційних послуг операторами публічних мереж (звичайно локальних телефонних компаній) і створення цілком приватних мереж. Такі мережі можна називати “повністю приватними”, бо вказані виділені комунікаційні послуги знову є (на нижніх рівнях стеку протоколів) окремими випадками віртуальних приватних комунікаційних систем, побудованих над спільною системою пересилання. Слід відзначити, що більшість ранніх досягнень в мережах даних і багато сьогоднішніх мережевих архітектур не використовують модель розгортання повсюдного публічного доступу. Натомість застосовується модель закритого (або приватного) мережевого середовища, де інфраструктура, схема адресації, управління і послуги призначені для закритої множини абонентів. Такий попередник VPN може бути названий приватною мережею даних (Private Data Network – PDN) і може бути побудований з використанням виділених кабельних офісних систем і виділених кіл (або приватних віртуальних кіл від базової системи з комутацією пакетів, наприклад, X.25) для сполучення географічно віддалених пунктів.

 

Типи VPN

           Існують різні типи VPN і, залежно від функціональних вимог, різні методи їх побудови. Процес вибору може включати розгляд того, яка проблема вирішується, аналіз ризику при захисті інформації, передбаченому для конкретних впроваджень, питання масштабування при збільшенні розміру VPN, складності провадження VPN, а також обслуговування та відмовостійкості. Для спрощення опису різних типів VPN їх ділять на категорії, розміщені на різних рівнях системи протоколів TCP/IP.

Фільтрування маршрутів.

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

Рис. Фільтрування маршрутів.

Наприклад, на рис., якщо раутери сервіс-провайдера (SP) фільтрують раутінгову інформацію, прийняту від одного пункту мережі A до інших пунктів мережі A, то пункти, що не належать до мережі A (наприклад, пункти мережі B) не можуть знати про будь-які інші мережі, під’єднані до інфраструктури сервіс-провайдера (рис.). Таким чином, приватність послуг тут впроваджується через відсутність можливості для станцій даної VPN відповідати на пакети, які мають адресу джерела з-поза спільноти вузлів даної VPN.

           Таке використання часткової раутінгової інформації піддатне багатьом видам помилкового конфігурування. Однією можливою проблемою з фільтрацією маршрутів є те, що вона дуже складна, якщо взагалі можлива, при забороні для абонентських мереж вказувати за замовчуванням на вхідний раутер наступного стрибка для трафіку, призначеного мережам поза спільнотою даної VPN. Із позиції абонентів всередині VPN розумно, щоб доступ за замовчуванням для всіх учасників тієї самої VPN означав досяжність всіх інших членів тієї самої VPN і щоб вказання маршруту за замовчуванням до локального вхідного шляху були в локальному контексті розумним вирішенням. Якщо сервіс-провайдер адмініструє конфігурування у розташуванні замовника, то це рідко викликає проблеми. Однак поширеним явищем у VPN є те, що замовник сам конфігурує і адмініструє раутери в своєму розташуванні. Тоді з боку сервіс-провайдера доцільно помістити фільтри трафіку на раутері першого стрибка, щоб заборонити весь трафік, призначений для мереж поза спільнотою інтересів даної VPN.

           Слід також відзначити, що це середовище посередньо припускає існування спільного ядра раутінгу. Це, у свою чергу, веде до того, що кожна VPN повинна вживати адреси, які не перетинаються з адресами будь-якої іншої VPN у тій самій спільній інфраструктурі, і не може оголошувати довільні приватні адреси у VPN. Побічним ефектом у цій формі структури VPN є те, що дві VPN не можуть мати одного пункту взаємосполучення, або VPN у такому середовищі не може оперувати одним пунктом сполучення з Internet. Так званий “шлюз”, де весь зовнішній трафік пересилається через контрольний пункт, може регулювати як певні форми політики доступу, так і вести реєстр зовнішніх транзакцій. Спільне ядро раутінгу використовує один взірець раутінгу, базований виключно на адресі призначення.

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

           Впровадження сполучності між VPN вимагає від мережі маршрутування зовнішніх пакетів до пункту взаємозв’язку VPN і, якщо вони визнаються у пункті взаємозв’язку VPN, то вони можуть бути вислані через мережу за потрібною адресою призначення. Без використання технології трансляції мережевих адрес (Network Address Translation – NAT) у пункті взаємозв’язку входу до VPN, цей вид комунікаційної структури не може підтримуватися у наведеній архітектурі VPN (рис.).

Рис.. Використання трансляції мережевих адрес.

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

           Більші можливості для масштабованості надає використання BGP-спільнот як методу управління поширенням маршрутів. Використання атрибутів BGP-спільнот дозволяє провайдеру VPN “позначати” інформацію досяжності Мережевого рівня BGP (BGP Network Layer Reachability Information – BGP NLRI) атрибутами спільноти, так що управління конфігуруванням дозволяє поширювати раутингову інформацію відповідно до профілю спільноти (рис.).

Рис. Спільноти BGP.

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

Тунелювання.

Рис.. Традиційна модель тунелювання.

           Висилання певної частини мережевого трафіку через тунель є іншим методом побудови VPN, більш ефективним від інших. Найбільш поширеним механізмом тунелювання є використання загальної раутингової інкапсуляції (Generic Routing Incapsulation – GRE) між джерелом і раутером призначеня, між раутерами, або протоколів тунелювання між станціями, таких як L2TP, PPTP і DVMRP. Тунелювання можна розглядати як модель накладання, однак серйозність впливу масштабування приводить до того, що тунелі здійснюють за схемами “пункт-пункт” або “пункт-багато пунктів”. Тунелі “пункт-пункт” маєть менше проблем з масштабуванням, ніж тунелі “пункт-багато пунктів”, за вийнятком ситуацій, коли окремий вузол починає будувати багато тунелів “пункт-пункт” з багатьма кінцевими пунктами. Коли лінійна проблема масштабування уведена від цього пункту, то керованість тунелів “пункт-пункт” здійснюється виключно через адміністративне навантаження і тим самим через самі тунелі. З другого боку, тунелі “пункт-багато пунктів”, які використовують транзитний механізм, щоб збільшити кількість кінцевих пунктів на відстані одного стрибка від довільного іншого, потім створюють значно більш серйозну проблему масштабування.

VPN на базі робочих станцій

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

Рис.. VPN на базі робочих станцій.

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

           VPN на базі робочих станцій не залежить від конкретної марки сервера доступу або від будь-якого часкового перегляду функціональності тунелювання. Сервер повинен мати здатність комунікуватися через PPP, але всі Internet-сервери здійснюють це. VPN на базі робочих станцій не залежить від того, чи сервер доступу сприймає IPX, AppleTalk, NetBEUI або інший тип не-IP-протоколу, бо ці протоколи тунелюються до робочої станції перед висиланням через телефон до ISP. Власний шлюз може розуміти їх, однак Internet’у між ними не може бути. Компетенції ISP не можуть допускати внесення змін при NTS-розв’язаннях. VPN на базі робочих станцій не залежить від секретних телефонних номерів, які відомі тільки службовцям компанії.

           Використання VPN на базі робочих станцій може коштувати не більше, ніж доступ до мережі Internet та робота в ній. Організація не потребує мати спеціальних договорів з Internet-провайдерами, а службовці можуть використовувати будь-які потрібні послуги. Тимчасова реєстрація в чужих ISP може бути потрібна для тих, хто подорожує до віддалених країн; як тільки ця проблема вирішена для всіх, хто бажає доступу до Internet, то вона вирішена також для службовців даної організації.

           VPN на базі робочих станцій не дає шансів гакерам для подолання захисту ISP таким чином, що приймає на себе заходи ідентифікації службовців. Гакери повинні б мати програмне забезпечення організації, її ключі шифрування та адреси власних шлюзів, щоб проникнути до LAN організації. Оскільки організація контролює тунель на обидвох кінцях, то вона може впроваджувати довільні правила автентифікації користувачів. Вона також може співпрацювати із програмним забезпеченням робочих станцій для фіксації телефонних номерів, що викликаються інтервентом, та реєстрацій (account), вживатих для доступу до ISP, при діяльності, схожій на трасування телефонних викликів. VPN на базі робочих станцій не вимагає також, щоб база даних організації, яка вживається для автентифікації, була доступна для ISP. Службовці мають тільки звичайну користувацьку реєстрацію із використанням їх власних імен і паролів. Нарешті, VPN на базі робочих станцій не обмежують користувачів до одного режиму операцій (“робота” або “дозвілля”) у часі. Пакети, призначені для роботи, тунелюються, а пакети, які вживаються для дозвілля, пересилаються відкрито. До речі, TCP робочої станції мусить повністю та одночасно підтримувати різні особливості. Тоді як всі пакети, які висилаються користувачем, і всі пакети, вислані до користувача мусять вживати його IP-адресу, призначену ISP, пакети організації, сформовані TCP-стеком, мають адреси, призначені організацією. Пакети організації інкапсулюються всередині звичайних IP-пакетів і висилаються до шлюзу із зворотньою IP-адресою, призначеною ISP. Коли вони транспортуються від нього до Internet, відповіді скеровуються назад до організації, до власного шлюзу, звідки вони знову тунелюються до користувача всередині пакетів, призначених на його адресу, виділені ISP.

 

           Віртуальна приватна мережа (Virtual Private Network – VPN) з’єднує компоненти і ресурси одної мережі через іншу мережу. Віртуальні приватні мережі здійснюють це, надаючи користувачу тунель через Internet або іншу публічну мережу таким чином, що створюють учасникам тунелю можливість мати ті самі характеристики і захист інформації, які раніше були доступні тільки у приватних мережах (рис. 1).

Рис. 1. Віртуальна приватна мережа.

Віртуальні приватні мережі дозволяють віддаленим комп’ютерам, віддаленим службовцям або навіть віддаленим офісам захищеним чином з’єднуватися з корпоративним сервером, розташованим в корпоративній локальній мережі, використовуючи інфраструктуру раутінгу, наявну в публічній мережі (такій, як Internet). З точки зору користувача VPN – це сполучення “пункт-пункт” між комп’ютером користувача і корпоративним сервером. Характер проміжної мережі байдужий для користувача, оскільки вона створює враження, що дані пересилаються через виділене приватне сполучення. Технологія VPN також дозволяє корпораціям з’єднувати свої віддалені офіси або під’єднувати їх до інших компаній (Extranet) через публічні мережі, якщо надаються захищені комунікації. VPN-сполучення через Internet логічно діє як сполучення WAN між цими пунктами. В обидвох цих випадках захищене сполучення через об’єднання мереж виглядає для користувача як комунікація через приватну мережу, звідси витікає назва - віртуальна приватна мережа.

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

q розв’язання, керовані департаментом MIS, коли внутрішній департамент інформаційних систем відповідає за придбання, встановлення і обслуговування корпоративного модемного пулу та інфраструктури приватної мережі;

q розв’язання (Value-Added Network – VAN), коли корпорація оплачує зовнішній компанії за придбання, встановлення і обслуговування корпоративного модемного пулу та інфраструктури приватної мережі.

Жодне із цих розв’язань не забезпечує оптимальних надійності або масштабованості у сенсі вартості, надійності гнучкого адміністрування і управління, а також вимог щодо сполучень. Тому має сенс знайти посередню основу, коли організація доповнює або замінює свої поточні інвестиції в модемні пули і інфраструктуру приватної мережі на менш витратні розв’язання, базовані на Internet-технології. Наявність Internet-розв’язань дає можливість мати небагато під’єднань до Internet (через надавачів послуг – ISP) і розгорнути на окремих краях мережі VPN-сервери для обслуговування віддалених мережевих потреб багатьох сотень, а навіть тисяч віддалених клієнтів та офісів.

 

Поширені застосування VPN

Основні вимоги до VPN

           Звичайно, коли опрацьовують розв’язання для взаємодії віддалених мереж, підприємства вимагають забезпечити контрольований доступ до корпоративних ресурсів та інформації. Ці розв’язання повинні забезпечити авторизованим віддаленим клієнтам свободу і простоту доступу до ресурсів корпоративних локальних мереж, а також дозволяти віддаленим офісам з’єднуватися один з одним для спільного використання ресурсів та інформації (сполучення LAN-LAN). Нарешті, сполучення повинні забезпечувати секретність і цілісність даних, які поширюються через корпоративне об’єднання мереж.

           Тому, як мінімум, розв’язання VPN повинні забезпечувати:

q автентифікацію користувачів. Розв’язання повинні перевіряти ідентичність користувача і обмежувати VPN-доступ тільки до авторизованих користувачів. Крім того, повинен забезпечуватися аудит і облік записів, які показують, хто і коли мав доступ до певної інформації.

q управління адресами. Розв’язання повинні призначати адреси клієнтам у приватній мережі та мусять дбати про те, щоб ці адреси були таємними.

q шифрування даних. Дані, які переносяться через публічні мережі, мусить бути захищені від читання неавторизованими клієнтами мережі.

q управління ключами. Розв’язання повинні генерувати та оновлювати ключі шифування для клієнта і для сервера.

q багатопротокольну підтримку. Розв’язання повинні бути здатні обслуговувати поширені протоколи, які вживаються у публічних мережах. Це включає протоколи IP, IPX і тому подібні.

Для Internet розв’язання VPN базуються на тунельному протоколі “пункт-пункт” (Point-to-Point Tunneling Protocol – PPTP) або на тунельному протоколі Рівня 2 (Layer 2 Tunneling Protocol- L2TP), які відповідають всім цим основним вимогам і широко доступні в Internet. Інші розв’язання, включно з новим захищеним протоколом IP (IP Security Protocol – IPSec), відповідають тільки деяким із цих вимог, однак можуть вживатися в особливих ситуаціях.

 

Основи тунелювання

Тунелювання – це метод використання інфраструктури об’єднання мереж для пересилання даних від одної мережі через іншу мережу. Даними, які пересилаються, тобто корисним навантаженням можуть бути рамки або пакети від інших протоколів. Замість висилання рамки, випродукованої джерельним протоколом, тунельний протокол інкапсулює (запаковує) рамку в новий пакет, забезпечений своїм заголовком. Цей заголовок забезпечує інформацію для раутінгу, так що інкапсульоване корисне навантаження може перетинати проміжну мережу. При цьому інкапсульовані пакети маршрутуються через проміжне об’єднання мереж між кінцевими пунктами. Логічний шлях, через який переміщається інкапсульований пакет, називають тунелем (рис. 5). Коли інкапсульований пакет досягає призначення в об’єднанні мереж, він розпаковується і пересилається до кінцевого призначення. Зауважимо, що тунелювання включає процес запакування, пересилання і розпакування пакетів. Транзитне об’єднання мереж може бути довільним і Internet як публічна мережа є тільки найбільш поширеним прикладом.

Технології тунелювання вже існують певен час, однак новітні технології тунелювання з’явилися протягом останніх декількох років. Ці новітні технології включають:

q протокол PPTP, який дозволяє шифрувати трафік IP, IPX або NetBEUI і тоді інкапсулювати його в IP-данограму, яка пересилається через корпоративну IP-мережу або через публічну IP-мережу, таку, як Internet;

q протокол L2TP, який дозволяє шифрувати трафік IP, IPX або NetBEUI і тоді висилати його через довільне середовище, яке підтримує доручення данограм типу “пункт-пункт”, наприклад, через мережі IP, X.25, Frame Relay або ATM;

q тунельний режим IPSec, який дозволяє шифрувати трафік IP і тоді інкапсулювати його в IP-данограму, яка пересилається через корпоративну IP-мережу або через публічну IP-мережу, таку, як Internet.

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

Протоколи тунелювання

           Для того, щоб встановити тунель, необхідно, щоб тунельний клієнт і тунельний сервер використовували однаковий протокол тунелювання. Технологія тунелювання базується на використанні протоколів тунелювання Рівня 2 або Рівня 3. Протоколи Рівня 2 відповідають Канальному рівню еталонної моделі OSI і використовують рамки як блоки обміну. Протоколами Рівня 2 є PPTP і L2TP; обидва вони інкапсулюють корисне навантаження у рамки протоколу PPP для пересилання через об’єднання мереж. Протоколи Рівня 3 відповідають Канальному рівню і використовують пакети. Прикладами таких протоколів є IP over IP та IPSec Tunnel Mode. Ці протоколи інкапсулюють IP-пакети у додаткові IP-данограми перед пересиланням через IP-мережу.

Як працює тунелювання

           Для тунельних технологій Рівня 2, таких як PPTP і L2TP, тунель подібний до сесії: обидва кінцеві пункти тунелю повинні бути залучені до тунелю і повинні бути узгоджені конфіураційні змінні, такі як призначення адрес або параметри шифрування чи компресії даних. У більшості випадків дані, які пересилаються через тунель, висилаються за допомогою протоколів, базованих на данограмах. Протокол, який обслуговує тунель, вживається як механізм для керування тунелем.

Тунельні технології Рівня 3 у загальному випадку передбачають, що всі питання конфігурування обслуговуються окремо, часто вручну. Для цих протоколів фаза обслуговування тунелю може бути відсутня. Натомість для протоколів тунелювання Рівня 2 тунель повинен бути створений, обслужений і потім закритий.

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

Протокол PPP

           Оскільки протоколи Рівня 2 явно залежать від характеристик, початково визначених для PPP, має сенс вивчити цей протокол більш детально. PPP опрацьований для пересилання даних через комутовані або виділені сполучення типу “пункт-пункт”. PPP інкапсулює пакети IP, IPX та NetBEUI в рамки PPP і тоді пересилає PPP-інкапсульовані пакети через сполучення “пункт-пункт”. PPP використовується між клієнтом і сервером мережевого доступу. Існують чотири різні фази узгодження при встановленні PPP-сесії через комутовані лінії. Кожна із цих чотирьох фаз мусить успішно закінчитися, перш ніж PPP-сполучення буде готове до пересилання даних користувача.

q Фаза 1: встановлення PPP-зв ’язку. PPP використовує протокол управління каналом (Link Control Protocol – LCP) для встановлення, обслуговування і припинення фізичного сполучення. Протягом початкової фази LCP вибираються основні комунікаційні опції. Відзначимо, що протягом фази встановлення зв’язку (Фаза1) протоколи автентифікації вибираються, але не використовуються до початку фази автентифікації сполучення (Фаза 2). Подібно, протягом дії LCP вирішується, хто із двох партнерів у сполученні буде узгоджувати параметри компресії і/або шифрування даних, однак остаточний вибір алгоритмів компресії/шифрування та інші подробиці з’ясовуються протягом Фази 4.

q Фаза 2:автентифікація користувача. У другій фазі комп’ютер клієнта подає повноваження користувача до сервера віддаленого доступу. Схема надійної автентифікації передбачає захист проти (replay attack) та імітації віддаленого клієнта (Remote client impersonation). Replay attack з’являється тоді, коли третя сторона моніторує успішне сполучення і використовує захоплений пакет для відтворення відповіді віддаленого клієнта, щоб добитися автентифікованого сполучення. Remote client impersonation з’являється тоді, коли третя сторона перехоплює автентифіковане сполучення. Порушник чекає, доки сполучення буде автентифіковане і тоді виловлює інформаційний обмін, від’єднує автентифікованого користувача і перехоплює управління автентифікованим сполученням.

Більшість впроваджень PPP використовують обмежені методи автентифікації. Звичайно це протокол автентифікації пароля (Password Authentification Protocol – PAP), Challenge Handshake Authentification Protocol – CHAP і Microsoft Challenge Handshake Authentification Protocol – MSCHAP.

· Password Authentification Protocol (PAP). Це проста автентифікаційна схема з відкритим текстом. Сервер мережевого доступу запитує ім’я користувача та його пароль і PAP повертає йому це у вигляді відкритого тексту (без шифрування). Очевидно, що ця схема автентифікації не захищена, бо третя сторона може захопити ім’я користувача та пароль і використати їх для подальшого доступу до сервера мережевого доступу і всіх ресурсів, які забезпечує цей сервер. PAP не передбачає жодного захисту проти replay attack або імітації віддаленого клієнта, після того, як пароль користувача скомпрометований.

· Challenge HandshakeAuthentification Protocol (CHAP). CHAP – це шифрований автентифікаційний механізм, який уникає пересилання чинного пароля через сполучення. Сервер мережевого доступу висилає до клієнта виклик, який містить ідентифікатор сесії та довільний рядок виклику. Віддалений клієнт повинен використати односторонній алгоритм перемішування (hashing) MD5, щоб повернути ім’я користувача і шифруваня виклику, ідентифікатора сесії та пароля клієнта. Ім’я користувача висилається без перемішування.

Рис. 6. Процес CHAP.

CHAP – це вдосконалення PAP, у якому відкритий текст пароля не пересилається через сполучення. Замість цього пароль використовується для створення зашифрованого перемішування (hash) із оригінального виклику (challenge). Сервер знає відкритий текст пароля клієнта, тому може повторити операцію і порівняти результат у паролі, який висилається у відповідь клієнту. CHAP захищає проти атаки (replay attack), використовуючи довільний рядок виклику при кожній спробі автентифікації. CHAP захищає проти фальсифікації віддаленого клієнта шляхом непрогнозованого висилання повторних викликів до віддаленого клієнта протягом періоду тривання сполучення.

· Microsoft Challenge HandshakeAuthentification Protocol (MS-CHAP). MS-CHAP – це шифрований механізм автентифікації, дуже подібний до CHAP. Подібно до CHAP, NAS висилає до клієнта виклик, який складається із ідентифікатора сесії (session ID) і довільного рядка виклику. Віддалений клієнт повинен повернути ім’я користувача, MD4-hash рядка виклику, ідентифікатор сесії і пароль, зашифрований перемішуванням MD4. Така конструкція, яка оперує перемішуванням MD4-hash пароля, забезпечує додатковий рівень безпеки, бо дозволяє серверу зберігати перемішаний пароль замість відкритого тексту пароля. MS-CHAP також забезпечує додатковий код помилки включно з кодом пароля, який втратив чинність, та додаткові шифровані повідомлення клієнт-сервер, які дозволяють користувачу змінювати свій пароль. У Microsoft-впровадженнях MS-CHAP клієнт і NAS незалежно генерують початкові ключі для наступного шифрування даних через MPPE. Останній пункт дуже важливий, бо він пояснює, чому автентифікація MS-CHAP необхідна для створення можливості шифрування даних на основі MPPE.

q Фаза 3:Зворотній виклик PPP (PPP callback c ontrol).