софтуер
Отдалечен достъп чрез VPN
Потребителят отдалечен достъп с помощта на IPsec
Създаване на VPN шлюз
клиенти VPN
софтуер
потребителска среда
Отдалечен достъп чрез VPN
С бързото развитие на DSL-връзка по телефонна линия е намалена, но необходимостта от сигурни връзки остават. Тук имаме подкрепата на VPN.
В тази статия, ние ще разгледаме само достъп чрез потребителско име / парола.
съображения за сигурност
За да създадете VPN връзка към потребителя и сървъра трябва да бъдат удостоверени за предотвратяване на атаки като "човек-в-средата".
Нашата задача - да се гарантира надеждността на VPN шлюз. В случай на предварително определен ключ, това ще позволи на някой хакер да извърши пробив във симулира шлюз, който ще доведе до катастрофални последици. За да се потвърди автентичността на врата, ние ще използваме сертификати x509. В същото време. Ние няма да инсталирате сертификати от страна на клиента.
възможни решения
Потребителят отдалечен достъп с помощта на IPsec
IPsec фаза 1 за удостоверяване
Първата фаза е IPSec IPsec Key Exchange (IKE) (обмен на ключове) и се изпълнява демон IKE, в NetBSD по-известен като миеща мечка (8). Този етап е предназначен за удостоверяване отдалечените краища на връзката и инсталирането на ключовете, използвани във втората фаза. Втората фаза се използва при смяна на ключове, които криптират трафика, и няколко пъти по време може да се появи на сесията. Първа фаза могат да бъдат подредени по два начина - предварително определен ключове и сертификати (предварително споделен). Това не е съвсем ни устройва, поради следните причини:- Предварително зададените ключове не са обвързани с потребителско име и ние не разполагаме с инструменти, за да ги управляват. Единственото нещо, което може да контролира - парола група.
- Първата фаза е симетрична, че предварително споделен ключ или удостоверение от двете страни на връзката. Това не е нашият метод.
Xauth е разширение на IKE удостоверяване, и добавя име / парола, след първата фаза. Това решава половината от проблема. Тъй като се извършва разпознаването след първата фаза, предадените данни вече е кодирано. Необходимостта от споделен ключ или сертификат е все още там, но ключовете не са безопасни, и сертификатът ще предизвика потребителското проблем, който ние абсолютно не е необходимо.
Hybrid упълномощаване
Ниво на защита IPSec с Xauth + Hybrid упълномощаване еквивалентно на SSH за използване на удостоверяване с парола.
ISAKMP режим довереник
NAT Traversal
Дистанционното потребителят може да бъде скрита зад мрежови адреси (NAT), има проблем използването на IPsec. Когато криптиране IPsec трафик използва протокол за 4-ниво, известен като Encapsulated Security полезен товар (ESP). За разлика от TCP или UDP, ESP не е номер на порт и не може правилно да преминава през NAT.
В 3947 и RFC 3948 описва метод ESP капсулиране в UDP и разширяване за IKE NAT IPSec контрол между крайните точки. Капсулиране и разширение са известни като NAT Traversal (NAT-T).
IKE разпокъсаност и ESP
Повечето отдалечените потребители в крайна сметка ще бъдат свързани чрез XDSL-модеми. Тези модеми често се прекратяват връзката много натоварено, UDP пакети, тъй като производителите на някак си вярват, че само използва UDP на DNS-заявките и ще падне по-големи или фрагментирани искания. А както знаем, ESP над UDP просто използвайте големи UDP пакети. За да се реши този проблем, ние ще използваме IKE фрагментация, друго разширение на IKE, което позволява на фрагменти големи пакети. Проблемът е решен с големи пакети преди фрагментация IP капсулиране в ESP, т.е. вместо чуплив (IP / UDP / ESP / IP), получен IP / UDP / ESP / чуплив (IP), така че устройството между крайни точки не се fidyat не фрагментирани пакети.
Мъртво Peer Откриване
Последно проблем: отдалечена връзка не може да бъде постоянен, откъсване от време на време. Вграден механизъм IPsec трябва от време на време, за да доведе до втората фаза на IKE ключове за препредаване, и когато един опит да прекъсне сесията. Този механизъм не е много удобно. За да се контролира редовно Връзката използва разширението IKE, наречено Мъртво Peer Detection (DPD). DPD е в състояние да се провери наличието на екстремните точки на мултиплициране в рамките на няколко секунди.
Създаване на VPN шлюз
конфигуриране на ядрото
пакет за маршрутизиране
Необходимо е да се даде възможност за изпращане на IPv4 пакети:Създаване на сертификати
Конфигуриране миеща мечка (8)
Ето един пример /etc/racoon/racoon.conf конфигурационен файл:раздробяване
Използването ESP фрагментация могат да бъдат обменяни през тунела пакети IP от всякакъв размер. Но има особености при работа с TCP, което би могло да бъде проблем с Отдела за Path Maximum Transmission (PMTU). Разтворът е Максимална Сегмент Размер (MSS) на фиксиране. Можете да направите това чрез следния ред в /etc/ipnat.conf:Взаимодействие с защитни стени
В решение на описаните контакт, клиентът трябва да изпрати UDP пакети към порт 500 и да получи VPN шлюз порт 4500. Първите пакети се обменя между пристанищата на 500, а след това NAT-T ходове-за порт 4500. За да използвате VPN необходимо правилно да се изравнят правилата на защитната стена.
VPN шлюз и RADIUS
клиенти VPN
Cisco VPN клиент
Горната VPN шлюз, съвместим с Cisco VPN Client, конфигуриран в режим на група (същото като на Hybrid удостоверяване). се въведе име на група и група паролата са игнорирани миеща мечка (8). но към съединение на безопасността не е засегната.
Не забравяйте да изпратите IPsec над UDP и даде възможност на NAT-T.
миеща мечка (8) като клиента: конфигурация например
Създаване и VPN връзки почивка
Запазване на паролата Xauth
Ако не искате да въвеждате паролата си всеки път, когато Xauth, можете да запишете файла в предварително споделен ключ миеща мечка е (PSK) на предварително зададените ключове. Добавяне на секция на дистанционно /etc/racoon/racoon.conf файл: