Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Віртуальні приватні мережі
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Телекомунікації
Інформація про роботу
Рік:
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). Майже всі такі схеми тунелювання між сервером доступу і власним шлюзом є базпосередньо відгалуженнями поширених схем інкапсуляції прот...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора