Література
INTUIT.ru: Курс: Руководство по безопасности в Lotus Notes : Лекция № 5: Прокси-серверы
Тема 15. Захищені віртуальні канали. Стек протоколів ipSec
Технологія віртуальних каналів
Техніка віртуальних каналів, яка використовується у всіх територіальних мережах з комутацією пакетів, крім TCP/IP, полягає в наступному.
Перш ніж пакет буде переданий через мережу, необхідно встановити віртуальне з'єднання між абонентами мережі – терміналами, маршрутизаторами чи комп'ютерами. Існують два типи віртуальних з'єднань – віртуальний канал, що комутується (Switched Virtual Circuit, SVC) і постійний віртуальний канал (Permanent Virtual Circuit, РVС). При створенні віртуального каналу, що комутується, комутатори мережі настроюються на передачу пакетів динамічно, по запиті абонента, а створення постійного віртуального каналу відбувається заздалегідь, причому комутатори настроюються вручну адміністратором мережі, можливо, із залученням централізованої системи керування мережею.
Зміст створення віртуального каналу полягає в тому, що маршрутизація пакетів між комутаторами мережі на основі таблиць маршрутизації відбувається тільки один раз – при створенні віртуального каналу (мається на увазі створення віртуального каналу, що комутується, оскільки створення постійного віртуального каналу здійснюється вручну і не вимагає передачі пакетів по мережі). Після створення віртуального каналу передача пакетів комутаторами відбувається на основі так званих номерів чи ідентифікаторів віртуальних каналів (Virtual Channel Identifier, VCI). Кожному віртуальному каналу присвоюється значення VCI на етапі створення віртуального каналу, причому це значення має не глобальний характер, як адреса абонента, а локальний – кожен комутатор самостійно нумерує новий віртуальний канал. Крім нумерації віртуального каналу, кожен комутатор при створенні цього каналу автоматично настроює так звані таблиці комутації портів – ці таблиці описують, на який порт потрібно передати пакет, що прийшов, якщо він має визначений номер VCI. Так що після прокладки віртуального каналу через мережу комутатори більше не використовують для пакетів цього з'єднання таблицю маршрутизації, а передають пакети на основі номерів VCI невеликої розрядності. Самі таблиці комутації портів також включають звичайно менше записів, чим таблиці маршрутизації, тому що зберігають дані тільки про діючі на даний момент з'єднання, що проходять через даний порт.
Робота мережі по маршрутизації пакетів прискорюється за рахунок двох факторів. Перший полягає в тому, що рішення про передачу пакета приймається швидше через менший розмір таблиці комутації. Другим фактором є зменшення частки службової інформації в пакетах. Адреси кінцевих вузлів у глобальних мережах зазвичай мають досить велику довжину – 14-15 десяткових цифр, що займають до 8 байт (у технології АТМ – 20 байт) у службовому полі пакета. Номер віртуального каналу зазвичай займає 10-12 біт, так що накладні витрати на адресну частину істотно скорочуються, а виходить, корисна швидкість передачі даних зростає.
Режим PVC є особливістю технології маршрутизації пакетів у глобальних мережах, у мережах TCP/IP такого режиму роботи немає. Робота в режимі PVC є найбільш ефективною за критерієм продуктивності мережі. Половину роботи з маршрутизації пакетів адміністратор мережі уже виконав, тому комутатори швидко займаються передаванням кадрів на основі готових таблиць комутації портів. Постійний віртуальний канал подібний виділеному каналу в тому, що не потрібно встановлювати з'єднання чи роз'єднання. Обмін пакетами по PVC може відбуватися в будь-який момент часу. Відмінність PVC у мережах Х.25 від виділеної лінії типу 64 Кбіт/с полягає в тому, що користувач не має ніяких гарантій щодо дійсної пропускної здатності PVC. Використання PVC звичайно набагато дешевше, ніж оренда виділеної лінії, тому що користувач поділяє пропускну здатність мережі з іншими користувачами.
Режим просування пакетів на основі готової таблиці комутації портів звичайно називають не маршрутизацією, а комутацією і відносять не до третього, а до другого (канальному) рівня стека протоколів.
Принцип маршрутизації пакетів на основі віртуальних каналів пояснюється на рисунку 15.1. При встановленні з'єднання між кінцевими вузлами використовується спеціальний тип пакета – запит на встановлення з'єднання (зазвичай називається Call Request), що містить багаторозрядну (у прикладі семирозрядну) адресу вузла призначення.
Табл. маршрутизації К1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Адреса |
Порт |
|
Табл. комутації порта 1 К1 |
|
|
|
|
|
Табл. комутації порта 3 К1 |
||||
1583250 |
2 |
|
VCI-In |
VCI-Out |
Порт |
|
Табл. комутації порта 2 К1 |
|
VCI-In |
VCI-Out |
Порт |
||
1581130 |
3 |
|
3 |
2 |
2 |
|
VCI-In |
VCI-Out |
Порт |
|
10 |
4 |
1 |
… |
… |
|
4 |
10 |
3 |
|
2 |
3 |
1 |
|
9 |
8 |
4 |
Рисунок 15.1 – Комутація в мережах з віртуальними з'єднаннями
Нехай кінцевий вузол з адресою 1581120 починає установлювати віртуальне з'єднання з вузлом з адресою 1581130. Одночасно з адресою призначення в пакеті Call Request вказується і номер віртуального з'єднання VCI. Цей номер має локальне значення для порту комп'ютера, через який установлюється з'єднання. Через один порт можна встановити досить велику кількість віртуальних з'єднань, тому програмне забезпечення протоколу глобальної мережі в комп'ютері просто вибирає вільний у даний момент для даного порту номер. Якщо через порт уже прокладено 3 віртуальні з'єднання, то для нового з'єднання буде обраний номер 4, по якому завжди можна буде відрізнити пакети даного з'єднання від пакетів інших з'єднань, що приходять на цей порт.
Далі пакет типу Call Request з адресою призначення 1581130, номером VCI 4 і адресою джерела 1581120 відправляється в порт 1 комутатора К1 мережі. Адреса призначення використовується для маршрутизації пакета на основі таблиць маршрутизації, аналогічних таблицям маршрутизації протоколу IP, але з більш простою структурою кожного запису. Запис складається з адреси призначення і номера порту, на який потрібно переслати пакет. Адреса наступного комутатора не потрібна, тому що всі зв'язки між комутаторами є зв'язками типу «крапка-крапка», множинних з'єднань між портами немає. Стандарти глобальних мереж звичайно не описують який-небудь протокол обміну маршрутною інформацією, подібний RIP чи OSPF, що дозволяє комутаторам мережі автоматично будувати таблиці маршрутизації. Тому в таких мережах адміністратор звичайно вручну складає подібну таблицю, вказуючи для забезпечення відказостійкості основний і резервний шляхи для кожної адреси призначення. Виключенням є мережі АТМ, для яких розроблений протокол маршрутизації PNNI, заснований на алгоритмі стану зв'язків.
У приведеному прикладі відповідно до таблиці маршрутизації виявилося необхідним передати пакет Call Request з порту 1 на порт 3. Одночасно з передачею пакета маршрутизатор змінює номер віртуального з'єднання пакета – він привласнює пакету перший вільний номер віртуального каналу для вихідного порту даного комутатора. Кожен кінцевий вузол і кожен комутатор веде свій список зайнятих і вільних номерів віртуальних з'єднань для усіх своїх портів. Зміна номера віртуального каналу робиться для того, щоб при просуванні пакетів у зворотному напрямку (а віртуальні канали працюють у дуплексному режимі), можна було відрізнити пакети даного віртуального каналу від пакетів інших віртуальних каналів, уже прокладених через порт 3. У прикладі через порт 3 уже проходить кілька віртуальних каналів, причому самий старший зайнятий номер – це номер 9. Тому комутатор змінює номер віртуального каналу, що прокладається, з 4 на 10.
Крім таблиці маршрутизації для кожного порту складається таблиця комутації. У таблиці комутації вхідного порту 1 маршрутизатор відзначає, що в подальшому пакети, що прибули на цей порт із номером VCI рівним 4 повинні передаватися на порт 3, причому номер віртуального каналу повинен бути змінений на 10. Одночасно робиться і відповідний запис у таблиці комутації порту 3 – пакети, що прийшли по віртуальному каналі 10 у зворотному напрямку потрібно передавати на порт із номером 1, змінюючи номер віртуального каналу на 4. Таким чином, при одержанні пакетів у зворотному напрямку комп'ютер-відправник одержує пакети з тим же номером VCI, з яким він відправляв їх у мережу.
У результаті дії такої схеми пакети даних вже не несуть довгі адреси кінцевих вузлів, а мають у службовому полі тільки номер віртуального каналу, на підставі якого і виробляється маршрутизація всіх пакетів, крім пакета запиту на встановлення з'єднання. У мережі прокладається віртуальний канал, що не змінюється протягом усього часу існування з'єднання. Його номер міняється від комутатора до комутатора, але для кінцевих вузлів він залишається постійним.
За зменшення службового заголовку приходиться платити неможливістю балансу трафіку всередині віртуального з'єднання. При відмові якого-небудь каналу з'єднання приходиться також установлювати заново.
Власне кажучи, технологія віртуальних каналів дозволяє реалізувати два режими просування пакетів – стандартний режим маршрутизації пакета на підставі адреси призначення і режим комутації пакетів на підставі номера віртуального каналу. Ці режими застосовуються поетапно, причому перший етап складається в маршрутизації всього одного пакета – запиту на встановлення з'єднання.
Технологія віртуальних каналів має свої переваги і недоліки відносно технології IP- чи IPX-маршрутизації. Маршрутизація кожного пакета без попереднього встановлення з'єднання (ні IP, ні IPX не працюють із встановленням з'єднання) ефективна для короткочасних потоків даних. Крім того, можливо розпаралелювання трафіка для підвищення продуктивності мережі при наявності рівнобіжних шляхів у мережі. Швидше обробляється відмова маршрутизатора чи каналу зв'язку, тому що наступні пакети просто підуть по новому шляху (тут, щоправда, потрібно врахувати час встановлення нової конфігурації в таблицях маршрутизації). При використанні віртуальних каналів дуже ефективно передаються через мережу довгострокові потоки, але для короткочасних цей режим не дуже підходить, тому що на встановлення з'єднання звичайно іде багато часу – навіть комутатори технології АТМ, що працюють на дуже високих швидкостях, витрачають на встановлення з'єднання по 5-10 мс кожний. Через цю обставину компанія Ipsilon розробила кілька років назад технологію IP-switching, яка вводила в мережі АТМ, які працюють по описаному принципі віртуальних каналів, режим передачі ячейок без попереднього встановлення з'єднання. Ця технологія дійсно прискорювала передачу через мережу короткочасних потоків IP-пакетів, тому вона стала досить популярною, хоча і не придбала статус стандарту.
Алгоритми симетричного і асиметричного шифрування
Алгоритми з відкритим ключем (звані також асиметричними алгоритмами) розроблені таким чином, що ключ, використовуваний для зашифрування, відрізняється від ключа розшифрування. Більш того, ключ розшифрування не може бути (принаймні протягом розумного інтервалу часу) розрахований по ключу зашифрування. Такі алгоритми називають алгоритмами з відкритим ключем, тому що ключ зашифрування може бути відкритим: хто завгодно може використовувати цей ключ для зашифрування повідомлення, але розшифрувати повідомлення може тільки конкретна людина, яка знає ключем розшифрування. У таких системах ключ зашифрування часто називають відкритим ключем, а ключ розшифрування – закритим ключем. Закритий ключ іноді називають секретним ключем, але щоб не було плутанини з симетричними алгоритмами, цей термін використовується в даній роботі. Припустимо, що К1 – деякий відкритий ключ (для зашифрування), а К2 – відповідний закритий ключ (для розшифрування), тоді зашифрування з відкритим ключем К1 позначається як: Ек1(М)=С, а розшифрування з відповідним закритим ключем К2 позначаєтся як: Dк2(C)=M.
Схематично зашифрування та розшифрування при використанні асиметричних криптографічних алгоритмів зображені на рисунку 15.2.
Рисунок 15.2 – Операції зашифрування та розшифрування в асиметричних криптосистемах
Слід зауважити, що ключі К1 та К2 не обов’язково мають бути різними, але в тому випадку, коли вони співпадають, втрачається багато переваг алгоритма з відкритим ключем.
Іноді повідомлення зашифровуються закритим ключем, а розшифровуються – відкритим ключем. Такий метод використовують для цифрового підпису. Ці операції, відповідно, позначають як: Ек2(М)=С, Dк1(C)=M.
Від часу винайдення криптографії з відкритим ключем було запропоновано безліч криптографічних алгоритмів з відкритими ключами . Багато з них не є стійкими. А з тих, які є стійкими, багато непридатних для практичної реалізації . Або вони використовують дуже великий ключ, або розмір отриманого шифртексту набагато перевищує розмір відкритого тексту. Небагато алгоритмів є і безпечними, і практичними. Зазвичай ці алгоритми засновані на одній з важких проблем. Деякі з цих безпечних і практичних алгоритмів підходять тільки для розподілу ключів. Інші підходять для шифрування (і для розподілу ключів). Треті корисні тільки для цифрових підписів. Тільки три алгоритми добре працюють як при шифруванні, так і для цифрового підпису: RSA, EIGamal (Ель-Гамаля) та Rabin (Рабіна). Усі ці алгоритми повільні. Вони зашифровують і розшифровують дані набагато повільніше, ніж симетричні алгоритми. Зазвичай їх швидкість недостатня для шифрування великих обсягів даних.
Гібридні криптосистеми дозволяють прискорити події: для шифрування повідомлення використовується симетричний алгоритм з випадковим ключем, а алгоритм з відкритим ключем застосовується для шифрування випадкового сеансового ключа.
Симетричні алгоритми, які іноді називають умовними алгоритмами, це ті, в яких ключ зашифрування може бути розрахований з ключа розшифрування, і навпаки. У більшості симетричних алгоритмів ключі зашифрування і розшифрування ті самі . Ці алгоритми, також звані алгоритмами з секретним ключем або алгоритмами з єдиним ключем, вимагають, щоб відправник і одержувач погодили використовуваний ключ перед початком передачі секретних повідомлень. Захист, що забезпечується симетричним алгоритмом визначається ключем; розкриття ключа означає, що хто завгодно зможе зашифрувати і розшифрувати повідомлення. Поки повідомлення, що передаються, повинні залишатися таємними, ключ повинен зберігатися в секреті.
Якщо припустити, що К – ключ, що використовується у деякому симетричному криптографічному алгоритмі, тоді зашифрування і розшифрування з використанням симетричного алгоритму позначається як: Ек(М)=С, Dк(C)=M.
Схематично зашифрування та розшифрування при використанні симетричних криптографічних алгоритмів зображені на рисунку 15.3.
Рисунок 15.3 – Операції зашифрування та розшифрування в симетричних алгоритмах
Симетричні алгоритми поділяються на дві категорії. Одні алгоритми обробляють відкритий текст побітово (іноді побайтово), вони називаються потоковими алгоритмами або потоковими шифрами. Інші працюють з групами бітів відкритого тексту. Групи бітів називаються блоками, а алгоритми - блоковими алгоритмами або блоковими шифрами.
Стек протоколів IPSec
IPsec створено для безпечної взаємодії на основі криптографії для IPv4 та IPv6. Набір сервісів безпеки включає управління доступом, цілісність з'єднання, аутентифікацію вихідних даних, захист від replay-атак (цілісність послідовності), конфіденційність (шифрування) і конфіденційний потік трафіку. Ці сервіси надаються на рівні IP, забезпечуючи захист для IP і/або протоколів більш високого рівня.
IPsec підтримує дві форми цілісності: цілісність з'єднання і часткову цілісність послідовності. Цілісність з'єднання є сервісом безпеки, який визначає модифікацію конкретної IP датаграми, безвідносно послідовності датаграмм в потоці трафіку. Часткова цілісність послідовності є anti-reply сервісом, за допомогою якого визначається отримання дублікатів IP датаграм.
Ці сервіси реалізуються з використанням двох протоколів забезпечення безпечного трафіку, Authentication Header (AH) і Encapsulating Security Payload (ESP), і за допомогою процедур та протоколів управління криптографічним ключем. Безліч застосовуваних IPsec протоколів і метод їх використання визначаються вимогами безпеки.
Коли дані механізми встановлені коректно, вони не заважають користувачам, хостів і інших компонентів Інтернет, що не застосовують дані механізми безпеки для захисту свого трафіку. Ці механізми є алгоритмонезалежними. Це означає можливість вибору різного набору алгоритмів без впливу на інші частини реалізації. Наприклад, різні групи користувачів можуть вибрати при необхідності різні набори алгоритмів.
Визначено стандартний набір алгоритмів за замовчуванням для забезпечення інтероперабельності. Використання цих алгоритмів спільно із захистом трафіку на основі IPsec і протоколами управління ключа дозволяє забезпечити високу ступінь криптографічного безпеки.
Безпека, що забезпечується IPsec, залежить від багатьох факторів операційного оточення, в якому IPsec виконується. Наприклад, від безпеки ОС, джерела випадкових чисел, поганих протоколів управління системою і т.д.
Опишемо функціонування IPsec, компоненти системи і те, як вони взаємодіють один з одним для забезпечення сервісів безпеки.
IPsec виконується на хості або шлюзі безпеки, забезпечуючи захист IP-трафіку. Термін "шлюз безпеки" використовується для позначення проміжної системи, яка реалізує IPsec-протоколи. Захист заснована на вимогах, визначених у Базі Даних Політики Безпеки (Security Policy Database-SPD), обумовленою і підтримуваної системним адміністратором. Пакети обробляються одним з трьох способів на підставі відповідності інформації заголовка IP або транспортного рівня записам у SPD. Кожен пакет або відкидається сервісом безпеки IPsec, або пропускається без зміни, або обробляється сервісом IPsec на основі застосування певної політики.
IPsec забезпечує сервіси безпеки на IP-рівні, вибираючи потрібні протоколи безпеки, визначаючи алгоритми, використовувані сервісами, і надаючи всі криптографічні ключі потрібним сервісам. IPsec може використовуватися для захисту одного або кількох "шляхів" між парою хостів, між парою шлюзів безпеки або між шлюзом безпеки і хостом.
IPsec використовує два протоколи для забезпечення безпеки трафіку - Authentication Header (AH) і Encapsulating Security Payload (ESP).
Authentication Header (AH) забезпечує цілісність з'єднання, аутентифікацію вихідних даних і додатково може забезпечувати anti-replay сервіс.
Encapsulating Security Payload (ESP) протокол може забезпечувати конфіденційність (шифрування) трафіку. ESP також може забезпечувати цілісність з'єднання, аутентифікацію вихідних даних і додатково anti-replay сервіс. Цілісність забезпечується тільки для протоколів більш високого рівня. Хоча б один з цих сервісів має бути задіяний при використанні ESP.
Ці протоколи можуть застосовуватися як окремо так і в комбінації з один одним для забезпечення необхідного набору сервісів безпеки в IPv4 та IPv6. Кожен протокол підтримує два режими використання: режим транспорту і режим тунелювання. У транспортному режимі протоколи забезпечують захист головним чином для протоколів більш високого рівня; в режимі тунелювання протоколи застосовуються для приховування IP-заголовків вихідних пакетів. Різниця між двома режимами розглядається далі.
IPsec дозволяє системному адміністратору керувати деталізацією, з якою надається сервіс безпеки. Наприклад, можна створити єдиний зашифрований тунель між двома безпечними шлюзами, або для кожного ТСР з'єднання може бути створений зашифрований тунель між парою хостів. IPsec дозволяє вказувати наступні параметри:
Які сервіси використовуються і в якій комбінації.
Необхідний рівень деталізації застосовуваної захисту.
Алгоритми, що використовуються для забезпечення безпеки на основі криптографії.
Існує кілька способів реалізації IPsec на хості або в з'єднанні з маршрутизатором або firewall (для створення безпечного шлюзу). Наведемо кілька загальних прикладів:
Інтеграція IPsec в конкретну реалізацію IP. Це вимагає доступу до вихідного коду IP і застосування як до хостів, так і до шлюзів безпеки.
Bump-in-the-stack (BITS) реалізації, де IPsec реалізований "внизу" існуючої реалізації стека протоколів IP, між звичайним IP і локальними мережевими драйверами. Доступу до вихідного коду стека IP в даному контексті не потрібно, що робить такий підхід придатним для вбудовування в існуючі системи. Даний підхід зазвичай реалізується на хостах.
Використання зовнішнього кріптопроцессора (зазвичай у військових і в деяких комерційних системах). Як правило, це є Bump-in-the-stack (BITS) реалізацією. Такі реалізації можуть використовуватися як на хостах, так і на шлюзах. Зазвичай BITS-пристрої є IP-адресованими.
Протокол обміну ключами в Інтернет IKE
Протоколи ESP і АН дозволяють реалізувати найважливіші атрибути захищеної передачі – конфіденційність зв'язку, аутентифікацію сторін і цілісність даних. Проте їх функції втрачають будь-яку цінність під час відсутності могутньої підтримуючої інфраструктури, що забезпечувала б розподіл ключів і узгодження протоколів між учасниками обміну.
Роль такої інфраструктури в IPSec виконує група протоколів IKE (Internet Key Exchange). Це назва прийшла в 1998 р. на зміну більш ранньому – ISAKMP/Oakley, що безпосередньо вказувало на походження засобів керування ключами в складі IPSec.
Протокол ISAKMP {Internet Security Association and Key Management Protocol), описаний в документі RFC 2408, дозволяє погоджувати алгоритми та математичні структури (так звані мультиплікативні групи, визначені на кінцевому полі) для процедури обміну ключами Діффі - Хеллмана, а також процесів аутентифікації.
Протокол Oakley, описаний в RFC 2412, заснований на алгоритмі Діффі - Хеллмана і служить для організації безпосереднього обміну ключами.
Протоколи IKE вирішують три завдання:
здійснюють аутентифікацію взаємодіючих сторін, погоджують алгоритми шифрування і характеристики ключів, що будуть використовуватися в захищеному сеансі обміну інформацією;
забезпечують створення, управління ключової інформації сполуки, безпосередній обмін ключами (у тому числі можливість їхньої частої зміни);
управляють параметрами з'єднання і захистом від деяких типів атак, контролюють виконання всіх досягнутих угод.
Розробники IPSec почали свою діяльність з рішення останньої з перерахованих завдань. У результаті на світ з'явилася концепція захищених віртуальних з'єднань або безопасних асоціацій SA (Security Associations).
Встановлення безпечної асоціації SA
Основою функціонування IPSec є захищені віртуальні з'єднання або безпечні асоціації SA (Security Associations). Для того щоб протоколи АН і ESP могли виконувати свою роботу із захисту даних, що передаються, між двома кінцевими точками повинна бути сформована асоціація SA - угода про захист обміну даними між двома взаємодіючими партнерами.
Встановлення SA має починатися зі взаємної аутентифікації сторін, тому що заходи безпеки втрачають всякий сенс, якщо дані передаються або приймаються неавторизованими користувачами. Процедури встановлення SA виправдані лише в тому випадку, якщо у кожної зі сторін є повна впевненість в тому, що її партнер - саме той, за кого він себе видає.
Для виконання аутентифікації сторін у IKE застосовуються два основних способи.
Перший спосіб заснований на використанні розділяється секрету. Перед ініціалізацією IPSec-пристроїв, що утворюють безпечні асоціації, в їх БД поміщається попередньо розподілений розділяється секрет. Цифровий підпис на основі односторонньої функції, наприклад, MD5, що використовує в якості аргументу цей попередньо розподілений секрет, доводить автентичність протилежної сторони.
Другий спосіб заснований на використанні технології цифрового підпису та цифрових сертифікатів стандарту Х.509. Кожна зі сторін підписує свій цифровий сертифікат своїм закритим ключем і передає ці дані протилежній стороні. Якщо підписаний сертифікат розшифровується відкритим ключем відправника, то це засвідчує той факт, що відправник, який надав дані, дійсно володіє відповідною частиною даного відкритого ключа - відповідним закритим ключем.
Однак слід зазначити, що для посвідчення автентичності боку потрібно ще переконатися в автентичності самого сертифіката, і для цього сертифікат повинен бути підписаний не тільки його власником, а й деякою третьою стороною, що видала сертифікат і викликає довіру. В архітектурі IPSec ця третя сторона іменується органом сертифікації СА (Certification Authority). Цей орган покликаний засвідчити справжність обох сторін і повинен користуватися повною довірою сторін, а його відкритий ключ - відомий всім вузлам, що використовують його сертифікати для посвідчення особистостей один одного.
Після проведення взаємної аутентифікації взаємодіючі сторони можуть безпосередньо перейти до узгодження параметрів захищеного каналу. Обираєте параметри SA визначають: протокол, використовуваний для забезпечення безпеки передачі даних; алгоритм аутентифікації протоколу АН і його ключі; алгоритм шифрування, використовуваний протоколом ESP, і його ключі; наявність або відсутність криптографічної синхронізації; способи захисту сеансу обміну; частоту зміни ключів і ряд інших параметрів . Важливим параметром SA є так званий криптографічний матеріал, тобто секретні ключі, що використовуються в роботі протоколів АН і ESP. Сервіси безпеки, пропоновані IPSec, використовують для формування криптографічних ключів колективні секрети.
Параметри SA повинні влаштовувати обидві кінцеві точки захищеного каналу. Тому при використанні автоматичної процедури встановлення SA протоколи IKE, що працюють по різні сторони каналу, вибирають параметри в ході переговорного процесу. Для кожного завдання, розв'язуваної протоколами АН і ESP, пропонується кілька схем аутентифікації і шифрування - це робить IPSec дуже гнучким засобом. Безпечна асоціація SA являє собою в IPSec односпрямоване логічне з'єднання, тому при двосторонньому обміні даними необхідно встановити дві асоціації SA. У рамках однієї асоціації SA може працювати тільки один з протоколів захисту даних - або АН, або ESP, але не обидва разом.
Для ідентифікації кожної SA призначено індекс параметрів безпеки SPI (Security Parameters Index). Цей індекс включається в заголовки захищених IPSec-пакетів, щоб приймаюча сторона змогла правильно їх розшифрувати і аутентифікувати, скориставшись зазначеної безпечної асоціацією.
Система IPSec допускає застосування ручного та автоматичного способу встановлення SA. При ручному способі адміністратор конфігурує кожен кінцевий вузол таким чином, щоб вони підтримували узгоджені параметри асоціації, включно і таємні ключі.
Для автоматичного встановлення асоціації необхідний відповідний протокол, в якості якого в стандартах IPSec визначений протокол IKE. Він є комбінацією протоколів ISAKMP, Oakley і SKEME. Протокол узгодження параметрів віртуального каналу та управління ключами ISAKMP (Internet Security Association Key Management Protocol) описує базову технологію аутентифікації, обміну ключами та узгодження решти параметрів IPSec-тунеля при створенні SA, проте самі протоколи аутентифікації сторін та обміну ключами в ньому детально не визначені. Тому при розробці протоколу IKE загальні правила і процедури протоколу ISAKMP доповнені процедурами аутентифікації і обміну ключами, взятими з протоколів Oakley і SKEME. Оскільки протокол IKE використовує для управління асоціаціями алгоритми та формати протоколу ISAKMP, назви цих протоколів іноді використовують як синоніми.
На підставі протоколу ISAKMP узгодження параметрів захищеного взаємодії необхідно як при формуванні IPSec-тунеля, так і при формуванні в його рамках кожного захищеного односпрямованого з'єднання. Параметри IPSec-тунеля узгоджуються по протоколу ISAKMP/Oakley. Параметри кожного захищеного односпрямованого з'єднання узгоджуються в рамках сформованого IPSec-тунеля і утворюють SA.
Криптографічні ключі для кожного захищеного односпрямованого з'єднання генеруються на основі ключів, вироблених в рамках IPSec-тунеля. При цьому враховуються алгоритми аутентифікації і шифрування, які використовуються в протоколах аутентифікуючий заголовка (АН) і Інкапсулює захисту (ESP).
Стандарти IPSec дозволяють шлюзам використовувати як одну асоціацію SA для передачі трафіку всіх взаємодіючих через Інтернет хостів, так і створювати для цієї мети довільне число асоціацій SA, наприклад по одній на кожне з'єднання TCP.
Бази даних SAD і SPD
IPSec пропонує різні методи захисту трафіку. У кожному вузлі, що підтримує IPSec, використовуються БД двох типів:
база даних безпечних асоціацій SAD (Security Associations Database);
база даних політики безпеки SPD (Security Policy Database).
При встановленні SA дві вступають в обмін сторони беруть ряд угод, що регламентують процес передачі потоку даних між ними. Угоди представляються у вигляді набору параметрів. Для SA такими параметрами є, зокрема, тип і режим роботи протоколу захисту (АН або ESP), методи шифрування, секретні ключі, значення поточного номера пакета в асоціації та інша інформація.
Об'єднання службової інформації в рамках SA надає користувачеві можливість сформувати різні класи захисту, призначені, наприклад, для електронного спілкування з різними «співрозмовниками». Іншими словами, застосування структур SA відкриває шлях до побудови безлічі віртуальних приватних мереж, що розрізняються своїми параметрами.
Набори поточних параметрів, що визначають всі активні асоціації, зберігаються на обох кінцевих вузлах захищеного каналу у вигляді SAD. Кожен вузол IPSec підтримує дві бази SAD - одну для вихідних асоціацій, іншу - для вхідних.
SPD задає відповідність між IP-пакетами і встановленими для них правилами обробки. При обробці пакетів БД SPD використовуються спільно з БД SAD. SPD являє собою упорядкований набір правил, кожне з яких включає сукупність селектор і допустимих політик безпеки. Селектори служать для відбору пакетів, а політики безпеки задають необхідну обробку. Така БД формується і підтримується на кожному вузлі, де встановлене ПЗ IPSec.
Алгоритми встановлення і розривання IPSec з’єднання
Алгоритм роботи стеку IPSec складається з трьох основних кроків (див. рисунок 15.4).
Рисунок 15.4 – Алгоритм роботи IPSec
Узгодження політики побудови каналу.
Обмін ключами за допомогою протоколу IKE.
Обмін зашифрованими даними по загальній мережі.
Розрив з’єднання виконується при не отриманні відповіді від одної з сторін, або при передачі необхідної команди розриву з’єднання.
Основи налаштування VPN на прикладі ПЗ OpenVPN
Розглянемо реальний приклад налаштування системи OpenVPN.
Постановка завдання
Необхідно створити віртуальну приватну мережу між декількома офісами компанії, підключеними до Інтернет.
Вихідні дані
Мається сервер з FreeBSD, через який підмережа центрального офісу підключена до Інтернет (див. рисунок 15.5). На ньому буде розгорнуто сервер OpenVPN. Є два віддалених філії, підмережі яких також підключені до Інтернет через сервери з FreeBSD (вони будуть клієнтами OpenVPN) і комп'ютер системного адміністратора з Windows XP (він також буде клієнтом OpenVPN). Локальна підмережа центрального офісу має адресу 192.168.0.0/24; локальна підмережа філії № 1 - 192.168.1.0/24; локальна підмережа філії № 2 - 192.168.2.0/24. Необхідно створити віртуальну приватну мережу routed-типу (тобто не пропускає широкомовний трафік), з топологією Point-To-Multi-Point (один сервер і декілька клієнтів), що використовує для шифрування трафіку TLS/SSL і забезпечує наступну політику маршрутизації:
з локальної підмережі центрального офісу доступні комп'ютери локальних підмереж обох філій;
з локальних підмереж філій доступні комп'ютери локальної підмережі центрального офісу;
c комп'ютера системного адміністратора доступні комп'ютери всіх локальних підмереж.
Рисунок 15.5 – Функціональна схема мережі
Установка сервера OpenVPN
Перед установкою сервера OpenVPN необхідно додати у файл конфігурації ядра рядок pseudo-device tun, якщо така відсутня, перезібрати ядро і перезавантажити систему. Потім потрібно встановити OpenVPN з портів:
# cd /usr/ports/security/openvpn
# make install
Файли конфігурація сервера OpenVPN зберігаються в папці /usr/local/etc/openvpn. Для створення цієї папки, а також усіх необхідних вкладених папок і файлів необхідно виконати наступну послідовність команд:
# mkdir /usr/local/etc/openvpn
# cd /usr/local/etc/openvpn
# mkdir ccd
# mkdir certs
# mkdir crl
# mkdir keys
# mkdir private
# mkdir req
#chmod 700 keys private
#echo "01" > serial
#touch index.txt
Зазначені команди створюють папку /usr/local/etc/openvpn; вкладені в неї папки: ccd (конфігурації віддалених клієнтів), certs (сертифікати клієнтів і сервера), crl (списки відкликання сертифікатів), keys (закриті ключі сертифікатів клієнтів і сервера), private (закритий ключ самоподпісного довіреної сертифікату (CA), req (запити на сертифікати); обмежують права доступу до папок keys і private; створюють базу даних сертифікатів (файли serial і index.txt).
Файл конфігурації OpenSSL
Типово OpenSSL використовує файл конфігурації /etc/ssl/openssl.cnf. Я рекомендую створити окремий файл конфігурації OpenSSL в папці /usr/local/etc/openvpn. Цей файл повинен називатися openssl.cnf і мати наступне вміст:
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /usr/local/etc/openvpn
crl_dir = $dir/crl
database = $dir/index.txt
new_certs_dir = $dir/certs
certificate = $dir/CA_cert.pem
serial = $dir/serial
crl = $dir/crl/crl.pem
private_key = $dir/private/CA_key.pem
RANDFILE = $dir/private/.rand
default_days = 3650
default_crl_days = 365
default_md = md5
unique_subject = yes
policy = policy_any
x509_extensions = user_extensions
[ policy_any ]
organizationName = match
organizationalUnitName = optional
commonName = supplied
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
x509_extensions = CA_extensions
[ req_distinguished_name ]
organizationName = Organization Name (must match CA)
organizationName_default = Company
organizationalUnitName = Location Name
commonName = Common User or Org Name
commonName_max = 64
[ user_extensions ]
basicConstraints = CA:FALSE
[ CA_extensions ]
basicConstraints = CA:TRUE
default_days = 3650
[ server ]
basicConstraints = CA:FALSE
nsCertType = server
Створення самоподпісного довіреної сертифікату (CA)
Для створення самоподпісного довіреної сертифікату (Certification Authority, CA) та закритого ключа для нього необхідно виконати наступну команду, перебуваючи в папці /usr/local/etc/openvpn:
openssl req -new -nodes -x509 -keyout private/CA_key.pem -out CA_cert.pem -days 3650
Команда req змушує OpenSSL створити сертифікат, ключі: -new - створена запит на сертифікат, -nodes - не шифрувати закритий ключ, -x509 (спільно з -new) - створити самопідписний сертифікат (CA), -keyout - задає місцезнаходження закритого ключа, -out - задає місцезнаходження самоподпісного сертифіката, -days - задає час дії сертифіката (365x10 днів, що приблизно дорівнює десяти рокам). У процесі виконання команди на екран будуть видані запити про введення таких параметрів як: Country Name, State or Province Name; Locality Name; Organization Name; Organizational Unit Name; Common Name; Email Address. Найважливішим параметром є значення Common Name. У даному випадку воно має збігатися з FQDN-іменем сервера. Для перегляду результату генерації самоподпісного сертифіката та закритого ключа необхідно виконати наступну команду, перебуваючи в папці /usr/local/etc/openvpn:
openssl x509 -noout -text -in CA_cert.pem (для сертифікату)
openssl rsa -noout -text -in private/CA_key.pem (для замкненого ключа)
Створення сертифіката сервера
Перед створенням сертифіката сервера необхідно створити запит на сертифікат сервера і закритий ключ сервера. Для цього необхідно виконати наступну команду, перебуваючи в папці /usr/local/etc/openvpn:
openssl req -new -nodes -keyout keys/server.pem -out req/server.pem
Команда і ключі OpenSSL розглянуті вище. У процесі виконання команди Вам знову доведеться відповісти на запитання. Відповіді повинні відповідати відповідям з попереднього пункту. У відповідь на додаткові запити "A challenge password []:" і "An optional company name []:" необхідно просто натиснути <Enter>. Для перегляду результату генерації запиту на сертифікат та закритого ключа сервера необхідно виконати наступну команду, перебуваючи в папці /usr/local/etc/openvpn:
openssl req -noout -text -in req/server.pem (для запиту на сертифікат)
openssl rsa -noout -text -in keys/server.pem (для замкненого ключа)
Для створення сертифіката сервера необхідно підписати запит на сертифікат сервера самопідписним довіреною сертифікатом (CA). Для цього необхідно виконати наступну команду, перебуваючи в папці /usr/local/etc/openvpn:
openssl ca -batch -config openssl.cnf -extensions server -out certs/server.pem -infiles req/server.pem
Команда ca змушує OpenSSL підписати запит на сертифікат, ключі:-config задає місцезнаходження файлу конфігурації OpenSSL, -extensions - задає секцію файлу конфігурації OpenSSL, що містить додаткові параметри генерується сертифіката, -out - задає місцезнаходження генерованого сертифіката, -infiles - задає місцезнаходження запиту на сертифікат, -batch - позбавляє Вас від відповідей на додаткові запитання. У процесі виконання команди Вам буде поставлено питання "Sign the certificate? [Y/n]:", на який потрібно відповісти ствердно, після чого відбудеться генерація сертифікату та оновлення бази даних сертифікатів (файлів index.txt і serial). Для перегляду результату генерації сертифіката необхідно виконати наступну команду, перебуваючи в папці /usr/local/etc/openvpn:
openssl x509 -noout -text -in certs/server.pem
Створення файлу параметрів Діффі-Хелмана
Для створення файлу параметрів Діффі-Хелмана, призначеного для забезпечення більш надійного захисту даних при установці з'єднання клієнта з сервером, необхідно виконати наступну команду, перебуваючи в папці /usr/local/etc/openvpn:
openssl dhparam -out dh2048.pem 2048
Команда dhparam наказує OpenSSL створити файл параметрів Діффі-Хелмана, число 2048 визначає розрядність в бітах. Увага: ця команда виконується досить повільно навіть на дуже потужних комп'ютерах.
Створення клієнтських сертифікатів
Процедура створення клієнтських запитів на сертифікати і закритих ключів, підписання запитів на сертифікати і генерації сертифікатів, а також перегляду запитів на сертифікати, сертифікатів і закритих ключів повністю аналогічна відповідній процедурі для сервера. Зроблю одне невелике зауваження: запити на сертифікати, закриті ключі та сертифікати повинні мати шаблонні імена, наприклад, види: req/RClient для запитів на сертифікати, keys/KClient для закритих ключів і certs/CClient для сертифікатів, відповідно. Слово Client має бути замінене ім'ям клієнта, яке обов'язково має відповідати значенню параметра Common Name, що вводиться при генерації запиту на сертифікат для відповідного клієнта. Можливість дублювання Common Name у декількох клієнтів визначається конфігурацією сервера. Для генерації запиту на сертифікат та закритого ключа, а також підписання запиту на сертифікат і генерації сертифіката для клієнта Client необхідно виконати наступні команди, перебуваючи в папці /usr/local/etc/openvpn:
openssl req -new -nodes -keyout keys/KClient.pem -out req/RClient.pem
openssl ca -batch -config openssl.cnf -out certs/CClient.pem -infiles req/RClient.pem
Для перегляду згенерованих запиту на сертифікат, закритого ключа і сертифіката клієнта Client необхідно виконати наступні команди, перебуваючи в папці /usr/local/etc/openvpn:
openssl req -noout -text -in req/RClient.pem (для запиту на сертифікат)
openssl rsa -noout -text -in keys/KClient.pem (для замкненого ключа)
openssl x509 -noout -text -in certs/CClient.pem (для сертифікату)
На даному етапі для розглянутого випадку необхідно створити три групи, що складаються із запиту на сертифікат/закритого ключа/сертифікату, з іменами Rclient1/Kclient1/Cclient1, Rclient2/Kclient2/Cclient2 і Rclient3/Kclient3/Cclient3 для філії № 1 (Common Name - client1 ), для філії № 2 (Common Name - client2) і для системного адміністратора (Common Name - client3), відповідно.
Створення списку відкликання сертифікатів
Для створення списку відкликання сертифікатів необхідно виконати наступну команду, перебуваючи в папці /usr/local/etc/openvpn:
openssl ca -config openssl.cnf -gencrl -out crl/crl.pem
Команда ca з ключем-gencrl змушує OpenSSL створити список відкликання сертифікатів, ключі: -config розглянуто вище, -out - задає місцезнаходження списку відкликання сертифікатів. Дана команда створює порожній список відкликання сертифікатів. Для того, щоб відкликати сертифікат клієнта Client необхідно виконати наступну команду, перебуваючи в папці /usr/local/etc/openvpn:
openssl ca -config openssl.cnf -revoke certs/CClient.pem
Команда ca з ключем-revoke змушує OpenSSL відкликати заданий сертифікат, ключ-config розглянуто вище. Щоб переглянути список відкликаних сертифікатів необхідно виконати наступну команду, перебуваючи в папці /usr/local/etc/openvpn:
openssl crl -noout -text -in crl/crl.pem
Створення статичної ключа HMAC
Для створення статичного ключа HMAC, що забезпечує додатковий захист від DoS-атак і флудинг UDP-портів, необхідно виконати наступну команду, перебуваючи в папці /usr/local/etc/openvpn:
openvpn --genkey --secret ta.key
Файл конфігурації сервера
Типово конфігурація сервера OpenVPN зберігається у файлі openvpn.conf, який повинен знаходиться в папці /usr/local/etc/openvpn. У розглянутому випадку файл конфігурації має наступний вигляд:
dev tun
local <Зовнішня IP-адреса сервера>
port 1194
proto udp
server 10.0.0.0 255.255.255.0
push "route 10.0.0.0 255.255.255.0"
route 192.168.1.0 255.255.255.0
route 192.168.2.0 255.255.255.0
client-config-dir ccd
client-to-client
tls-server
dh /usr/local/etc/openvpn/dh2048.pem
ca /usr/local/etc/openvpn/CA_cert.pem
cert /usr/local/etc/openvpn/certs/server.pem
key /usr/local/etc/openvpn/keys/server.pem
crl-verify /usr/local/etc/openvpn/crl/crl.pem
tls-auth /usr/local/etc/openvpn/ta.key 0
comp-lzo
keepalive 10 120
tun-mtu 1500
mssfix 1450
persist-key
persist-tun
user openvpn
group openvpn
verb 3
У даному файлі задані такі значення параметрів сервера OpenVPN: dev - інтерфейс OpenVPN, local і port - IP-адреса і порт, на яких OpenVPN приймає вхідні з'єднання, proto - протокол (в даному випадку UDP), server - пул IP-адрес, виділений для віртуальної приватної мережі і автоматично розподіляється між клієнтами, push - команда OpenVPN, передана клієнту і виконувана клієнтом (у даному випадку "route 10.0.0.0 255.255.255.0" додає на стороні клієнта маршрут до віртуальної приватної мережі), route - додає на стороні сервера маршрути до локальних підмереж, які перебувають за клієнтами, client-config-dir - папка з файлами конфігурації клієнтів, client-to-client - дозвіл клієнтам "бачити" один одного (природно, при наявності відповідних правил маршрутизації), tls-server - включення підтримки TLS; dh - місцезнаходження файлу параметрів Діффі-Хелмана, ca - місцезнаходження самоподпісного довіреної сертифікату (CA), cert - місцезнаходження сертифіката сервера, key - місцезнаходження закритого ключа сервера, crl-verify - місцезнаходження списку відкликання сертифікатів, tls-auth - місцезнаходження статичного ключа HMAC, comp-lzo - використання LZO-компресії трафіку, keeplive - підтримка з'єднання (в даному випадку відправка пінгів кожні 10 секунд, і закриття з'єднання через дві хвилини після відсутності відповідних пакетів, як сервером, так і клієнтами), tun-mtu і mssfix - параметри передачі даних по тунелю, persist-tun - не закривати/відкривати по-новій tun-пристрій при отриманні сигналу SIGUSR1 (перезапуск без привілеїв root) або при виконанні ping-restarts, user і group - користувач і група, від імені яких працює OpenVPN після запуску (запуск виконується під root'ом), verb - рівень деталізації повідомлень, видаваних OpenVPN в /var/log/messages.
Файли конфігурації клієнтів
Файли конфігурації клієнтів є текстовими файлами і містять команди, які виконуються сервером при підключенні клієнтів. Імена файлів конфігурації клієнтів повинні відповідати Common Name клієнтів, тобто при підключенні клієнта з Common Name client1 сервер виконає команди, задані у файлі client1 і т.д. Файли конфігурації клієнтів повинні знаходитися в папці /usr/local/etc/openvpn/ccd. Для розглянутого випадку необхідно створити три файли конфігурації клієнтів client1-client3:
# cd /usr/local/etc/openvpn/ccd
# touch client1 client2 client3
Файл client1 повинен містити дві команди: додаючи клієнту маршрут до локальної підмережі центрального офісу, а також визначальну адресу локальної підмережі, що знаходиться за клієнтом:
push "route 192.168.0.0 255.255.255.0"
iroute 192.168.1.0 255.255.255.0
Файл client2 аналогічний файлу client1 за винятком адреси локальної підмережі, що знаходиться за клієнтом:
push "route 192.168.0.0 255.255.255.0"
iroute 192.168.2.0 255.255.255.0
Файл client3 повинен містити команди, що додають клієнту маршрути до локальних підмереж центрального офісу і обох філій:
push "route 192.168.0.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.2.0 255.255.255.0"
Існують і інші способи завдання маршрутів, а також інші команди, які можуть бути присутніми у файлах конфігурації клієнтів. На цей рахунок найкраще уважно вивчити OpenVPN Man Page і HOWTO.
Написано пізніше: у зв'язку з часто повторюваними питаннями додав замітку Призначення статичних IP-адрес клієнтам OpenVPN.
Автоматичний запуск сервера
Для автоматичного запуску сервера OpenVPN при завантаженні операційної системи необхідно додати рядок openvpn_enable="YES" у файл /etc/rc.conf.
Зауваження по налаштуванню брандмауерів
Для коректної роботи сервера OpenVPN необхідно внести такі зміни в налаштування брандмауера:
Дозволити проходження будь-якого трафіку через інтерфейс OpenVPN;
Дозволити проходження UDP-трафіку на зовнішній адресу сервера порт 1194;
Дозволити проходження будь-якого трафіку з віртуальної приватної мережі в локальну підмережа;
Дозволити проходження будь-якого трафіку з локальної підмережі у віртуальну приватну мережу;
Дозволити проходження будь-якого трафіку з локальної підмережі філії № 1 в локальну підмережа;
Дозволити проходження будь-якого трафіку з локальної підмережі в локальну підмережа філії № 1;
Дозволити проходження будь-якого трафіку з локальної підмережі філії № 2 в локальну підмережа;
Дозволити проходження будь-якого трафіку з локальної підмережі в локальну підмережа філії № 2.
Для ipfw потрібно додати наступні правила:
/sbin/ipfw -q add pass ip from any to any via ${vif}
/sbin/ipfw -q add pass udp from any to ${oip} 1194 in via ${oif}
/sbin/ipfw -q add pass ip from ${vnet} to ${inet} out via ${iif}
/sbin/ipfw -q add pass ip from ${inet} to ${vnet} in via ${iif}
/sbin/ipfw -q add pass ip from 192.168.1.0/24 to ${inet} out via ${iif}
/sbin/ipfw -q add pass ip from ${inet} to 192.168.1.0/24 in via ${iif}
/sbin/ipfw -q add pass ip from 192.168.2.0/24 to ${inet} out via ${iif}
/sbin/ipfw -q add pass ip from ${inet} to 192.168.2.0/24 in via ${iif}
Змінні shell мають такі значення: oip - зовнішній IP-адресу сервера, inet - адреса локальної підмережі (у нашому випадку - 192.168.0.0/24), vnet - адреса віртуальної приватної мережі (в нашому випадку 10.0.0.0/24), iif - ім'я внутрішнього інтерфейсу сервера (наприклад, rl1), oif - ім'я зовнішнього інтерфейсу сервера (наприклад, rl0), vif - ім'я інтерфейсу OpenVPN (наприклад, tun0).
Налаштування брандмауерів клієнтів виконується аналогічно. Правила, починаючи з п'ятого, залежать від реалізованої політики маршрутизації. Для нашого випадку правила ipfw для клієнта client1 будуть мати вигляд (не забудьте, що тепер мінлива shell inet визначає адресу локальної підмережі клієнта client1 - 192.168.1.0/24):
/sbin/ipfw -q add pass ip from any to any via ${vif}
/sbin/ipfw -q add pass udp from any to ${oip} 1194 in via ${oif}
/sbin/ipfw -q add pass ip from ${vnet} to ${inet} out via ${iif}
/sbin/ipfw -q add pass ip from ${inet} to ${vnet} in via ${iif}
/sbin/ipfw -q add pass ip from 192.168.0.0/24 to ${inet} out via ${iif}
/sbin/ipfw -q add pass ip from ${inet} to 192.168.0.0/24 in via ${iif}
Правила ipfw для клієнта client2 не відрізняються від правил для клієнта client1 (не забудьте, що тепер мінлива shell inet визначає адресу локальної підмережі клієнта client2 - 192.168.2.0/24).
Передача ключових файлів клієнту
Для передачі файлів клієнту краще використовувати який-небудь твердий носій, наприклад дискету, але ні в якому разі не мережу Інтернет. Щоб скопіювати файли, необхідні клієнту Client, на дискету, потрібно виконати наступну послідовність команд:
# mount -t msdos /dev/fd0 /mnt
# cd /usr/local/etc/openvpn
# cp certs/CClient.pem /mnt
# cp keys/KClient.pem /mnt
# cp CA_cert.pem /mnt
# cp ta.key /mnt
# umount /mnt
Дані команди монтують дискету до папки /mnt, копіюють сертифікат клієнта, закритий ключ клієнта, самопідписний довірений сертифікат (CA) і статичний ключ HMAC на дискету, а потім розмонтуйте її.
Клієнтське програмне забезпечення
Якщо клієнт працює під FreeBSD, то установка клієнта OpenVPN нічим не відрізняється від установки сервера (використовується той же самий порт), якщо під Windows, є два варіанти - OpenVPN і OpenVPN GUI. Перший варіант більше підходить для постійно включених серверів (OpenVPN може бути встановлена як служба Windows), другий - для мобільних клієнтів, періодично підключаються до корпоративної мережі. Наприклад, я використовую на домашньому ноутбуці OpenVPN GUI, коли мені потрібно підключитися до корпоративної мережі. У всіх перерахованих випадках файли конфігурації мають один і той же формат. Увага: у разі використання Windows-клієнтів не забувайте використовувати у файлах конфігурації подвійні бекслеші замість одинарних Слеш, що використовуються в файлах конфігурації Unix-клієнтів.
Файл конфігурації клієнтського програмного забезпечення
Конфігурація клієнта OpenVPN зберігається у файлі openvpn.conf, який повинен знаходиться в папці /usr/local/etc/openvpn, якщо ми маємо справу з FreeBSD-клієнтом, або у файлі з довільним ім'ям і розширенням. Ovpn, який повинен знаходитися в папці C:\Program Files\OpenVPN\config, якщо при установці OpenVPN (OpenVPN GUI) не було наведено шлях, відмінний від пропонованого за замовчуванням. Розглянемо файл конфігурації клієнта client3, встановленого на ноутбук з Windows XP. Клієнт OpenVPN GUI встановлений в каталог за замовчуванням, а ключові файли, які раніше були переписані на дискету, збережені на диску P: в папці OpenVPN (я віддаю перевагу шифрувати цей диск). Для розглянутого випадку файл конфігурація клієнта OpenVPN має наступний вигляд:
client
dev tun
proto udp
remote <IP-адреса сервера OpenVPN>
tls-client
tls-remote <FQDN сервера OpenVPN>
ca "P:\\OpenVPN\\CA_cert.pem"
cert "P:\\OpenVPN\\Ссlient3.pem"
key "P:\\OpenVPN\\Kсlient3.pem"
tls-auth "P:\\OpenVPN\\ta.key" 1
ns-cert-type server
comp-lzo
tun-mtu 1500
mssfix 1450
verb 3
У даному файлі задані такі значення параметрів клієнта OpenVPN: client - спрощений варіант вказівки того, що це файл конфігурації клієнта, dev - пристрій OpenVPN, proto - протокол (в даному випадку UDP), remote - IP-адреса сервера OpenVPN, tls-client - включення підтримки TLS, tls-remote - Common Name сервера OpenVPN, ca - місцезнаходження самоподпісного довіреної сертифікату (CA), cert - місцезнаходження сертифіката клієнта, key - місцезнаходження закритого ключа клієнта, tls-auth - місцезнаходження статичного ключа HMAC, comp-lzo, tun -mtu, mssfix і verb розглянуті вище. Повторюю, файли конфігурації FreeBSD-клієнтів відрізняються тільки форматом завдання шляхів до файлів.