Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Управління інформацією
Кафедра:
Не вказано
Інформація про роботу
Рік:
2010
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Захист інформації
Група:
МЕ
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
Національний університет
“ЛЬВІВСЬКА ПОЛІТЕХНІКА”
ВІРТУАЛЬНІ ПРИВАТНІ МЕРЕЖІ
МЕТОДИЧНІ ВКАЗІВКИ ДО ЛАБОРАТОРНОЇ РОБОТИ № 2
З КУРСУ “ІНФОРМАЦІЙНО-АНАЛІТИЧНЕ ЗАБЕЗПЕЧЕННЯ БЕЗПЕКИ”
для студентів базових напрямів
“Управління інформаційною безпекою”
Затверджено
на засіданні кафедри
захисту інформації
Протокол № 11 від “01”лютого 2010 р.
Львів 2010
Мета роботи – ознайомитися зі способами організації віртуальних приватних мереж та набути практичні навики стосовно конфігурації параметрів відповідного мережного обладнання і вирішенні проблем щодо захисту комп’ютерного трафіку.
1. ТЕОРЕТИЧНІ ВІДОМОСТІ
Віртуальна приватна мережа – це комунікаційне середовище, у якому доступ контрольований через дозвіл сполучення між респондентами тільки всередині визначеної спільноти за інтересами і побудований на певних формах спільного використання основного комунікаційного середовища, де це основне комунікаційне середовище забезпечує послуги мережі на невиключній основі.
Найпростіше трактувати термін “приватна” у тому сенсі, що комунікації між двома (або більше) пристроями є певним чином секретними, що пристрої, які не беруть участі у “приватній” природі комунікацій, не мають доступу до вмісту комунікації і повністю вільні від особливих (приватних) взаємовідносин з будь-ким. Інше трактування терміну “приватна” витікає з його протиставлення поняттю “публічна”. Публічні засоби доступні відкрито та адмініструються через публічні адміністративні органи як загальнодоступні публічні ресурси. На відміну від цього, доступ до приватних засобів обмежений до визначеної множини учасників та адмініструється органами, які мають вийняткове право доступу. Ще один важливий аспект “приватності” VPN полягає в технічному визначенні, яке описує приватність систем адресації та раутінгу в тому сенсі, що адресація всередині спільноти VPN є окремою і відмінною від адресації в основній спільній мережі та від VPN інших спільнот. Це саме справедливе для систем раутінгу у VPN та в основній спільній мережі.
Термін “приватна” досить складним чином пов’язаний із концепцією “віртуалізації”. Значення терміну “віртуальна мережа” слід в даному контексті трактувати як “симульована” або “модельована”, тобто така, що здійснює функції чогось, чим вона не є в дійсності. Аспект “віртуалізації” подібний до вже описаної “приватності”, однак сценарій тут дещо модифікований –приватна комунікація здійснюється через мережеву інфраструктуру, яка спільно використовується більше, ніж однією організацією. Приватні ресурси тепер будуються із використанням логічного поділу певних основних спільних ресурсів замість створення окремих виділених фізичних кіл та комунікаційних послуг, тобто “приватній” мережі не відповідаає “приватна” комунікаційна система. Тому “приватна” мережа” є віртуальним твором, яка не має фізичного відовідника. Віртуальна комунікація між двома (або більше) пристроями обумовлена тим фактом, що пристрої, які не є учасниками віртуальної комунікації, не мають доступу до вмісту даних і не пов’язані приватними відносинами між віртуальними партнерами.
Поєднання цих понять приводить до віртуальної приватної мережі – приватної мережі, приватність якої впроваджена певними методами віртуалізації. VPN може бути побудована між двома кінцевими системами, між двома організаціями, між окремими кінцевими системами всередині однієї організації або між багатьма організаціями через глобальний Internet, між індивідуальними застосуваннями або для довільної комбінації вказаних вище.
Про віртуальні приватні мережі також можна сказати, що вони є дискретними, тобто відокремленими мережами. Дискретна природа VPN дозволяє приватність і віртуальність. Оскільки VPN не є повністю відокремленими у фізичному сенсі, то їх відокремленість забезпечується тим, що вони оперують дискретно через спільну інфраструктуру, створюючи виключне комунікаційне середовище, яке не є спільним із іншими в жодному пункті сполучення. Тому VPN не обов’язково означає комунікаційну ізоляцію, а скоріше керовану сегментацію комунікацій для спільнот за інтересами через спільну інфраструктуру.
Слід також відзначити, що оскільки віртуальні приватні мережі можуть бути побудовані відповідно до будь-якої кількості певних бізнесових потреб або технічних вимог, то сучасні VPN-розв’язання повинні підтримувати доступ через комутовані канали, доступ до багатьох віддалених пунктів через виділені лінії, здатність надавачів VPN-послуг надавати різні послуги замовникам VPN і датність VPN-провайдерів підтримувати сполучення не тільки всередині VN, але і між VPN, включно із сполученнями до Internet.
Існує декілька мотивів для побудови VPN. Основна мотивація міститься в економіці комунікацій. Сьогоднішні комунікаційні системи характерні високими коштами фіксованої компоненти та значно меншими коштами змінних компонент, які змінюються із перепускною здатністю або шириною смуги системи. З фінансової точки зору становить інтерес об’єднання певної кількості окремих комунікаційних послуг у спільну високопродуктивну комунікаційну платформу, дозволяючи амортизацію високих коштів, пов’язаних із цією платформою, за рахунок більшої кількості клієнтів. Множина віртуальних мереж, вбудованих в окрему комунікаційну систему, коштує дешевше від еквівалентної множини менших фізично окремих комунікаційних систем, кожна з яких обслуговує окремого мережевого клієнта. Тому, якщо агрегування комунікацій провадить до більш ефективної в коштах комунікаційної інфраструктури, то об’єднання всіх необхідних послуг в межах однієї публічної комунікаційної системи повинне дати найбільший економічний ефект.
Другою мотивацією для побудови VPN є забезпечення приватності комунікації, де характеристики і цілісність комунікаційних послуг всередині одного замкненого середовища ізольовані від усіх інших середовищ, які спільно використовують загальну комунікаційну систему. Рівень приватності в основному залежить від ступеня ризику, прийнятного для організації – абонента VPN, і визначає ступінь жорсткості заодів для захисту інформації, яка пересилається через загальну комунікаційну систему.
Типи VPN
Існують різні типи VPN і, залежно від функціональних вимог, різні методи їх побудови. Процес вибору може включати розгляд того, яка проблема вирішується, аналіз ризику при захисті інформації, передбаченому для конкретних впроваджень, питання масштабування при збільшенні розміру VPN, складності провадження VPN, а також обслуговування та відмовостійкості. Для спрощення опису різних типів VPN їх ділять на категорії, розміщені на різних рівнях системи протоколів TCP/IP.
Поширені застосування VPN
Доступ віддаленого користувача через Internet
Віртуальні приватні мережі забезпечують віддалений доступ до корпоративних ресурсів через Internet, забезпечуючи секретність інформації (рис. 2). Замість використання виділеної лінії або комутованого зв’язку на велику відстань через зовнішній сервер доступу, користувач спочатку з’єднується з локальним ISP через телефон. Використовуючи локальне сполучення до ISP, програмне забезпечення VPN створює приватну віртуальну мережу між користувачем і корпоративним сервером VPN через Internet.
Рис. 2. Використання VPN для сполучення віддаленого клієнта з корпоративною LAN.
Сполучення мереж через Internet
Існують два методи використання віртуальних приватних мереж для під’єднання локальних мереж до віддалених пунктів:
використання виділених ліній для сполучення віддалених офісів до корпоративної LAN. Замість використання дорогого віддаленого зв’язку через виділену лінію між офісом і корпоративним габом (раутером), раутер віддаленого офісу і корпоративний раутер можуть використовувати локальні виділені лінії до локальних ISP для під’єднання до Internet. Програмне забезпечення VPN використовує локальні під’єднання до ISP та Internet для створення віртуальної приватної мережі між раутером віддаленого офісу і раутером корпорації через Internet.
Використання комутованих ліній для сполучення віддалених офісів до корпоративної LAN. Замість використання виділеної лінії або віддаленого комутованого з’єднання до корпоративного або стороннього сервера мережевого доступу, раутер віддаленого офісу може з’єднуватися з локальним ISP через комутовану лінію. Програмне забезпечення VPN використовує сполучення до локального ISP для створення віртуальної приватної мережі між раутером віддаленого офісу і раутером корпорації через Internet.
Рис. 3. Використання VPN для сполучення двох віддалених пунктів.
Зауважимо, що в обидвох випадках обладнання, яке з’єднує віддалений офіс з корпоративним, є локальним. Ощадність коштів при використанні віртуальних приватних мереж клієнт-сервер і сервер-сервер є прогнозованою, якщо брати до уваги використання локального комутованого зв’язку для сполучення. Рекомендується, щоб корпоративний раутер, який діє як сервер VPN, був під’єднаний до локального ISP через виділену лінію. Цей сервер повинен бути доступний для вхідного трафіку VPN протягом 24 годин на добу.
Сполучення комп’ютерів через intranet
У певних корпоративних об’єднаннях мереж дані підрозділів є настільки важливими (тобто чутливими до несанкціонованого доступу), що LAN цих підрозділів фізично відокремлюють від решти корпоративної мережі. Хоч це забезпечує таємність інформації таких підрозділів, однак створює проблеми з доступом до інформації для тих користувачів, які фізично не під’єднані до цих окремих LAN. Віртуальні приватні мережі дозволяють LAN підрозділів бути фізично під’єднаними до корпоративного об’єднання мереж і бути відділеними від сервера VPN. Зауважимо, що сервер VPN не діє як раутер між корпоративним об’єднанням мереж і LAN підрозділів. Раутер може з’єднувати ці дві мережі, дозволяючи будь-кому мати доступ до чутливих LAN. При використанні VPN мережевий адміністратор може гарантувати, що тільки ті користувачі корпоративного об’єднання мереж, які мають відповідні повноваження, можуть встановлювати віртуальну приватну мережу з сервером VPN і отримувати доступ до захищених ресурсів підрозділу. Крім того, уся комунікація через VPN може бути зашифрована для забезпечення конфіденційності даних. Користувачі, які не мають необхідних повноважень, не можуть бачити LAN підрозділів.
Рис. 4. Використання VPN для сполучення двох комп’ютерів у тій самій LAN.
Основні вимоги до VPN
Звичайно, коли опрацьовують розв’язання для взаємодії віддалених мереж, підприємства вимагають забезпечити контрольований доступ до корпоративних ресурсів та інформації. Ці розв’язання повинні забезпечити авторизованим віддаленим клієнтам свободу і простоту доступу до ресурсів корпоративних локальних мереж, а також дозволяти віддаленим офісам з’єднуватися один з одним для спільного використання ресурсів та інформації (сполучення LAN-LAN). Нарешті, сполучення повинні забезпечувати секретність і цілісність даних, які поширюються через корпоративне об’єднання мереж.
Тому, як мінімум, розв’язання VPN повинні забезпечувати:
автентифікацію користувачів. Розв’язання повинні перевіряти ідентичність користувача і обмежувати VPN-доступ тільки до авторизованих користувачів. Крім того, повинен забезпечуватися аудит і облік записів, які показують, хто і коли мав доступ до певної інформації.
управління адресами. Розв’язання повинні призначати адреси клієнтам у приватній мережі та мусять дбати про те, щоб ці адреси були таємними.
шифрування даних. Дані, які переносяться через публічні мережі, мусить бути захищені від читання неавторизованими клієнтами мережі.
управління ключами. Розв’язання повинні генерувати та оновлювати ключі шифування для клієнта і для сервера.
багатопротокольну підтримку. Розв’язання повинні бути здатні обслуговувати поширені протоколи, які вживаються у публічних мережах. Це включає протоколи IP, IPX і тому подібні.
Для Internet розв’язання VPN базуються на тунельному протоколі “пункт-пункт” (Point-to-Point Tunneling Protocol – PPTP) або на тунельному протоколі Рівня 2 (Layer 2 Tunneling Protocol- L2TP), які відповідають всім цим основним вимогам і широко доступні в Internet. Інші розв’язання, включно з новим захищеним протоколом IP (IP Security Protocol – IPSec), відповідають тільки деяким із цих вимог, однак можуть вживатися в особливих ситуаціях.
Основи тунелювання
Тунелювання – це метод використання інфраструктури об’єднання мереж для пересилання даних від одної мережі через іншу мережу. Даними, які пересилаються, тобто корисним навантаженням можуть бути рамки або пакети від інших протоколів. Замість висилання рамки, випродукованої джерельним протоколом, тунельний протокол інкапсулює (запаковує) рамку в новий пакет, забезпечений своїм заголовком. Цей заголовок забезпечує інформацію для раутінгу, так що інкапсульоване корисне навантаження може перетинати проміжну мережу. При цьому інкапсульовані пакети маршрутуються через проміжне об’єднання мереж між кінцевими пунктами. Логічний шлях, через який переміщається інкапсульований пакет, називають тунелем (рис. 5). Коли інкапсульований пакет досягає призначення в об’єднанні мереж, він розпаковується і пересилається до кінцевого призначення. Зауважимо, що тунелювання включає процес запакування, пересилання і розпакування пакетів. Транзитне об’єднання мереж може бути довільним і Internet як публічна мережа є тільки найбільш поширеним прикладом.
Технології тунелювання вже існують певен час, однак новітні технології тунелювання з’явилися протягом останніх декількох років. Ці новітні технології включають:
протокол PPTP, який дозволяє шифрувати трафік IP, IPX або NetBEUI і тоді інкапсулювати його в IP-данограму, яка пересилається через корпоративну IP-мережу або через публічну IP-мережу, таку, як Internet;
протокол L2TP, який дозволяє шифрувати трафік IP, IPX або NetBEUI і тоді висилати його через довільне середовище, яке підтримує доручення данограм типу “пункт-пункт”, наприклад, через мережі IP, X.25, Frame Relay або ATM;
тунельний режим IPSec, який дозволяє шифрувати трафік IP і тоді інкапсулювати його в IP-данограму, яка пересилається через корпоративну IP-мережу або через публічну IP-мережу, таку, як Internet.
Протоколи тунелювання і основні вимоги до тунелювання
Оскільки ці протоколи базуються на добре визначеному протоколі PPP, то протоколи Рівня 2 (такі як PPTP і L2TP) успадкували систему корисних характеристик. Ці характеристики та їх відповідники Рівня 3 визначають основні вимоги VPN:
Автентифікація користувачів. Протоколи тунелювання Рівня 2 успадковують схеми автентифікації користувачів, включно з методом розширюваного протоколу автентифікації (Extensible Authentification Protocol – EAP), який розглянено нижче. Більшість схем тунелювання Рівня 3 приймають, що кінцеві пункти добре відомі та автентифіковані перед встановленням тунелю. Вийнятком із цього є ISAKMP-узгодження в протоколі IPSec, яке передбачає взаємну автентифікацію кінцевих пунктів тунелю. Відзначимо, що більшість впроваджень IPSec підтримує тільки сертифікацію комп’ютерів замість сертифікації користувачів. Внаслідок цього будь-який користувач, який має доступ до одного із комп’ютерів у кінцевих пунктах, може використовувати тунель. Цей потенційний недолік у забезпеченні захисту можна усунути, якщо IPSec працює разом із протоколом Рівня 2, таким як L2TP.
Підтимка карт-жетонів (token card). З використанням протоколу EAP протоколи тунелювання Рівня 2 можуть підтримувати різноманітні методи автентифікації, включно з одноразовими паролями, криптографічними калькуляторами та інтелектуальними картками (smart card). Протоколи тунелювання Рівня 3 можуть використовувати подібні методи; наприклад, IPSec визначає автентифікацію сертифікату з публічним ключем у своєму ISAKMP/Oakley-узгодженні.
Динамічне призначення адрес. Тунелювання на Рівні 2 підтримує динамічне призначення адрес клієнтів, базоване на механізмі узгодження протоколу управління мережею (Network Control Protocol – NCP). Загалом схеми тунелювання Рівня 3 приймають, що що адреси завжди призначені заздалегідь перед ініціюванням тунелю. Схеми призначення адрес в тунельному режимі IPSec ще опрацьовуються і тепер відсутні.
Компресія даних. Протоколи тунелювання Рівня 2 підтримують схеми компресії, базовані на протоколі PPP. IETF опрацьовує подібні механізми (такі, як IP-компресія) для протоколів тунелювання Рівня 3.
Шифрування даних. Протоколи тунелювання Рівня 2 підтримують механізми шифрування, базовані на протоколі PPP; подібні схеми використовуються у протоколах тунелювання Рівня 3.
Управління ключами. Протокол тунелювання Рівня 2 MPPE (Microsoft Point-to-Point Encryption) полягає на початковому генеруванні ключа при автентифікації користувача і наступному періодичному оновленні його. IPSec явно узгоджує поточний ключ протягом ISAKMP-узгодження і також перідично його оновлює.
Багатопротокольна підтримка. Тунелювання Рівня 2 підтримує багато протоколів для корисного навантаження, що робить його простим для клієнтів тунелювання при доступі до корпоративних мереж, які вживають IP, IPX, NetBEUI і подібні протоколи. Навпаки, протоколи тунелювання Рівня 3 звичайно підтримують тільки ті доцільові мережі, які вживають протокол IP.
Протокол PPP
Оскільки протоколи Рівня 2 явно залежать від характеристик, початково визначених для PPP, має сенс вивчити цей протокол більш детально. PPP опрацьований для пересилання даних через комутовані або виділені сполучення типу “пункт-пункт”. PPP інкапсулює пакети IP, IPX та NetBEUI в рамки PPP і тоді пересилає PPP-інкапсульовані пакети через сполучення “пункт-пункт”. PPP використовується між клієнтом і сервером мережевого доступу. Існують чотири різні фази узгодження при встановленні PPP-сесії через комутовані лінії. Кожна із цих чотирьох фаз мусить успішно закінчитися, перш ніж PPP-сполучення буде готове до пересилання даних користувача.
Фаза 1: встановлення PPP-зв’язку. PPP використовує протокол управління каналом (Link Control Protocol – LCP) для встановлення, обслуговування і припинення фізичного сполучення. Протягом початкової фази LCP вибираються основні комунікаційні опції. Відзначимо, що протягом фази встановлення зв’язку (Фаза1) протоколи автентифікації вибираються, але не використовуються до початку фази автентифікації сполучення (Фаза 2). Подібно, протягом дії LCP вирішується, хто із двох партнерів у сполученні буде узгоджувати параметри компресії і/або шифрування даних, однак остаточний вибір алгоритмів компресії/шифрування та інші подробиці з’ясовуються протягом Фази 4.
Фаза 2: автентифікація користувача. У другій фазі комп’ютер клієнта подає повноваження користувача до сервера віддаленого доступу. Схема надійної автентифікації передбачає захист проти (replay attack) та імітації віддаленого клієнта (Remote client impersonation). Replay attack з’являється тоді, коли третя сторона моніторує успішне сполучення і використовує захоплений пакет для відтворення відповіді віддаленого клієнта, щоб добитися автентифікованого сполучення. Remote client impersonation з’являється тоді, коли третя сторона перехоплює автентифіковане сполучення. Порушник чекає, доки сполучення буде автентифіковане і тоді виловлює інформаційний обмін, від’єднує автентифікованого користувача і перехоплює управління автентифікованим сполученням.
Більшість впроваджень PPP використовують обмежені методи автентифікації. Звичайно це протокол автентифікації пароля (Password Authentification Protocol – PAP), Challenge Handshake Authentification Protocol – CHAP і Microsoft Challenge Handshake Authentification Protocol – MSCHAP.
Password Authentification Protocol (PAP). Це проста автентифікаційна схема з відкритим текстом. Сервер мережевого доступу запитує ім’я користувача та його пароль і PAP повертає йому це у вигляді відкритого тексту (без шифрування). Очевидно, що ця схема автентифікації не захищена, бо третя сторона може захопити ім’я користувача та пароль і використати їх для подальшого доступу до сервера мережевого доступу і всіх ресурсів, які забезпечує цей сервер. PAP не передбачає жодного захисту проти replay attack або імітації віддаленого клієнта, після того, як пароль користувача скомпрометований.
Challenge Handshake Authentification Protocol (CHAP). CHAP – це шифрований автентифікаційний механізм, який уникає пересилання чинного пароля через сполучення. Сервер мережевого доступу висилає до клієнта виклик, який містить ідентифікатор сесії та довільний рядок виклику. Віддалений клієнт повинен використати односторонній алгоритм перемішування (hashing) MD5, щоб повернути ім’я користувача і шифруваня виклику, ідентифікатора сесії та пароля клієнта. Ім’я користувача висилається без перемішування.
CHAP – це вдосконалення PAP, у якому відкритий текст пароля не пересилається через сполучення. Замість цього пароль використовується для створення зашифрованого перемішування (hash) із оригінального виклику (challenge). Сервер знає відкритий текст пароля клієнта, тому може повторити операцію і порівняти результат у паролі, який висилається у відповідь клієнту. CHAP захищає проти атаки (replay attack), використовуючи довільний рядок виклику при кожній спробі автентифікації. CHAP захищає проти фальсифікації віддаленого клієнта шляхом непрогнозованого висилання повторних викликів до віддаленого клієнта протягом періоду тривання сполучення.
Microsoft Challenge Handshake Authentification Protocol (MS-CHAP). MS-CHAP – це шифрований механізм автентифікації, дуже подібний до CHAP. Подібно до CHAP, NAS висилає до клієнта виклик, який складається із ідентифікатора сесії (session ID) і довільного рядка виклику. Віддалений клієнт повинен повернути ім’я користувача, MD4-hash рядка виклику, ідентифікатор сесії і пароль, зашифрований перемішуванням MD4. Така конструкція, яка оперує перемішуванням MD4-hash пароля, забезпечує додатковий рівень безпеки, бо дозволяє серверу зберігати перемішаний пароль замість відкритого тексту пароля. MS-CHAP також забезпечує додатковий код помилки включно з кодом пароля, який втратив чинність, та додаткові шифровані повідомлення клієнт-сервер, які дозволяють користувачу змінювати свій пароль. У Microsoft-впровадженнях MS-CHAP клієнт і NAS незалежно генерують початкові ключі для наступного шифрування даних через MPPE. Останній пункт дуже важливий, бо він пояснює, чому автентифікація MS-CHAP необхідна для створення можливості шифрування даних на основі MPPE.
Фаза 3: Зворотній виклик PPP (PPP callback control). Microsoft-впровадження PPP включають опційну фазу зворотнього виклику (Callback Control Phase). Ця фаза використовує протокол управління зворотнім викликом (Callback Control Protocol - CBCP) безпосередньо після фази автентифікації. Клієнт і NAS, якщо вони сконфігуровані для зворотнього виклику, після автентифікації переривають сполучення. Тоді NAS здійснює зворотній виклик віддаленого клієнта через визначений теелефонний номер. Це забезпечує додатковий рівень безпеки для мережевої взаємодії через комутовані телефонні канали. NAS може дозволити сполучення від віддаленого клієнта, який користується тільки визначеним телефонним номером.
Фаза 4: активування протоколів Мережевого рівня. Як тільки попередні фази завершені, PPP активує різні протоколи управління мережею (Network Control Protocol – NCP), вибрані під час фази встановлення зв’язку (Фаза 1) для конфігурування протоколів, що використовуються віддаленим клієнтом. Наприклад, протягом цієї фази протокол управління IP (IP Control Protocol – IPCP) може призначити динамічну адресу користувачу комутованого телефонного каналу. У Microsoft-впровадженнях PPP використовується протокол управління компресією для узгодження як компресії даних із вживанням MPPC, так і компресії даних із використанням MPPE, оскільки обидва ці потоколи впроваджені у тій самій процедурі.
Фаза персилання даних. Коли чотири фази узгодження завершені, PPP розпочинає висилання даних між двома сторонами сполучення. Кожний пакет даних вставляється у заголовок PPP, який потім видаляється у приймальній системі. Якщо компресія даних вибрана протягом Фази 1 та узгоджена під час Фази 4, то дані стискають перед висиланням. Якщо шифрування даних вибране і узгоджене подібним чином, то дані (опційно скомпесовані) можуть бути зашифровані перед пересиланням.
Протокол тунелювання “пункт-пункт” (Point-to-Point Tunneling Protocol – PPTP).
PPTP – це протокол Рівня 2, який інкапсулює рамки PPP у IP-данограми для пересилання через IP-мережі. PPTP також може застосовуватися у приватних об’єднаннях мереж LAN-LAN. PPTP удокументований у проекті RFC “Point-to-Point Tunneling Protocol”. PPTP використовує TCP-сполучення для обслуговування тунелю і загальну раутінгову інкапсуляцію (Generic Routing Encapsulation – GRE) для інкапсуляції PPP-рамок для тунельованих даних. Корисне навантаженння інкапсульованих PPP-рамок може бути зашифроване і/або скомпресоване. На рис. показано, як PPTP-пакет асемблюється перед пересиланням. Рисунок показує утворення тунелю через об’єднання мереж для клієнта комутованого телефонного каналу. Ескіз останньої рамки показує інкапсуляцію для такого клієнта (PPP Device Driver).
Адресація та раутінг у VPN
Для того, щоб розуміти, як працює VPN, слід розглянути, як створення VPN для віддаленого доступу і VPN між раутерами впливає на адресацію та раутінг. VPN-сполучення створюють віртуальний інтерфейс, якому слід надати правильну IP-адресу, а маршрути повинні змінюватися або додаватися для того, щоб правильний трафік висилався через захищене VPN-сполучення, замість через спільну або публічну транзитну мережу.
VPN-сполучення із віддаленим доступом
Для сполучення VPN із віддаленим доступом комп’ютер створює сполучення з віддаленим доступом до сервера VPN. Протягом процесу сполучення VPN-сервер призначає IP-адресу для VPN-клієнта віддаленого доступу і змінює маршрут за замовчуванням до віддаленого клієнта так, щоб відповідний трафік висилався через віртуальний інтерфейс.
IP-адреси і VPN-клієнт із доступом через комутовані канали.
Для VPN-клієнта із доступом через комутовані канали, який з’єднується з Internet перед створенням VPN-сполучення з VPN-сервером у Internet, виділяються дві IP-адреси:
коли створюється PPP-сполучення, то IPCP-узгодження із сервером мережевого доступу ISP призначає публічну IP-адресу;
коли створюється VPN-сполучення, то IPCP-узгодження з VPN-сервером призначає IP-адресу в intranet; ця адреса, призначена VPN-сервером, може бути публічною або приватною, залежно від того, від кого організація впровадила публічну або приватну адресацію для свого intranet.
У кожному випадку IP-адреса, виділена для VPN-клієнта, повинна бути досяжна для гостів у intranet і навпаки. VPN-сервер мусить мати призначені входи у своїй таблиці раутінгу, щоб досягнути всі гости в intranet, а також раутери в intranet мусять мати призначені входи у своїх таблицях раутінгу для досягнення VPN-клієнта.
Тунельовані дані, які висилаються через VPN, заадресовані від адрес джерел, призначених VPN-клієнтам VPN-сервером, до intranet-адрес призначення. Зовнішній IP-заголовок заадресований між IP-адресою VPN-клієнта, виділеною ISP, і публічною адресою VPN-сервера. Оскільки раутери в Internet обробляють тільки зовнішній IP-заголовок, то раутери Internet пересилають тунельовані дані до публічних адрес VPN-серверів. Прклад адресації для клієнта комутованих каналів показаний на рис. , де організація використовує приватні адреси в intranet і тунельовані дані – це IP-данограми.
Рис.12 . Публічні та приватні адреси в тунельованих даних PPTP.
Маршрути за замовчуванням і клієнти комутованих каналів.
Коли типовий клієнт комутованих каналів викликає ISP, то він приймає публічну IP-адресу від NAS ISP. Адреса шлюзу за замовчуванням не виділяється як частина процесу узгодження IPCP. Тому для досягнння всіх Internet-адрес клієнт комутованих каналів додає маршрут за замовчуванням до своєї таблиці раутінгу, використовуючи інтерфейс комутованого каналу, сполученого з ISP. У результаті клієнт може пересилати IP-данограми до NAS ISP, звідки вони маршрутуються до свого Internet-призначення. Для клієнтів комутованих каналів без інших TCP/IP-інтерфейсів це оголошена поведінка, однак вона може викликати плутанину для клієнтів комутованих каналів, які мають чинне сполучення з intranet через LAN. У цьому сценарії маршрут за замовчуванням завжди існує, вказючи локальний раутер intranet. Коли клієнт комутованих каналів створює сполучення із своїм ISP, то початковий маршрут за замовчуванням залишається в таблиці раутінгу, але його метрика збільшується. Новий маршрут за замовчуванням додається із меншим значенням метрики через сполучення з ISP. Внаслідок цього intranet-розміщення, які не є мережами, безпосередньо під’єднаними до клієнта комутованих каналів, недосяжні протягом тривання сполучення до ISP. Якщо новий маршрут за замовчуванням не створений, то всі intranet-розміщення досяжні, але Internet-розміщення – ні.
Щоб досягнути сполучності як з intranet-, так і з Internet-розміщеннями, коли ISP-сполучення активне, слід залишити опцію Use default gateway для віддаленої мережі і додати маршрути intranet до таблиці раутінгу клієнта комутованих каналів. Маршрути intranet можна додати через постійні статичні маршрути з використанням утиліти route, або, якщо як протокол раутінгу intranet вживається RIPv1, то можна використати Route Listening Service для прослуховування трафіку раутінгу і динамічного додавання маршрутів intranet. При під’єднанні до ISP всі intranet- та Internet-розміщення досяжні із використанням маршрутів за замовчуванням.
Маршрути за замовчуванням і віртуальні приватні мережі через Internet.
Коли клієнт комутованих каналів викликає ISP, то він додає маршрут за замовчуванням, використовуючи сполучення до ISP, як це показано на рис. 13.
Рис. 13 Маршрути за замовчуванням при виклику ISP через комутовані канали.
Від цього пункту він може досягнути всі Internet-адреси через раутер в NAS ISP.
Коли VPN-клієнт створює VPN-сполучення, то додаються інші маршрути за замовчуванням і маршрути гостів з IP-адресою тунельного сервера, як показано на рис. . Попередній маршрут за замовчуванням зберігається, але отримує більшу метрику. Додання нового маршруту за замовчуванням означає, що всі Internet-розташування за винятком IP-адреси тунельного сервера недосяжні протягом часу тривання VPN-сполучення.
Рис. 14. Маршрути за замовчуванням при ініціюванні VPN.
Як у випадку сполучення клієнта комутованих каналів з Internet, коли клієнт, використовуючи добровільний тунель, створює VPN-сполучення до приватного intranet через Internet, наступає одна із таких подій:
Internet-розміщення досяжні, а intranet-розміщення недосяжні, коли VPN-сполученя неактивне;
Internet -розміщення недосяжні, а intranet-розміщення досяжні, коли VPN-сполученя активне.
Для більшості VPN-клієнтів, сполучених через Internet, така поведінка не створює проблем, бо вони звичайно використовують одну із intranet- або Internet-комунікацій, а не обидві. Для VPN-клієнтів, які хочуть одночасно мати доступ як до intranet-, так і до Internet-ресурсів, розв’язання залежить від способу IP-адресації в intranet. У всіх випадках об’єкт VPN-сполучення конфігурується так, що він не додає шлюзу за замовчуванням. Оли VPN-сполучення створене, маршрут за замовчуванням продовжує вказувати на NAS ISP, дозволяючи доступ до всіх адрес Internet.
Базуючись на типі intranet-адресації, яка вживається, можна отримати доступ до intranet- або Internet-ресурсів таким чином:
Публічні адреси. Додати статичні постійні маршрути до ідентифікаторів публічних мереж в intranet, використовуючи IP-адресу віртуального інтерфейсу VPN-сервера як IP-адресу шлюзу.
Приватні адреси. Додати статичні постійні маршрути до ідентифікаторів приватних мереж в intranet, використовуючи IP-адресу віртуального інтерфейсу VPN-сервера як IP-адресу шлюзу.
Суміщені або нелегальні адреси. Якщо в intranet використовуються суміщені або нелегальні адреси (ідентифікатори IP-мережі не є приватними і не зареєстровані в Internet Network Information Center (InterNIC) або не отримані від ISP), то ці IP-адреси можуть бути здубльовані публічними адресами в Internet. Якщо статичні постійні маршрути додані VPN-клієнту для суміщення ідентифікаторів мережі в intranet, то розміщення в Internet для суміщених адрес недосяжні.
У кожному із цих випадків статичні постійні маршрути для мережевих ідентифікаторів з intranet необхідно додати до VPN-клієнта. Коли постійні маршрути додані, то вони зберігаються в реєстрі. У Windows NT 4.0 та Windows 2000 постійні маршрути тепер не додаються до IP-таблиці раутінгу (та невидимі з командою route print для Windows 2000), доки IP-адреса шлюзу досяжна. IP-адреса шлюзу стає досяжною, коли встановлене VPN-сполучення.
Для кожного маршруту слід ввести таку команду для Windows 2000:
ROUTE ADD <intranet Network ID> <IP address of VPN server’s virtual interface> -p
IP-адреса шлюза в команді route для кожного intranet-маршруту – це IP-адреса, призначена віртуальному інтерфейсу VPN-сервера, а не IP-адреса Internet-інтерфейсу VPN-сервера.
У всіх цих випадках слід дуже старанно додавати маршрути, щоб приватний трафік intranet був пересланий через VPN-сполучення, а не через PPP-сполучення до ISP. Якщо додані неправильні маршрути, то трафік, який слід було вислати через VPN у зашифрованій формі, буде пересилатися незашифрованим через Internet. Наприклад, якщо intranet використовує публічний ідентифікатор мережі 207.46.130.0/24 (маска підмережі 255.255.255.0) і помилково додано постійний статичний маршрут для 207.46.131.0/24, то весь трафік до intranet-мережі 207.46.130.0/24 буде вислано через Internet відкритим текстом.
VPN-сполучення раутер-раутер
Для VPN раутер-раутер інтерфейс раутінгу, який вживається для висилання пакетів - це інтерфейс через комутовані канали на вимогу, який конфігурується таким чином:
у таблиці General вказати ім’я госта або IP-адресу VPN-сервера;
у таблиці Security вибрати або Secure my password and Data, або Custom;
у таблиці Networking вибрати відповідний тип сервера і протоколи, які будуть маршрутовані. Якщо тип сервера встановлено в Automatic, то спочатку слід спробувати сполучення L2TP через IPSec, а потім сполучення PPTP;
У Interface credentials (мандати інтерфейсів) ввести ім’я користувача, пароль і доменне ім’я, яке вживається для верифікації раутера, що здійснює виклик.
Створення інтерфейсів через комутовані канали на вимогу автоматизоване через Demand-Dial Interface Wizard. Імена інтерфейсів через комутовані канали на вимогу і мандати раутера, що здійснює виклик, можуть потребувати правильного узгодження, щоб досягнути VPN-сполучення раутер-раутер.
Тимчасові або постійні віртуальні приватні мережі раутер-раутер.
VPN-сполучення раутер-раутер можуть бути тимчасовими або постійними. Тимчасові VPN-сполучення раутер-раутер здійснюють, якщо є пакети, які будуть маршрутовані через інтерфейс VPN через комутовані канали на вимогу і сполучення буде завершене після визначеного періоду простою. Час простою конфігурується як у VPN-клієнті (раутер, який викликає), так і у VPN-сервері (раутер, який викликають). Час простою інтерфейсів через комутовані канали на вимогу за замовчуванням у VPN- клієнтів не обмежується; для VPN-серверів він становить 20 хвилин. Однак загалом час простою можна конфігурувати.
Постійні VPN-сполучення раутер-раутер здійснюють, якщо раутер стартує і залишається сполученим незалежно від того, чи пересилається трафік. Якщо VPN-сполучення завершується, то автоматично здійснюється спроба встановити його знову.
Віртуальні приватні мережі з використанням сполучень через комутовані канали з ISP.
Якщо VPN-сервер і VPN-клієнт безпосередньо сполучені з Internet через постійний WAN-зв’язокЮ наприклад, через канал E1 або Frame Relay, то VPN-сполучення може бути постійним і чинним 24 години на добу. Однак, коли постійний WAN-зв’язок неможливий або непрактичний, то можна сконфігурувати VPN-сполучення на вимогу, використовуючи доступ через комутовані канали до ISP. VPN-сполучення раутер-раутер на вимогу із використанням сполучення до iSP через комутовані канали має два інтерфейси:
інтерфейс виклику на вимогу для виклику ISP;
інтерфейс виклику на вимогу для VPN-сполучення раутер-раутер.
Виклик на вимогу VPN-сполучення раутер-раутер автоматично здійснюється, коли трафік, який пересилається крізь VPN-сполучення, приймається раутером у віддаленому офісі.Наприклад, якщо приймається пакет, який повинен маршрутуватися до центрального офісу організації, то раутер віддаленого офісу спочатку використовує зв’язок через комутовані канали, щоб з’єднатися з локальним ISP. Коли Internet-сполучення встановлене, то раутер віддаленого офісу як VPN-клієнт створює VPN-сполучення раутер-раутер з раутером центрального офісу – VPN-сервером.
Щоб сконфігурувати таке сполучення, у раутері віддаленого офісу необхідно:
створити інтерфейс виклику на вимогу для Internet-сполучення, сконфігурованого для відповідного обладнання (модему або пристрою ISDN), телефонного номера локального ISP та імені користувача і паролю, які вживаються для доступу до Internet;
створити інтерфейс виклику на вимогу для VPN-сполучення раутер-раутер із раутером центрального офісу, сконфігурованого для PPTP або L2TP, IP-адреси або імені госта інтерфесу VPN-сервера в центральному офісі для доступу до Internet, імені користувача та паролю, які повинні бути верифіковані VPN-сервером. Ім’я користувача повинне повинне бути узгоджене з іменем інтерфейсу виклику на вимогу у VPN-сервері центрального офісу;
створити статичний маршрут госта для IP-адреси Internet-інтерфейсу VPN-сервера, який використовує інтерфейс виклику на вимогу для виклику локального ISP.
створити статичний маршрут або маршрути для ідентифікаторів IP-мережі intranet організації, який використовує VPN-інтерфейс виклику на вимогу.
Щоб сконфігурувати раутер центрального офісу, необхідно:
створити інтерфейс виклику на вимогу для VPN-сполучення з віддаленим офісом, сконфігурованим для VPN-пристрою (порт PPTP або L2TP). Інтерфейс виклику на вимогу повинен мати те ж ім’я, що й ім’я користувача в мандаті автентифікації, який вживається длястворення VPN-сполучення раутером віддаленого офісу;
створити статичний маршрут або маршрути для ідентифікатора IP-мережі віддаленого офісу, який використовує VPN-інтерфейс виклику на вимогу.
VPN-сполучення раутер-раутер автоматично ініціюється раутером віддаленого офісу з таким процесом:
Пакети, призначені до розташування мережевого габа організації від користувача у віддаленому офісі, пересилаються користувачем до раутера віддаленого офісу.
Раутер віддаленого офісу перевіряє свою таблицю раутінгу і знаходить маршрут до ідентифікатора intranet організації, який використовує VPN-інтерфейс виклику на вимогу.
Раутер віддаленого офісу перевіряє стан VPN-інтерфейсу виклику на вимогу і встановлює, що він є у від’єднаному стані.
Раутер віддаленого офісу відновлює конфігурацію VPN-інтерфейсу виклику на вимогу.
Базуючись на конфігурації VPN-інтерфейсу виклику на вимогу, раутер віддаленого офісу пробує ініціювати VPN-сполучення раутер-раутер за IP-адресою VPN-сервера в Internet.
Для встановлення VPN мусить бути встановлене або TCP/IP-сполучення (з використанням PPTP), або здійснене узгодження IPSec із VPN-сервером. Створюється пакет встановлення VPN.
Для пересилання пакету встановлення VPN до раутера організації раутер віддаленого офісу перевіряє свою таблицю раутінгу і знаходить маршрут госта, який вживається для ISP-інтерфейсу виклику на вимогу.
Раутер віддаленого офісу перевіряє стан ISP-інтерфейсу виклику на вимогу і знаходить його у від’єднаному стані.
Раутер віддаленого офісу відновлює конфігурацію ISP-інтерфейсу виклику на вимогу.
Базуючись на конфігурації ISP-інтерфейсу виклику на вимогу, раутер віддаленого офісу використовує модем або ISDN-адаптер для виклику і встановлення сполучення із своїм локальним ISP.
Коли сполучення із ISP встановлене, то раутер віддаленого офісу висилає пакет встановлення VPN до раутера центрального офісу організації.
VPN узгоджується між раутерами віддаленого офісу і центрального офісу організації.Раутер віддаленого офісу як частину узгодження висилає мандат автентифікації, який верифікується раутером центрального офісу.
Раутер центрального офісу перевіряє свої інтерфейси виклику на вимогу і знаходить узгоджений із іменем користувача, висланим для автентифікації, і встановлює інтерфейс у стан з’єднання.
Раутер віддален...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора