Модель 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.

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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