87. Опишіть поняття тунелювання та його види у віртуальних приватних мережах.

Т унелювання.Висилання певної частини мережевого трафіку через тунель є іншим методом побудови VPN, більш ефективним від інших. Найбільш поширеним механізмом тунелювання є використання загальної раутингової інкапсуляції (Generic Routing Incapsulation – GRE) між джерелом і раутером призначеня, між раутерами, або протоколів тунелювання між станціями, таких як L2TP, PPTP і DVMRP. Тунелювання можна розглядати як модель накладання, однак серйозність впливу масштабування приводить до того, що тунелі здійснюють за схемами “пункт-пункт” або “пункт-багато пунктів”. Тунелі “пункт-пункт” маєть менше проблем з масштабуванням, ніж тунелі “пункт-багато пунктів”, за вийнятком ситуацій, коли окремий вузол починає будувати багато тунелів “пункт-пункт” з багатьма кінцевими пунктами. Коли лінійна проблема масштабування уведена від цього пункту, то керованість тунелів “пункт-пункт” здійснюється виключно через адміністративне навантаження і тим самим через самі тунелі. З другого боку, тунелі “пункт-багато пунктів”, які використовують транзитний механізм, щоб збільшити кількість кінцевих пунктів на відстані одного стрибка від довільного іншого, потім створюють значно більш серйозну проблему масштабування.

Рис. 1. Традиційна модель тунелювання.

Традиційний режим тунелювання

Тунелі 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). Перший раніше називали “добровільним” тунелем, тоді як другий –“вимушеним” тунелем. Добровільний тунель називається так тому, що тунель створюється на запит користувача для спеціального призначення; вимушений тунель створюється без жодної дії з боку користувача і не дозволяючи йому жодних змін по суті.

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

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

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