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

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