Програмне забезпечення
Віддалений доступ через VPN
Доступ віддалених користувачів через IPsec
Налаштування шлюзу VPN
VPN клієнти
Програмне забезпечення
користувача оточення
Віддалений доступ через VPN
З урахуванням швидкого розвитку DSL-підключень, значення модемного з'єднання зменшується, але потреба в захищених з'єднаннях залишається. Тут нам на допомогу приходить VPN.
У цій статті ми розглянемо доступ тільки через логін / пароль.
міркування безпеки
Для створення VPN з'єднання користувачеві і сервера необхідно підтвердити свою автентичність, щоб виключити атаку типу "людина-в-середині".
Наше завдання - забезпечити достовірність VPN-шлюзу. У разі зумовленого ключа, його компрометація дозволить зловмисникові імітувати шлюз, що призведе до плачевних наслідків. Для перевірки шлюзу ми будемо використовувати сертифікати x509. При цьому. ми не будемо встановлювати сертифікати на стороні клієнта.
можливі рішення
Доступ віддалених користувачів через IPsec
1 фаза аутентифікації IPsec
Першою фазою IPSec є IPsec Key Exchange (IKE) (обмін ключами) і виконується демоном IKE, в NetBSD більше відомим як racoon (8). Ця фаза призначена для підтвердження автентичності віддалених кінців з'єднання і установки ключів, що використовуються в другій фазі. Друга фаза застосовується при зміні ключів, якими шифрується трафік, і може відбуватися кілька разів за сесію. Перша фаза може бути організована двома способами - зумовленими (pre-shared) ключами і сертифікатами. Це не зовсім нас влаштовує з наступних причин:- Зумовлені ключі не прив'язані до логіну та у нас немає інструментів для управління ними. Єдине, чим ми можемо управляти - це пароль групи.
- Перша фаза є симетричною, що подразуменвает наявність однакових ключів або сертифікатів на обох сторонах підключення. Це не наш метод.
Xauth є розширенням IKE і додає аутентифікацію за логіном / паролем після першої фази. Така можливість знімає половину наших проблем. Так як аутентифікація відбувається після першої фази, то передані дані вже зашифровані. Необхідність в загальному ключі або сертифікаті як і раніше існує, але ключі небезпечні, а сертифікат спричинить проблеми з користувачами, чого нам абсолютно не треба.
Hybrid auth
Рівень захисту IPsec + Xauth + Hybrid auth відповідає використанню SSH з аутентифікацією по паролю.
ISAKMP mode config
NAT Traversal
Так як віддалений користувач може бути прихований за Network Address Translator (NAT), постає проблема застосування IPsec. При шифрування трафіку IPsec використовує протокол 4 рівня, відомий як Encapsulated Security Payload (ESP). На відміну від TCP або UDP, ESP не має номера порту і не може коректно проходити через NAT.
В RFC 3947 і 3948 описується метод інкапсуляції ESP в UDP і розширення IKE для управління NAT між кінцевими точками IPSec. Інкапсуляція і розширення більше відомі як NAT Traversal (NAT-T).
Фрагментація IKE і ESP
Більшість вилучених користувачів, в кінцевому підсумку, буде з'єднуватися через xDSL-модеми. Такі модеми досить часто обривають зв'язок під великим навантаженням UDP-пакетами, так як виробники чомусь вважають, що UDP використовується тільки для DNS-запитів і відкидають великі або фрагментовані запити. А як ми пам'ятаємо, ESP поверх UDP якраз і використовує великі UDP пакети. Для вирішення цієї проблеми, ми будемо використовувати IKE фрагментацію, ще одне розширення IKE, що дозволяє фрагментувати великі пакети. Проблема великих пакетів вирішується шляхом фрагментації IP перед инкапсуляцией в ESP, тобто замість frag (IP / UDP / ESP / IP) виходить IP / UDP / ESP / frag (IP), тому пристрої між кінцевими точками НЕ фідят ніяких фрагментованих пакетів.
Dead Peer Detection
Остання проблема: віддалене з'єднання може бути не постійним, час від часу перериваючись. Вбудований механізм IPsec повинен викликати час від часу другу фазу IKE для повторної передачі ключів і при невдалій спробі обривати сесію. Цей механізм не дуже зручний. Для регулярної перевірки з'єднання використовується розширення IKE, зване Dead Peer Detection (DPD). DPD здатне перевіряти доступність крайніх точок з кратністю в кілька секунд.
Налаштування шлюзу VPN
конфігурація ядра
маршрутизація пакетів
Необхідно дозволити перенаправлення пакетів IPv4:створення сертифікатів
Конфігурація racoon (8)
Ось приклад файлу конфігурації /etc/racoon/racoon.conf:проблеми фрагментації
Використовуючи фрагментацію ESP можна обмінюватися через тунель IP пакетами будь-якого розміру. Але, є специфіка при роботі з TCP, так як можуть з'явитися проблеми з Path Maximum Transmission Unit (PMTU). Рішення полягає в фіксації Maximum Segment Size (MSS). Зробити це можна внісши следущую рядок в /etc/ipnat.conf:Взаємодія з системами мережевого захисту
В описаному нами рішенні клієнт повинен послати UDP пакети на порт 500 і приймати з порту 4500 VPN шлюзу. Перші пакети обмінюються між 500 портами, а потім NAT-T переміщує обмін на порт 4500. Для роботи VPN необхідно відповідним чином скоригувати правила на межсетевом екрані.
Шлюз VPN і RADIUS
VPN клієнти
Cisco VPN client
Представлений вище VPN шлюз сумісний з Cisco VPN Client, налаштовані на груповий режим (те ж саме, що і Hybrid authentication). Необхідні ім'я групи і групової пароль ігноруються racoon (8). але на безпеку з'єднання не впливають.
Не забудьте направити IPsec через UDP і задіяти NAT-T.