Введення в тунелі GRE

GRE є протоколом тунеллюванням, визначеним в RFC 1702 і RFC 2784. Спочатку він був розроблений Cisco для створення віртуальної магістральної лінії до маршрутизаторів Cisco у віддалених точках по об’єднаної IP-мережі.

GRE підтримує багатопротокольне тунелювання. Це може інкапсулювати багатократні типи пакету протоколу третього рівня моделі OSI в тунелі IP. Додавання додаткового заголовка GRE між корисним навантаженням і заголовка IP, що тунелює, забезпечує багатопротокольну функціональність. Тунелювання IP за допомогою GRE включає розширення мережі шляхом з’єднання багатопротокольних підмереж через однопротокольне магістральне середовище. GRE також підтримує тунелювання багатоадресного IP-пакета. Протоколи маршрутизації, що використовуються через тунель, включають динамічний обмін маршрутною інформацією у віртуальній мережі.

Тунелі GRE є такими, що не зберігають стан. Кожна кінцева точка тунелю не зберігає інформації про стан або доступність віддаленої кінцевої точки тунелю. Ця функція допомагає постачальникам послуг (SPs), надати тунелі IP клієнтам, які не стурбовані внутрішньою архітектурою, у кінці SP. У клієнтів тоді є гнучкість, щоб конфігурувати або реконфігурувати їх архітектуру IP, але все ще підтримати зв’язок. Це створює віртуальну магістральну лінію до маршрутизаторів у віддалених точках по об’єднаній IP-мережі. GRE не включає сильних механізмів захисту для забезпечення конфіденційності.

Заголовок GRE

GRE інкапсулює увесь початковий пакет IP із стандартним заголовком IP і заголовком GRE (рис. 2.), заголовок тунелю GRE містить принаймні два 2-байтові обов’язкові поля:

• прапор GRE;
• тип протоколу;

GRE використовує поле типу протоколу в заголовку GRE для підтримки інкапсуляції будь-якого протоколу третього рівня моделі OSI. Заголовок GRE, разом із заголовком IP створює принаймні 24 байти додаткових витрат для пакетів, що тунелюють.

Конфігурація GRE

Існує п'ять кроків конфігурації тунелю GRE :

• Крок 1. Створіть тунельний інтерфейс.
• Крок 2. Призначте IP-адресу тунелю.
• Крок 3. Ідентифікуйте початковий тунельний інтерфейс.
• Крок 4. Ідентифікуйте місце призначення тунелю.
• Крок 5. Зазначте, який протокол GRE інкапсулює використання режиму тунелювання.

Тунель GRE налаштований вірно, якщо:

• тунельне джерело і місце призначення конфігуровані;
• тунельне місце призначення знаходиться в таблиці маршрутизації;
• повідомлення активності GRE отримані (якщо використовується);
• GRE є режимом за умовчанням.

Перевага GRE полягає в тому, що він може використовуватися для тунелювання трафіку, який не відноситься до IP по мережі IP. На відміну від IPsec, що тільки підтримує одноадресний трафік, GRE підтримує багатоадресний трафік і широкомовний трафік по тунельному посиланню. Тому протоколи маршрутизації і підтримуються в GRE.

Для забезпечення конфіденційності має бути конфігурований IPsec.

Тунелі IPsec

IPsec є стандартом IETF (RFC 2401-2412), який визначає, як VPN може бути конфігурований за допомогою протоколу IP - адресації. IPsec забезпечує конфіденційність даних, цілісність даних і аутентифікацію джерела. IPsec не зв’язується ні з яким певним шифруванням, аутентифікацією, алгоритмами безпеки або іншими технологіями. IPsec є платформою відкритих стандартів, що докладно пояснюють правила для безпечного зв’язку. IPsec покладається на існуючі алгоритми для реалізації шифрування, автентифікації і ключового обміну (рис. 7).

IPsec працює на мережному рівні, захищаючи і автентифікуючи пакети IP між пристроями IPsec. В результаті IPsec може захистити фактично увесь трафік, тому що захист може бути реалізований на всіх рівнях моделі осі вище четвертого. Усі реалізації IPsec мають простий заголовок мережного рівня, таким чином, немає жодних проблем з маршрутизацією. IPsec функціонує по усіх протоколах канального рівня, таким як Ethernet, ATM, Frame Relay, Синхронне управління каналом передачі даних (SDLC) і Високорівневе управління каналом передачі даних (HDLC).

