4.1.2.Віртуальні приватні мережі з доступом через комутовані канали

Існують окремі технології (із використанням власних механізмів виготівників, так і механізмів, базованих на стандартах), наявні для побудови віртуальних приватних мереж з доступом через комутовані канали (Virtual Private Dial Network –VPDN). Зокрема, два принципові методи впровадження VPDN, популярність яких зростає – це тунелі L2TP і PPTP. З історичної перспективи L2TP є технічним об’єднанням специфікації більш раннього протоколу L2F і протоколу PPTP. Оскільки PPTP включений до операційних систем більшості персональних комп’ютерів, то він стає більш популярним.

Із цієї точки зору слід відзначити різницю між тунелями, ініційованими клієнтом, і ініційованими сервером мережевого доступу (Network Access Server – NAS). Перший раніше називали “добровільним” тунелем, тоді як другий –“вимушеним” тунелем. Добровільний тунель називається так тому, що тунель створюється на запит користувача для спеціального призначення; вимушений тунель створюється без жодної дії з боку користувача і не дозволяючи йому жодних змін по суті.

L2TP як модель із вимушеним тунелюванням – це механізм “вивантаження” абонента комутованих каналів до іншого пункту мережі або до іншої мережі. У цьому сценарії абонент викликає мережевий сервер доступу (Network Access Server – NAS), базуючись на локально сконфігурованому профілі або на узгодженнях NAS із сервером політики захисту та ефективнійавтентифікації. Тунель L2TP динамічно встановлюється до наперед визначеного кінцевого пункту, у якому закінчується сесія PPP (рис. ).

Р ис. . Механізм тунелювання з використанням L2TP.

PPTP як модель з добровільним тунелюванням дозволяє робочій станції конфігурувати і встановлювати індивідуальні тунелі “пункт-пункт” до довільно розташованих PPTP-серверів без проміжної участі NAS в узгодженнях і встановленні тунелю. У цьому сценарії абонент комутованих каналів здійснює виклик до NAS, однак PPP-сесія завершується в NAS як утрадиційній моделі PPP. Наступна PPTP-сесія тоді встановлюється між кінцевою системою клієнта і довільним вихідним PPTP-сервером, із яким клієнт бажає встановити з’єднання і який може бути досяжний через традиційну раутінгову інформацію. Після цього користувач надає певні повноваження PPTP-серверу (рис. ).

Р ис. Механізм тунелювання з використанням PPTP.

(Далі відмінності між L2TP і PPTP)

4.1.2.1.Шифрування на Мережевому рівні

Технології шифрування надзвичайно ефективні для забезпечення сегментації та віртуалізації, необхідних для VPN, і можуть бути впроваджені майже на кожному рівні стеку протоколів. Розвиненим стандартом для шифруванні на Мережевому рівні в Internet є IPSec (IP Security).

4.1.2.1.1.Віртуальні приватні мережі Канального рівня

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

(далі не перекладено)

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

Р ис. Глобальна мережа, базована на телефонній мережі або на Internet.

Якщо мережа з комутацією пакетів, така як Internet, вживається як WAN для сполучення певних пунктів, то приватна природа комунікації раутер-раутер є під загрозою, оскільки мережа не гарантує захисту доручення пакетів. Раутери, які взаємодіють один з одним через логічні кола Internet, можуть виявляти, що пакети уведяться або вилучаються із цих кіл без обмежень. Щоб зберегти “приватність” таких кіл, пакети повинні бути зашифровані, так щоб раутер міг розпізнати і видалити уведені пакети, а вилучені пакети не могли бути використані неуповноваженим приймачем. Такі приватні зв’язки між раутерами називають “тунелями”. Для надійності операцій через цей тип “віртуальних” приватних мереж компоненти раутерів звичайно повинні походити від одного виготівника.

Пересилання пакетів між раутерами могло би бути нормою для комунікації між “постійними” багатокористувацькими пунктами (sites) організацій, але виникає проблема, коли індивідуальні користувачі потребують мати доступ до LAN організації від інших зовнішніх пунктів. Коли користувач з’єднується через комутовані канали із своєї квартири або готелю, то він не має у своєму розпорядженні відповідного раутера. Сполучення може бути здійснене через телефон безпосередньо до організації або через Internet і пакети висилаються до організації через зовнішню мережу. У попередньому випадку із захистом інформації не було проблем, бо мережа розглядалася як повністю “приватна”. В останньому випадку захист інформації створює багато проблем, як це показано нижче.

Р ис. Віддалений доступ до мережі організації через комутовані телефонні канали.

Недавня тенденція великих організацій до забезпечення власної “повністю приватної” мережі з комутованими каналами (із модемними банками, серверами доступу і технічними персоналом, розташованими у кожній резиденції організації) тепер змінюється внаслідок повсюдної наявності пунктів доступу до Internet, що робить привабливим використання ресурсів надавачів послуг Internet (Internet Service Provider – ISP). Користувач може зв’язатися через комутовані телефонні канали із сервером доступу у найближчому пункті ISP і висилати пакети через місцеву LAN до раутера для їх доручення через Internet до мережі своєї організації (рис. ). Щоб зберегти захищеність комунікацій через комутовані канали, необхідно створити тунель для пересилання пакетів організації. Однак сьогодні виготівники раутерів поставлені у невигідне положення із розв’язаннями, які вони можуть запропонувати, бо їх модель тунелів працює між раутерами, а раутер з боку користувача відсутній. Для створення VPN вони можуть застосувати одну із таких моделей:

1. Передоручення (outsource) приватного пункту (Private Site).

2. Спільне використання передорученого пункту.

3. Передоручення приватного сервера доступу.

4. Спільне використання сервера доступу.

5. Обхід ISP.

Модель 1 – передоручення приватного пункту.

Організація, яка бажає передоручити свою відповідальність за доступ, може звернутися до ISP із пропозицією обслуговування “пункту” цим ISP. Провайдери самі встановлюють власне обладнання для використання комутованих каналів поблизу розташування користувачів, які викликають пункт доступу (Point of Presence – POP). При використанні першої моделі організація може укласти угоду з ISP на встановлення приватних POP для службовців компанії, які користуються доступом через комутовані канали. Якщо всі ресурси POP призначені для конкретної організації, то POP не відрізняється від віддаленого пункту організації (рис. ), так що таке саме обладнання для раутінгу, яке використовується у центрі організації, повинне бути застосоване у POP. Оскільки пункт приватний, то всі пакети можуть бути відкритими. Тунель використовується тільки між раутером і POP та між раутером і центром.

Одним із способів реалізації моделі 1 є передоручення приватного пункту з утворенням приватного тунелю тільки між ISP та раутером центру (рис. ). Цей підхід передає відповідальність щодо доступу до ISP, однак це можливо більш затратний варіант від інших, бо кошти обладнання не розділяються. Подальший недолік полягає в тому, що повсюдний доступ потребує приватного обладнання, необхідного для забезпечення локального доступу для всіх службовців, а також обмежує їх доступ тільки до конкретного ISP.

Р ис. . Модель 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), які повинні забезпечити взаємодію тунелів сервер-раутер для різних виготівників.

Р ис. Передоручення приватного сервера доступу.

Модель 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 організації, бо вона є наскрізним розв’язанням. Тому правильно передоручати свій доступ, а не управління.

Рис. . Обхід ISP.