Віртуальні приватні мережі. Лекція з Телекомунікаційні мережі. Робота № 300325

Віртуальні приватні мережі

Інформація про навчальний заклад

ВУЗ:

Національний університет Львівська політехніка

Інститут:

Не вказано

Факультет:

Не вказано

Кафедра:

Телекомунікації

Інформація про роботу

Рік:

2002

Тип роботи:

Лекція

Предмет:

Телекомунікаційні мережі

Завантажити

Частина тексту файла (без зображень, графіків і формул):

Міністерство освіти і науки України Національний університет “Львівська політехніка” Кафедра “Телекомунікації” М. Павликевич Телекомунікаційні мережі 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. Віртуальні мережі Мережевого рівня. Мережевий рівень стеку протоколів TCP/IP містить систему IP-раутінгу. Існують декілька методів побудови VPN на Мережевому рівні. Із цієї точки зору доцільно здійснити короткий огляд відмінностей між моделями VPN – модель партнерів (peer) і модель накладання (overlay). У певному спрощенні, VPN-модель партнерів – це така, в якій обчислення шляху пересилання на Канальному рівні здійснюється на основі послідовних стрибків, де кожен вузол у проміжному шляху пересилання даних є партнером вузла для наступного стрибка. Традиційні маршрутовані мережі є прикладом моделі партнерів, бо кожен раутер на шляху є партнером свого сусіда для наступного стрибка. На відміну від цього, модель VPN з накладанням – це така модель, у якій проміжна мережа Канального рівня використовується для транзиту до іншого крайнього вузла на протилежному кінці мережі. Прикладами такої моделі є впровадження ATM, Frame Relay і тунелювання. Слід відзначити, що модель з накладанням створюює серйозні проблеми з масштабуванням у випадках, коли вимагається велика кількість вхідних партнерів. Це витікає з факту, що кількість сусідів зростає у прямій залежності від кількості вхідних партнерів. Прості приклади цих двох моделей показані на рис. . Нехай раутери, які оточують внутрішню комутовану інфраструктуру, репрезентують вхідних партнерів і комутатори в основній внутрішній мережі сконфігуровані так, що всі вхідні вузли забезпечують тільки один стрибок на Рівні 3 до будь-якого іншого, утворюючи транзитну мережу. Це основа для мережі з накладанням. На відміну від цього, якщо комутатори були б замінені раутерами, то раутери, розташовані на краях мережі, тепер стають партнерами з раутерами наступного стрибка, а не з іншими вхідними раутерами. Це основа для VPN-моделі партнерів. EMBED Visio.Drawing.5 Рис. Модель VPN з накладанням (а) і модель партнерів (б). Фільтрування маршрутів. Фільтрування матшрутів – це метод, у якому основна мережа здійснює тільки управління маршрутами до пункту, де тільки певні мережі приймають маршрути для інших мереж, які належать до їх власної спільноти за інтересами. Ця модель може розглядатися як модель партнерів, бо раутер всередині пункту VPN встановлює відносини раутінгу з раутером всередині мережі VPN-провайдера замість встановлення наскрізних відносин партнерства з раутерами в інших пунктах цієї VPN. Якщо спільний основний Internet взагалі переносить маршрути від усіх мереж, під’єднаних до нього, то архітектура даної моделі приймає, що тільки підмножина таких мереж формує VPN. Маршрути для цієї підмножини мереж фільтруються так, що вони не анонсуються до будь-якої іншої групи сполучених мереж і що всі інші не-VPN-маршрути не анонсуються у мережах, які належать до VPN. EMBED Visio.Drawing.5 Рис. Фільтрування маршрутів. Наприклад, на рис. , якщо раутери сервіс-провайдера (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 (рис. ). EMBED Visio.Drawing.5 Рис. . Використання трансляції мережевих адрес. Загалом техніка підтримки приватних спільнот за інтересами тільки шляхом фільтрації маршрутів є примітивним методом побудови VPN, схильним до адміністративних помилок і надмірного рівня незахищеності та мережевої негнучкості. Навіть із всеохоплюючою фільтрацією трафіку та маршрутів результуюче середовище не повністю стійке. Операційне службове навантаження, необхідне для підтримки додаткових систем традиційних фільтрів для раутінгу і трафіку із використанням сучасних технологій раутінгу, не дозволяє перевищити межу кількості VPN понад декілька сотень. Більші можливості для масштабованості надає використання BGP-спільнот як методу управління поширенням маршрутів. Використання атрибутів BGP-спільнот дозволяє провайдеру VPN “позначати” інформацію досяжності Мережевого рівня BGP (BGP Network Layer Reachability Information – BGP NLRI) атрибутами спільноти, так що управління конфігуруванням дозволяє поширювати раутингову інформацію відповідно до профілю спільноти (рис. ). EMBED Visio.Drawing.5 Рис. Спільноти BGP. Внаслідок того факту, що трафік від різних спільнот за інтересами повинен перетинати спільну інфраструктуру, реальна приватність даних відсутня в цій частині мережі, однак можна сказати, що доки сполучені підмережі або абоненти VPN-послуг не здатні виявити, що існують інші абоненти послуг, доти потоки трафіку даних багатьох абонентів пересилаються незахищеним чином у ядрі мережі надавача послуг. Тунелювання. EMBED Visio.Drawing.5 Рис. . Традиційна модель тунелювання. Висилання певної частини мережевого трафіку через тунель є іншим методом побудови VPN, більш ефективним від інших. Найбільш поширеним механізмом тунелювання є використання загальної раутингової інкапсуляції (Generic Routing Incapsulation – GRE) між джерелом і раутером призначеня, між раутерами, або протоколів тунелювання між станціями, таких як L2TP, PPTP і DVMRP. Тунелювання можна розглядати як модель накладання, однак серйозність впливу масштабування приводить до того, що тунелі здійснюють за схемами “пункт-пункт” або “пункт-багато пунктів”. Тунелі “пункт-пункт” маєть менше проблем з масштабуванням, ніж тунелі “пункт-багато пунктів”, за вийнятком ситуацій, коли окремий вузол починає будувати багато тунелів “пункт-пункт” з багатьма кінцевими пунктами. Коли лінійна проблема масштабування уведена від цього пункту, то керованість тунелів “пункт-пункт” здійснюється виключно через адміністративне навантаження і тим самим через самі тунелі. З другого боку, тунелі “пункт-багато пунктів”, які використовують транзитний механізм, щоб збільшити кількість кінцевих пунктів на відстані одного стрибка від довільного іншого, потім створюють значно більш серйозну проблему масштабування. Традиційний режим тунелювання Тунелі GRE загалом конфігуруються між джерельним (вхідним) раутером і раутером призначення (вихідним), так що пакети, призначені для пересилання крізь тунель (вже форматовані із інкапсуляцією даних у заголовок “звичайного” пакету, визначеного протоколом), інкапсулюються з новим заголовком (заголовком GRE) і поміщаються в тунель з адресою призначення до кінцевого пункту тунелю (нового наступного стрибка). Коли пакет досягає кінцевий пункт тунелю, заголовок GRE видаляється і пакет пересилається до призначення, як вказано в заголовку оригінального IP-пакету (рис. ). Тунелі GRE у загальному випадку є тунелями “пункт-пункт”, тобто для тунелю існує одна адреса джерела і звичайно один кінцевий пункт тунелю. Однак існують певні впровадження виготівників, які дозволяють конфігурувати тунелі “пункт-багато пунктів”, які мають одну адресу джерела і багато призначень. Коли це впровадження загалом вживається із протоколом раутінгу з наступним стрибком (Next-Hop Routing Protocol – NHRP), то ефективність і вигідність NHRP є сумнівною і повинна тестуватися перед впровадженням. Варто відзначити, що NHRP відомий здатністю створювати петлі, коли він вживається для встановлення скорочень між раутерами. Однак тунелі мають ряд дуже привабливих властивостей при використанні для побудови VPN. Архітектурна концепція полягає у створенні віртуальних приватних мереж як сукупності тунелів через спільну основну мережу. Кожен пункт під’єднання до спільної мережі конфігурується як фізичний зв’язок, який використовує адресацію і раутінг від спільної основної мережі та один або декілька сумісних тунелів. Кожен кінцевий пункт тунелю логічно пов’язує цей пункт під’єднання до інших віддалених пунктів у тій самій VPN. Техніка тунелювання використовує вхідну адресу тунелю, визначену всередині адресного простору спільної основної мережі, тоді як пакети, які транспортуються всередині тунелю, вживають адресний простір VPN, що у свою чергу змушує кінцеві пункти тунелю до розміщенння у тих пунктах мережі, де VPN і основна мережа взаємосполучені. Перевага такого підходу полягає в тому, що раутінг для VPN ізольований від раутінгу у спільній основній мережі. Віртуальні приватні адреси можуть знову використовувати той сам адресний простір всередині багатьох VPN без жодного взаємного впливу, що забезпечує значну незадежність VPN від основної мережі. Ключова вимога для багатьох VPN полягає в тому, що ці VPN звичайно не можуть вживати глобально унікальний або скоординований адресний простір, і це часто є послідовною вимогою для підтримки багатьох VPN, які незалежно вживають той самий блок адрес. Така конфігурація не може підтримуватися всередині архітектури VPN із керованою фільтрацією маршрутів. Тунель також може інкапсулювати різні сімейства протоколів, так що можна імітувати багато функціональних можливостей виділених приватних мереж. Знову, вимога щодо підтримки багатьох протоколів у форматі, який забезпечує функціональність цих протоколів, є критичною вимогою для багатьох архітектур підтримки VPN. Коли спільна IP-мережа не може підтримувати такі послуги при керованому фільтруванні маршрутів, то архітектура тунелювання може сегментувати VPN-приватний протокол у спільній основній мережі. Іншою суттєвою перевагою тунелювання є відділення спільного основного середовища раутінгу від раутінгу у VPN. Для VPN спільна основна мережа допускає власність певної кількості кіл “пункт-пункт” і VPN може використовувати протокол раутінгу через віртуальну мережу, який узгоджує адміністративні вимоги VPN. Так само спільна основна мережа може використовувати побудову раутінгу, яка узгоджена з адміністративними вимогами основної мережі (або сукупності основних мереж) і не обмежується протоколами раутінгу, використаними клієнтськими мережами VPN. Могло б здаватися, що тунелювання GRE є універсальним засобом для побудови VPN. Однак існують певні недоліки при використанні тунелів GRE як механізму для VPN, переважно внаслідок адміністративного навантаження, масштабування при великій кількості тунелів, якості постуг і характеристик. Оскільки тунелі GRE повинні конфігуруватися вручну, то існує пряма залежність між кількістю тунелів, які повинні бути сконфігуровані, та обсягом адміністративного навантаження, необхідного для їх конфігурування та обслуговування, бо кожного разу, коли кінцеві пункти тунелю повинні бути змінені, то вони мусять бути перекофігуровані вручну. Також доки обсяг обробки даних, необхідний для інкапсуляції пакетів для GRE залишається малим, доти існує пряма залежність між кількістю конфігурованих тунелів і загальним обсягом обробки, необхідної для GRE-інкапсуляції. До речі, тунелі можуть бути структуровані для автоматичного пермикання, але існює ряд недоліків такого підходу, які диктуються старанним розглядом пов’язаних питань раутінгу і характеристик. Найгіршим випадком такого автоматичного генерування тунелю є виникнення конфігураційної петлі, коли тунель пересилає трафік до себе самого. Ефективність раутінгу також зменшується внаслідок великої кількості суміжних партнерів раутінгу при повній сітці тунелів. Додаткові турботи при тунелюванні GRE викликає здатність механізмів класифікації трафіку до ідентифікації трафіку з достатньо дрібною деталізацією, яка не ставала б завадою для характеритстик пересилання. Якщо процес класифікації трафіку, використаний для ідентифікації пакетів (які повинні пересилатися через тунель), заважає обслуговувати прийнятні швидкості пересилання пакетів, то це приводить до погіршення характеристик. Приватність мережі обмежена вразливістю тунелю і не є абсолютною. Пакети, які використовують форматування GRE, можуть бути уведені у VPN від джерел із третьої сторони.Щоб досягнути вищого ступеня цілісності приватності VPN, необхідно впровадтити вхідні фільтри, узгоджені з конфігурацією тунельної структури. Також необхідно гарантувати, щоб раутери CPE адмініструвалися надавачем послуг VPN, бо конфігурування кінцевих пунктів тунелю є критичною компонентою загальної архітектури цілісності приватності. Існує проблема із використанням GRE-тунелів у такий спосіб, бо більшість надавачів послуг VPN не бажають адмініструвати раутери CPE. Дехто навіть може вказувати, що наявність виділеного раутера CPE заперечує одній з основних передумов VPN – використанню спільної інфраструктури для зменшення загальних мережевих коштів. У моделі VPN з накладанням відсутнє управління, за допомогою якого здійснювалося б виділення шляху ув основній спільній мережі або забезпечувалася б стабільність такого шляху, що може приводити до погіршення характеристик VPN. Крім технологічних аспектів, головним питанням є те, чи адміністрування VPN передоручається мережевому провайдеру, чи чи здійснюється у межах адміністративних функцій VPN. Одне з більш серйозних питань при побудові VPN за допомогою тунелювання є те, чи не існує віртуального способу визначення вартості маршруту через тунель, оскільки справжній шлях маскується транзитною природою тунелю. Це веде до дуже неоптимального раутінгу в тому сенсі, що пакет може проходити шлях, визначений механізмом транзитного пересилання, який є суттєво неоптимальний, тоді як природні протоколи раутінгу з наступним стрибком могли б знайти більш ефективний спосіб для пересилання пакетів до їх призначення. Віртуальні приватні мережі з доступом через комутовані канали Існують окремі технології (із використанням власних механізмів виготівників, так і механізмів, базованих на стандартах), наявні для побудови віртуальних приватних мереж з доступом через комутовані канали (Virtual Private Dial Network –VPDN). Зокрема, два принципові методи впровадження VPDN, популярність яких зростає – це тунелі L2TP і PPTP. З історичної перспективи L2TP є технічним об’єднанням специфікації більш раннього протоколу L2F і протоколу PPTP. Оскільки PPTP включений до операційних систем більшості персональних комп’ютерів, то він стає більш популярним. Із цієї точки зору слід відзначити різницю між тунелями, ініційованими клієнтом, і ініційованими сервером мережевого доступу (Network Access Server – NAS). Перший раніше називали “добровільним” тунелем, тоді як другий –“вимушеним” тунелем. Добровільний тунель називається так тому, що тунель створюється на запит користувача для спеціального призначення; вимушений тунель створюється без жодної дії з боку користувача і не дозволяючи йому жодних змін по суті. L2TP як модель із вимушеним тунелюванням – це механізм “вивантаження” абонента комутованих каналів до іншого пункту мережі або до іншої мережі. У цьому сценарії абонент викликає мережевий сервер доступу (Network Access Server – NAS), базуючись на локально сконфігурованому профілі або на узгодженнях NAS із сервером політики захисту та ефективнійавтентифікації. Тунель L2TP динамічно встановлюється до наперед визначеного кінцевого пункту, у якому закінчується сесія PPP (рис. ). EMBED Visio.Drawing.5 Рис. . Механізм тунелювання з використанням L2TP. PPTP як модель з добровільним тунелюванням дозволяє робочій станції конфігурувати і встановлювати індивідуальні тунелі “пункт-пункт” до довільно розташованих PPTP-серверів без проміжної участі NAS в узгодженнях і встановленні тунелю. У цьому сценарії абонент комутованих каналів здійснює виклик до NAS, однак PPP-сесія завершується в NAS як утрадиційній моделі PPP. Наступна PPTP-сесія тоді встановлюється між кінцевою системою клієнта і довільним вихідним PPTP-сервером, із яким клієнт бажає встановити з’єднання і який може бути досяжний через традиційну раутінгову інформацію. Після цього користувач надає певні повноваження PPTP-серверу (рис. ). EMBED Visio.Drawing.5 Рис. Механізм тунелювання з використанням PPTP. (Далі відмінності між L2TP і PPTP) Шифрування на Мережевому рівні Технології шифрування надзвичайно ефективні для забезпечення сегментації та віртуалізації, необхідних для VPN, і можуть бути впроваджені майже на кожному рівні стеку протоколів. Розвиненим стандартом для шифруванні на Мережевому рівні в Internet є IPSec (IP Security). Віртуальні приватні мережі Канального рівня Однам із найбільш прогресивних методів побудови VPN є використання передавальних систем і мережевих платформ для сполучності на Фізичному і Канальному рівнях. VPN Канального рівня є майже повним функційним аналогом звичайниїх приватних мереж. (далі не перекладено) Організації, приміщення яких розташовані у різних місцях, можуть з’єднувати їх через окрему логічну мережу за допомогою раутерів та технологій WAN. Якщо використовується мережа з комутацією кіл, наприклад, телефонна мережа, то послуги постійних або комутованих кіл використовуються через емуляцію фізичного сполучення двох пунктів для бміну пакетами між раутерами. Незважаючи на те, що WAN-технології майже завжди використовують спільні “публічні” телекомунікаційні засоби, мережа, побудована таким чином, звичайно розглядається як “приватна”. EMBED Visio.Drawing.5 Рис. Глобальна мережа, базована на телефонній мережі або на Internet. Якщо мережа з комутацією пакетів, така як Internet, вживається як WAN для сполучення певних пунктів, то приватна природа комунікації раутер-раутер є під загрозою, оскільки мережа не гарантує захисту доручення пакетів. Раутери, які взаємодіють один з одним через логічні кола Internet, можуть виявляти, що пакети уведяться або вилучаються із цих кіл без обмежень. Щоб зберегти “приватність” таких кіл, пакети повинні бути зашифровані, так щоб раутер міг розпізнати і видалити уведені пакети, а вилучені пакети не могли бути використані неуповноваженим приймачем. Такі приватні зв’язки між раутерами називають “тунелями”. Для надійності операцій через цей тип “віртуальних” приватних мереж компоненти раутерів звичайно повинні походити від одного виготівника. Пересилання пакетів між раутерами могло би бути нормою для комунікації між “постійними” багатокористувацькими пунктами (sites) організацій, але виникає проблема, коли індивідуальні користувачі потребують мати доступ до LAN організації від інших зовнішніх пунктів. Коли користувач з’єднується через комутовані канали із своєї квартири або готелю, то він не має у своєму розпорядженні відповідного раутера. Сполучення може бути здійснене через телефон безпосередньо до організації або через Internet і пакети висилаються до організації через зовнішню мережу. У попередньому випадку із захистом інформації не було проблем, бо мережа розглядалася як повністю “приватна”. В останньому випадку захист інформації створює багато проблем, як це показано нижче. EMBED Visio.Drawing.5 Рис. Віддалений доступ до мережі організації через комутовані телефонні канали. Недавня тенденція великих організацій до забезпечення власної “повністю приватної” мережі з комутованими каналами (із модемними банками, серверами доступу і технічними персоналом, розташованими у кожній резиденції організації) тепер змінюється внаслідок повсюдної наявності пунктів доступу до Internet, що робить привабливим використання ресурсів надавачів послуг Internet (Internet Service Provider – ISP). Користувач може зв’язатися через комутовані телефонні канали із сервером доступу у найближчому пункті ISP і висилати пакети через місцеву LAN до раутера для їх доручення через Internet до мережі своєї організації (рис. ). Щоб зберегти захищеність комунікацій через комутовані канали, необхідно створити тунель для пересилання пакетів організації. Однак сьогодні виготівники раутерів поставлені у невигідне положення із розв’язаннями, які вони можуть запропонувати, бо їх модель тунелів працює між раутерами, а раутер з боку користувача відсутній. Для створення VPN вони можуть застосувати одну із таких моделей: Передоручення (outsource) приватного пункту (Private Site). Спільне використання передорученого пункту. Передоручення приватного сервера доступу. Спільне використання сервера доступу. Обхід ISP. Модель 1 – передоручення приватного пункту. Організація, яка бажає передоручити свою відповідальність за доступ, може звернутися до ISP із пропозицією обслуговування “пункту” цим ISP. Провайдери самі встановлюють власне обладнання для використання комутованих каналів поблизу розташування користувачів, які викликають пункт доступу (Point of Presence – POP). При використанні першої моделі організація може укласти угоду з ISP на встановлення приватних POP для службовців компанії, які користуються доступом через комутовані канали. Якщо всі ресурси POP призначені для конкретної організації, то POP не відрізняється від віддаленого пункту організації (рис. ), так що таке саме обладнання для раутінгу, яке використовується у центрі організації, повинне бути застосоване у POP. Оскільки пункт приватний, то всі пакети можуть бути відкритими. Тунель використовується тільки між раутером і POP та між раутером і центром. Одним із способів реалізації моделі 1 є передоручення приватного пункту з утворенням приватного тунелю тільки між ISP та раутером центру (рис. ). Цей підхід передає відповідальність щодо доступу до ISP, однак це можливо більш затратний варіант від інших, бо кошти обладнання не розділяються. Подальший недолік полягає в тому, що повсюдний доступ потребує приватного обладнання, необхідного для забезпечення локального доступу для всіх службовців, а також обмежує їх доступ тільки до конкретного ISP. EMBED Visio.Drawing.5 Рис. . Модель 1 із тунелем між раутером ISP і раутером центру. Оскільки обладнання для доступу не впроваджене до послуг VPN, то ISP не повинен змінювати свого довіреного виготівника обладнання, однак він може змінити програмне забезпечення сервера доступу. Більшість ISP на сьогодні не маршрутують інших протоколів, крім IP. Якщо організація, яка здійснює передоручення, у своїй корпоративній мережі вживає протокол IPX або AppleTalk, то вона може бажати, щоб ці протоколи також тунелювалися. ISP мусить мати можливість скеровувати їх від станції, яка здійснює виклик через комутовані канали, до тунельного раутера. Більшість серверів доступу можуть бути модернізовані для обслуги цих протоколів. Оскільки ISP загалом не забезпечують повноту послуг програмного забезпечення віддаленого доступу для робочих станцій замовників, то організація повинна оснастити необхідним програмним забезпеченням своїх службовців. Це програмне забезпечення не відрізняється від необхідного при відсутності передоручення. Однак кожне спеціальне програмне забезпечення, необхідне ISP для реєстрації користувачів або забезпечення захисту, мусить бути долучене до програмного пакету робочих станцій організації. Нарешті, ISP може керувати списком авторизованих імен користувачів і паролів від імені організації, щоб допомогти управлінню доступом до приватних пунктів. Телефонні номери можуть зберігатися в таємниці. Однак гакери, які які зуміють обійти захист ISP, можуть вільно розпоряджати корпоративними інформаційними ресурсами, бо їх пакети неможливо відрізнити від пакетів легітимних користувачів. Із цих міркувань слід вимагати дуже тісної взаємодії між організацією, яка здійснює передоручення, та ISP. Якщо службовці організації потребують одночасно доступу як до ресурсів компанії, так і до Internet, то вони тунелюють до організації і тоді ризикують виходити до Internet, хоча вони могли б ініціювати контакт із робочого місця. Інший спосіб дій має багато недоліків. Приймемо, наприклад, що раутер ISP (рис. ) повністю забезпечує шлях до Internet, тоді якщо пакети можуть виходити в мережу, то вони також можуть доходити до робочих місць; такі пакети могли б бути ненавмисно уведені в тунель. Далі, IP-адреси, призначені ISP користувачам, є або адресами центру організації (зворотній Internet-трафік маршрутується до центру і досягає користувачів через тунель), або є адресами пунктів (маршрутуються до другого раутера і відкрито доходять до користувачів). Обидві ситуації не можуть існувати водночас. Хоч весь трафік у дійсності переходить через тунель, доступ до Internet не може працювати. Виготівнику раутерів такий спосіб обслуговування вигідний, бо він може продати на один раутер більше (для кожного POP), незалежно від серверів доступу через комутовані канали, розгорнених ISP. Модель 2 - спільне використання передорученого пункту. Розглянемо випадок, коли декілька організацій уклали договори з ISP про передоручення їх послуг доступу не до багатьох приватних пунктів, а до одного спільного пункту. Це зберігає кошти, до речі, тому, що безсумнівно не пропонує захисту приватних пунктів. Приймемо, що кожна організація, яка використовує спільний пункт, забезпечує раутер для тунелювання приватного трафіку до свого центру. Раутери можуть бути різними, бо кожна організація може мати свого поставника. Якщо обладнання в POP не призначене для окремої організації, то спільний сервер доступу та елементи lAN не мусять бути довірчими, оскільки пакети організації можуть бути відкритими (нешифрованими) на шляху до і від призначеного раутера організації. Такі пакети незахищені перед персоналом ISP у пункті ??? Якщо сервери доступу використовуються спільно, то бази даних користувачів і паролів are comingled у пункті і програмне забезпечення сервера доступу повинне скерувати всі пакети від даного порта доступу через комутований канал до одного і тільки одного тунельного раутера. Якщо пакети попадуть до неправильного тунелю, то вони залишаться відкритими для неуповноваженого центру. Зауважимо, що користувачі не можуть проходити через свій тунель до робочого місця і тоді до Internet, не створюючи ризику, що їх зворотні пакети будуть маршрутовані через неправильний тунель. IP-адреса, призначена їх сервером доступу, завжди залишається адресою пункту. Доступ до Internet при Моделі 2 взагалі неможливий, хоч тунельні раутери у пунктах відкриті для будь-якого трафіку Internet-пакетів. Отже, ця модель не працездатна для більшості сценаріїв. Модель 3 – передоручення приватного сервера доступу. Попередні підходи не дуже привабливі, бо вони дорогі, мають обмеження і в певних випадках недостатньо захищені. Вони роблять IPS довірчим розширенням організації, яка здійснює передоручення. Хоча передоручення пунктів може мати сенс у деяких ситуаціях, це не повинно бути поширеною практикою. Передоручення пунктів може бути фаворизоване виготівниками раутерів, бо вони тоді можуть продати більше раутерів для ISP. Модель 3 пропонує інший підхід. Замість того, щоб розпочинати тунель у раутері пункту в інтересах всіх серверів доступу в пункті ISP, можна розпочинати тунелі від кожного сервера доступу. Таким чином пакети, прийняти на порті комутованого каналу, можуть бути зашифровані, інкапсульовані та уведені в тунель перед пересиланням до сервера, так що вони ніколи не є відкритими в LAN ISP. Розміщення тунельних функцій у сервері доступу має безумовні переваги перед розв’язаннями Моделі 1 та Моделі 2 і тому знаходиться в центрі уваги виготівників обладання для серверів доступу. Це також тенденція у багатьох нових пропозиціях стандартів (наприклад, PPTP і L2TP), які повинні забезпечити взаємодію тунелів сервер-раутер для різних виготівників. EMBED Visio.Drawing.5 Рис. Передоручення приватного сервера доступу. Модель 3 приймає, що організація, яка здійснює передоручення, звертається до ISP із пропозицією про розгортання певної кількості серверів доступу у кожному POP і призначення їх для службовців організації. Телефонні номери цих виділених ресурсів повинні бути доступні тільки для персоналу організації. ISP повинен знати імена службовців та їх паролі для захисту доступу до цих серверів; тільки якщо ці сервери ефективно захищені, то організація може не мати клопотів із доступом користувачів інших серверів до тунелів організації. У цій схемі вимагається новий код як для сервера доступу, так і для раутера центру організації. Раутер центру повинен бути замінений, оскільки, крім інших міркувань, може існувати більше, ніж один тунель від кожного пункту ISP. Раутер уподібнюється до сервера доступу через комутовані канали, але з логічними портами замість фізичних. Кожен тунель закінчується в LAN організації. Щоб відрізнити такий логічний сервер доступу від раутерів, які розлядалися досі, приймемо для нього назву “власний шлюз” (home gateway). Майже всі такі схеми тунелювання між сервером доступу і власним шлюзом є базпосередньо відгалуженнями поширених схем інкапсуляції протоколу PPP (Point-to-Point Protocol), які використовуються для обміну пакетами IP, IPX, AppleTalk та інших протоколів між робочими станціями і серверами доступу через телефон. У тунельних схемах сервер доступу у власному шлюзі виконує одне із завдань PPP, здійснюючи виклик від станції до сервера доступу. Тунельний протокол дозволяє пересилати ім’я користувача і пароль, які початково зібрані в ISP, до власного шлюза (подібно до PPP), так що організація за бажанням може здійснювати автентифікацію користувача. У випадку невідповідності пароля, власний шлюз може повідомити сервер доступу ISP про потребу перервати телефонне сполучення. Невдалим є те, що хоч як ISP, так і власний шлюз можуть здійснювати автентифікацію користувача, однак від користувача вимагається тільки одна пара ім’я/пароль, так що захист реально не покращується. Якщо ISP дозволяє здійснювати автентифікацію виключно у центрі, то організація не потребує відкривати свої автентифікаційні дані перед ISP і може застосувати будь-який контроль пароля, який застосовувався перед передорученням. У цій схемі сервер доступу мусить здійснювати не тільки нові тунельні функції, але також інкапсуляцію IPX або AppleTalk, як вже згадано вище. Організація мусить сама турбуватися про забезпечення повного сервісного програмного забезпечення робочих станцій для всіх службовців. Якщо службовці можуть мати дві різні реєстрації (accounts), то вони можуть почергово отримувати послуги тунельного сервера і відкриті послуги Internet під цими двома персоніфікаціями. На сьогодні нема жодного способу, який дозволяв би підтримувати водночас тунельований і відкритий трафік. Модель 4 - спільне використання сервера доступу. Оскільки нові сервери доступу здані встановлювати тунелі від імені кожного порта для комутованих каналів, то нема застережень, щоб кожен тунель міг досягати різні власні шлюзи. Власні шлюзи можуть бути вибрані на основі опізнання користувача, автентифікованого ISP, і таким чином тунелі від одного сервера доступу можуть водночас проходити до різних організацій. Ця функціональність не обов’язково краща від попередньої схеми, а в багатьох випадках може бути гіршою. Наприклад, у цій моделі автентифікаційні дані організації мусять утримуватися в ISP, і сервер доступу бусить бути більше довірчим, ніж раніше. Крім того, доки тунельні протоколи справді неоперабельні, то сервер доступу від виготівника A може не мати можливості спілкуватися з власним шлюзом виготівника B, викликаючи потребу спеціальних заходів від ISP при розгортанні серверів, виділення телефонних номерів, типів модемів і т.п. Модель 5 – обхід ISP. Існує обмеження в тій допомозі, яку можуть надати провайдери Internet у забезпеченні послуг VPN організаціям, які хочуть передоручити свою структуру доступу. Воно полягає в тому, що ISP може працювати тільки з обмеженою частиною проблем, доступних йому. ISP можуть оперувати із серверами доступу, раутерами в пунктах та підсистемами автентифікації користувачів, вони можуть забезпечувати реєстрацію користувачів і цілодобове чергування, вони можуть постійно покращувати власну інфраструктуру доступу, відкриваючи більше пунктів доступу, портів та технологій цифрового зв’язку на всіх можливих швидкостях. Вони навіть можуть перекривати відсутність стандартів VPN, розміщаючи у своїх POP сервери доступу різних виготівників і всі раутери пунктів. Але остаточно вони реально корисні для організації своїм доступом до Internet завдаки наявності відповідної кабельної системи. Тому правильний шлях до забезпечення VPN полягає в повному обході ISP (за винятком використання комутованих каналів). Крім того, успішний виготівник серверів доступу не мусить бути найкращим розробником програмного забезпечення VPN із найвищою щільністю портів і найнижчою вартістю за порт. Організація може здійснювати безпосередній доступ через комутовані канали із довільного пункті на світі, через ISP, якого вона вибрала, до будь-якої із своїх корпоративних локальних мереж, із захистом та автентифікацією, контрольованими організацією, та мінімальними комунікаційними коштами. Послуги VPN мусять забезпечувати тунелювання, яке починається від робочої станції і закінчується у власному шлюзі. Остаточно, функціональність VPN не турбується тим, що міститься між робочою станцією і LAN організації, бо вона є наскрізним розв’язанням. Тому правильно передоручати свій доступ, а не управління. EMBED Visio.Drawing.5 Рис. . Обхід ISP. VPN на базі робочих станцій Коли TCP/IP-стек робочої станції модифікований для поєднання з протокольним модулем PPP для шифрування, інкапсуляції та маршрутування пакетів до власного шлюзу, то вхід до корпоративного тунелю може розміщатися де завгідно. Робоча станція, яка здійснює тунелювання від себе, може спілкуватися з довільним власним шлюзом організації, який забезпечує узгодження тунелювання від себе так само просто, як для комунікації з будь-якими Internet-ресурсами, і кожна з проблем, які виникали при впровадженні моделей, описаних вище, буде подолана. Це NTS-підхід – зашифрований тунель від робочої станції до корпоративної мережі, незалежний від будь-яких посередників. EMBED Visio.Drawing.5 Рис. . 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). EMBED Visio.Drawing.5 Рис. 1. Віртуальна приватна мережа. Віртуальні приватні мережі дозволяють віддаленим комп’ютерам, віддаленим службовцям або навіть віддаленим офісам захищеним чином з’єднуватися з корпоративним сервером, розташованим в корпоративній локальній мережі, використовуючи інфраструктуру раутінгу, наявну в публічній мережі (такій, як Internet). З точки зору користувача VPN – це сполучення “пункт-пункт” між комп’ютером користувача і корпоративним сервером. Характер проміжної мережі байдужий для користувача, оскільки вона створює враження, що дані пересилаються через виділене приватне сполучення. Технологія VPN також дозволяє корпораціям з’єднувати свої віддалені офіси або під’єднувати їх до інших компаній (Extranet) через публічні мережі, якщо надаються з

Лекція Телекомунікаційні мережі

01.01.1970 03:01-

Коментарі

Ви не можете залишити коментар. Для цього, будь ласка, або зареєструйтесь.

Ділись своїми роботами та отримуй миттєві бонуси!

Маєш корисні навчальні матеріали, які припадають пилом на твоєму комп'ютері? Розрахункові, лабораторні, практичні чи контрольні роботи — завантажуй їх прямо зараз і одразу отримуй бали на свій рахунок! Заархівуй всі файли в один .zip (до 100 МБ) або завантажуй кожен файл окремо. Внесок у спільноту – це легкий спосіб допомогти іншим та отримати додаткові можливості на сайті. Твої старі роботи можуть приносити тобі нові нагороди!

поділитись