IPsec служить основою і адміністратор вибирає алгоритми, які будуть використовуватись для реалізації служб безпеки. Не зв'язуючи IPsec з певними алгоритмами, це дозволяє новішим і кращим алгоритмам бути реалізованими, не виправляючи існуючі стандарти IPsec.

IPsec може захистити шлях між парою шлюзів, парою вузлів, або шлюзом і вузлом (рис. 8).

Конфіденційність – IPsec гарантує конфіденційність за допомогою шифрування.

Цілісність – IPsec гарантує, що дані прибувають незмінні в місце призначення, за допомогою використання хеш-алгоритмыв, таких як MD5 або SHA1.

Аутентифікація – IPsec використовує обмін ключами між мережами (IKE) для автентифікації користувачів і пристроїв, які можуть виконати комунікацію незалежно. IKE використовує декілька типів автентифікації, включаючи ім'я користувача і пароль, одноразовий пароль, біометрику, заздалегідь спільно використовуючи ключі (PSKs) і цифрові сертифікати.

Безпечний ключовий обмін – IPsec використовує алгоритм DH для забезпечення обмінного методу з відкритим ключем для двох колег для встановлення спільно використання секретного ключа.

Протоколи платформи IPsec

IPsec є платформою відкритих стандартів. IPsec докладно пояснює обмін повідомленнями для забезпечення зв’язку, але покладається на існуючі алгоритми. Двома основними протоколами платформи IPsec є заголовок автентифікації (AH) і протокол системи захисту інкапсуляції (ESP).

AH – є протоколом 51 IP, коли конфіденційність не вимагається або дозволяється. Він забезпечує аутентифікацію даних і цілісність для пакетів IP, що передаються між двома системами. Це гарантує, що джерело даних (або R1 або R2) перевіряється на те, що дані не були змінені під час транзиту. AH не забезпечує конфіденційність (шифрування) цих  пакетів. Увесь текст транспортується незашифрований. Якщо протокол AH використовується один, то він забезпечує слабкий захист.

ESP – є протоколом 50 IP, він може забезпечити конфіденційність і аутентифікацію. Протокол забезпечує конфіденційність шляхом виконання шифрування пакетів IP. Шифрування пакетів IP приховує корисне навантаження даних і ідентифікаційні дані остаточного джерела і місця призначення. ESP забезпечує аутентифікацію для внутрішнього пакету IP і заголовка ESP. Аутентифікація забезпечує перевірку джерел даних і цілісність даних.

Не дивлячись на те, що і шифрування і аутентифікація є додатковими в ESP, як мінімум, один з цих двох протоколів має бути вибраний.

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

Функція AH застосовується до цілого пакету, за винятком будь-яких непостійних полів заголовка IP та зміна в дорозі.

Процес AH відбувається в такому порядку (рис. 9 - 10):

1. Заголовок IP і корисне навантаження даних хешуються за допомогою спільно використовуваного секретного ключа.
2. Хеш створює новий заголовок AH, що вставляється в початковий пакет.
3. Новий пакет передається до віддаленого маршрутизатора IPsec.
4. Віддалений маршрутизатор хешує заголовок IP і корисне навантаження даних за допомогою спільно використовуваного секретного ключа, витягає хеш із заголовка AH і порівнює два хеша.

Хеши повинні відповідати точно. Якщо один біт буде змінений в переданому пакеті, то виведення хеша на змінах отриманого пакету і заголовку AH не відповідатиме.

AH підтримує HMAC - MD5 і HMAC - SHA - 1 алгоритми (рис. 11). AH може мати проблеми, якщо середовище використовує NAT.

ESP забезпечує конфіденційність шляхом шифрування корисного навантаження. Він підтримує безліч симетричних алгоритмів шифрування. Якщо ESP вибраний як протокол IPsec, алгоритм шифрування має також бути вибраний. Алгоритмом за умовчанням для IPsec є 56-розрядний DES. Продукти Cisco також підтримують використання 3DES, AES і SEAL для посиленого шифрування.

ESP може також забезпечити цілісність і аутентифікацію. По-перше, корисне навантаження шифрується. Потім, зашифроване корисне навантаження вирушає через хеш-алгоритм, HMAC - MD5 або HMAC - SHA - 1. Хеш забезпечує аутентифікацію і цілісність даних для корисного навантаження даних (рис. 12).

Коли з'єднання встановлене між джерелом і місцем призначення, їх лічильники ініціалізувалися в нулі. Кожного разу, коли пакет вирушає, порядковий номер додається до пакету джерелом. Місце призначення використовує визначає, які порядкові номери очікуються. Місце призначення перевіряє, що порядковий номер пакету не дубльований і отриманий в правильному порядку.

