Opennet cikk - a távoli felhasználók vpn hozzáférését a kiszolgálóhoz netbsd (vpn netbsd
szoftver
Távoli hozzáférés VPN-en keresztül
Távoli felhasználói hozzáférés IPsec segítségével
A VPN-átjáró konfigurálása
VPN ügyfelek
szoftver
Felhasználói környezet
Távoli hozzáférés VPN-en keresztül
A DSL-kapcsolatok gyors fejlesztése miatt a modemkapcsolat értéke csökken, de a biztonságos kapcsolatok iránti igény továbbra is fennáll. Itt segített egy VPN.
Ebben a cikkben csak a bejelentkezéshez / jelszóhoz való hozzáférést vesszük fontolóra.
Biztonsági szempontok
VPN-kapcsolat létrehozásához a felhasználónak és a szervernek meg kell erősítenie hitelességét, hogy kizárja a "mid-to-mid" támadást.
Feladatunk a VPN-átjáró megbízhatóságának biztosítása. Előre definiált kulcs esetén kompromisszuma lehetővé teszi, hogy egy támadó egy átjárót szimuláljon, ami katasztrofális következményekhez vezethet. Az átjáró hitelességének igazolásához x509 tanúsítványokat használunk. Ebben az esetben. nem fogunk tanúsítványokat telepíteni az ügyfél oldalán.
Lehetséges megoldások
Távoli felhasználói hozzáférés IPsec segítségével
Az IPsec hitelesítés 1 fázisa
Az IPSec első fázisa IPsec kulcscsere (IKE) (kulcscsere), amelyet az IKE démon hajt végre, a NetBSD-ben pedig jobban ismert racoon (8). Ez a fázis célja, hogy megerősítse a kapcsolat távoli végeinek hitelességét és telepítse a második fázisban használt kulcsokat. A második fázis a forgalom titkosítására szolgáló kulcsok megváltoztatásakor használható, és több munkanaponként is előfordulhat. Az első fázis kétféleképpen szervezhető: előre megosztott kulcsok és tanúsítványok. Ez a következő okokból nem felel meg nekünk:- Az előre definiált kulcsok nem kapcsolódnak a felhasználónévhez, és nem rendelkezünk azok kezelésével. Az egyetlen dolog, amit kezelhetünk, a csoport jelszava.
- Az első fázis szimmetrikus, ami azt jelenti, hogy ugyanazok a kulcsok vagy tanúsítványok a kapcsolat mindkét oldalán. Ez nem a mi módszerünk.
Az Xauth egy IKE kiterjesztés, és az első fázis után hozzáadja a bejelentkezés / jelszó hitelesítését. Ez a képesség eltünteti problémáink felét. Mivel a hitelesítés az első fázis után történik, a továbbított adatok már titkosítottak. A közös kulcs vagy tanúsítvány szükségessége továbbra is fennáll, de a kulcsok nem biztonságosak, és a tanúsítvány problémákat okozhat a felhasználóknak, amelyekre nincs szükségünk.
Hibrid auth
Az IPsec + Xauth + Hybrid auth védelmi szintje megfelel az SSH jelszóval történő hitelesítésének.
ISAKMP mód beállítása
NAT Traversal
Mivel a távoli felhasználó elrejthető a Network Address Translator (NAT) mögött, a probléma felmerül az IPsec alkalmazásának. Forgalom titkosításakor az IPsec a 4-szintű protokollt használja Encapsulated Security Payload (ESP) néven. A TCP vagy az UDP-vel ellentétben az ESP nem rendelkezik portszámmal, és nem tud átjutni a NAT-on keresztül.
Az RFC 3947 és 3948 leírja az ESP beágyazására szolgáló módszert UDP és IKE kiterjesztésekben a NAT kezelésére az IPSec végpontok között. A kapszulázás és a kiterjesztések általánosan NAT Traversal (NAT-T) néven ismertek.
Az IKE és az ESP fragmentálása
A legtöbb távoli felhasználó végül csatlakozik xDSL modemeken keresztül. Az ilyen modemek gyakran megszűnik a linket nagy terhelés alatt, UDP csomagokat, mert a gyártók valahogy úgy vélik, hogy csak akkor használja UDP A DNS-kéréseket, és csökkenni fog nagyobb vagy töredezett kéri. És ahogy emlékszünk rá, az UDP-t használó ESP csak nagy UDP csomagokat használ. A probléma megoldásához az IKE fragmentációt, egy másik IKE bővítményt használjuk, amely lehetővé teszi számunkra, hogy nagy csomagokat töröljünk. A probléma megoldódott a nagy csomagok, mielőtt töredezettség IP beágyazása az ESP, azaz helyett frag (IP / UDP / ESP / IP) kapott IP / UDP / ESP / Frag (IP), így az eszköz a végpontok között nem fidyat nem töredezett csomagok.
Dead Peer Detection
Az utolsó probléma: a távoli kapcsolat nem lehet állandó, időről időre leáll. A beépített IPsec-mechanizmusnak időről-időre hívnia kell az IKE második fázisát, hogy továbbadja a kulcsokat, és ha a kísérlet meghiúsul, akkor véget kell vetni a munkamenetnek. Ez a mechanizmus nem túl kényelmes. A rendszeres kapcsolatvizsgálathoz egy Dead Peer Detection (DPD) nevű IKE kiterjesztést használnak. A DPD több másodperces többszörös pontossággal ellenőrizheti a szélsőséges pontok elérhetőségét.
A VPN-átjáró konfigurálása
Kernel konfiguráció
Csomag útválasztás
Engedélyeznie kell az IPv4 csomag átirányítását:Tanúsítványok létrehozása
Rögbi konfigurálása (8)
Íme egy példa a /etc/racoon/racoon.conf konfigurációs fájlról:Fragmentációs problémák
Szétdarabolva az ESP az IP-alagúton keresztül bármilyen méretű csomagokkal kicserélhető. De van specifikus a TCP-vel való munkavégzés során, hiszen problémák merülhetnek fel a Pálya Maximális Átviteli Egységgel (PMTU). A megoldás a Maximális szegmens mérete (MSS) rögzítése. Ezt a következő sor beírásával teheti meg: /etc/ipnat.conf:Kapcsolódás a hálózati védelmi rendszerekkel
Az általunk leírt megoldásban az ügyfélnek UDP csomagokat kell küldenie az 500-as portra és kapnia kell egy átjárót a 4500 VPN portjából. Az első csomagok 500 port között cserélődnek, majd a NAT-T áthelyezi az adatcserét a 4500-as portra. A VPN működéséhez szükség van a tűzfal szabályainak megfelelő beállítására.
VPN és RADIUS Gateway
VPN ügyfelek
Cisco VPN kliens
A fenti VPN-átjáró kompatibilis a Cisco VPN-ügyfélprogrammal, amely csoportos üzemmódra van konfigurálva (ugyanúgy, mint a hibrid hitelesítés). A szükséges csoportnevet és csoportjelszót a racoon (8) figyelmen kívül hagyja. de a kapcsolat biztonságát nem érinti.
Ne felejtse el küldeni az IPsecet UDP-n keresztül, és engedélyezze a NAT-T-t.