Обмін ключами між мережами

Рішення VPN IPsec погоджує ключові обмінні параметри, встановлює спільно використовуваний ключ, автентифікує колегу і погоджує параметри шифрування. Узгоджені параметри між двома пристроями відомі як асоціація по безпеці (SA) (рис. 13).

SA є основою IPsec. Асоціації по безпеці зберігаються в базі даних SA (SADB), встановленій кожним пристроєм. VPN має записи SA, визначальні параметри шифрування IPsec, а також записи SA, що визначають ключові обмінні параметри.

Усі криптографічні системи, включаючи шифр Цезаря, шифр Vigenere, машину Загадки, до сучасних алгоритмів шифрування, повинні мати справу з проблемами управління ключами. DH використовується для створення спільно використовуваного секретного ключа. Проте IPsec використовує протокол IKE для встановлення ключового обмінного процесу.

Замість того, щоб передати ключі безпосередньо через мережу, IKE обчислює спільно використані ключі на основі обміну серією пакетів даних. Це відключає третю особу від дешифрування ключів, навіть якщо третя особа отримала усі передані дані, що використовуються для обчислення ключів.

IKE розділений на рівні UDP і використовує порт UDP 500 для обміну інформацією про IKE між шлюзами безпеки. Порт UDP 500 має бути дозволений в будь-якому інтерфейсі IP, залученому в з’єднанні колеги шлюзу безпеки.

IKE визначається в RFC 2409. Це – гібридний протокол, комбінуючий асоціацію захисту в мережі Інтернет і протокол управління ключами (ISAKMP) і методи обміну ключа Оукли і Скема. ISAKMP визначає формат повідомлення, механіку ключового протоколу обміну і процес узгодження для створення SA для IPsec. ISAKMP не визначає, як управляють ключами або спільно їх використовують в IPsec. У Оукли і Скема є п'ять певних ключових груп. З цих груп, групи підтримки маршрутизаторів Cisco 1 (768-розрядний ключ), Група 2 (1024-розрядний ключ) і Група 5 (1536-розрядний ключ).

IKE комбінує ці протоколи для створення безпечних з’єднань IPsec між пристроями. У кожного колеги мають бути ідентичний ISAKMP і параметри IPsec для встановлення операційного і безпечного VPN. Зверніть увагу на те, що терміни ISAKMP і IKE зазвичай використовуються галузевими людьми для звернення до IKE.

Альтернатива використанню IKE означає вручну конфігурувати усі параметри, які потрібні для встановлення безпечного з’єднання IPsec. Цей процес непрактичний, тому що він не масштабується.

Для встановлення безпечного каналу передачі між двома колегами протокол IKE виконує дві фази (рис. 14 - 15):

Фаза 1 – два колеги IPsec виконують початкове узгодження SAs. Основна мета Фази 1 полягає в тому, щоб погоджувати набори політики IKE, автентифіковувати колег і встановлювати безпечний канал між ними. Це може бути реалізовано в основному режимі або агресивному режимі.

Фаза 2 - SAs узгоджує ISAKMP з процесом IKE від імені IPsec. Це може бути узгоджено в швидкому режимі.

Конфігурація Site-to-Site IPsec VPNs з CLI

VPN є каналом передачі, що використовується для формування логічного з’єднання між двома кінцевими точками по мережі загального користування. VPN не обов’язково включають шифрування або аутентифікацію. IPsec VPN покладаються на протокол IKE для встановлення безпечного зв’язку.

Узгодження VPN IPsec включає п’ять кроків, що включають Фазу 1 і Фазу 2 узгодження IKE (рис. 16 - 22).

Крок 1. Тунель IPsec ініціюється, коли вузол A відправляє «цікавий» трафік для хостингу B. Трафік вважають цікавим, коли він переміщається між IPsec, взаємодіє і відповідає критеріям, які визначені в crypto ACL.

Крок 2. Починається Фаза 1 IKE . Колеги IPsec погоджують встановлену політику IKE SA. Коли сторони автентифікуються, безпечний тунель створюється за допомогою ISAKMP.

Крок 3. Починається Фаза 2 IKE. Рівноправне використання IPsec автентифікуючийся безпечний тунель для узгодження IPsec SA. Узгодження спільно використовуваної політики визначає, як встановлений Ipsec тунель.

Крок 4. Створюється тунель IPsec, і дані передаються між сторонами IPsec на основі параметрів IPsec, конфігурованих в IPsec.

Крок 5. Тунель IPsec завершується, коли SAs IPsec віддалений, або коли їх час життя збігає.