Ez a post most dedikáltan, külön igényre készült, Paluska Misi komámnak, a bloggazdának. Az előző VPN-ről szóló írásban kifejezte igényét hozzászólásában olyan, a PPTP-nél biztonságosabb megoldásra, melyet ő egyaránt tudna használni a rendelkezésére álló eszközeiről, pl. rendszereinek távelérésére. Apple alapú rendszereken ugyan a PPTP VPN kliens is beépítve megtalálható, azonban, mint ezt említettem is, nem a legbiztonságosabbnak kikiáltott típusa ez a VPN-eknek. Ami ennél sokkalta jobb faktorral rendelkezik biztonság szempontjából, és több ma használt okostelefon is alapból támogatja, az L2TP VPN, IPSEC-kel ötvözve. Szóljon most erről ez a bejegyzés.
VPN megoldások II. – L2TP/IPSEC VPN szerver
Mi az L2TP?
Az L2TP a Layer 2 Tunneling Protocol rövidítése. Az L2TP tulajdonképpen a már megismert PPTP protokollnak és a Cisco Layer 2 Forwarding megoldásának az összeházasításából született meg. PPP hitelesítési módszert és tunneling megoldást alkalmaz, ami alkalmas két egymástól eltérő alhálózat összekötésére, azonban titkosítást önmagában nem használ, ezért önmagában a módszer nem biztonságos. Ezért gyakorlat szerint a IPSEC protokollkészlettel ötvözve alakítunk ki egy kevert megvalósítást, ahol a tunnelt az L2TP, a biztonságot pedig az IPSEC szolgáltatja. Tegyük mindezt OpenBSD platformon.
Topológia
Első lépések
Sajnos OpenBSD-n a szükséges csomag telepítését nem könnyítették meg nekünk a fejlesztők: a L2TP-t megvalósító daemon-t nem találtam meg a legfrissebb port-tree-ben sem. Kénytelen voltam forrásból feltelepíteni, amit CVS-sel kellett letöltenem, igaz, túl bonyolult ez sem volt:
Ennél a pontnál pihenjük kicsit (vagy igyunk meg egy jó sört, a sorok írásakor a külső hőmérséklet is bőven 25 fok fölött van), számolnunk kell a internet kapcsolatunk sebességétől függően 10-15 perccel.
Körülbelül így ér véget a forrás-update. Ezután tegyük a következőket:
# cd /usr/src/usr.sbin/npppd
# make depend
# make
# make install
A csomagunk, mely a L2TP szerver működéséért közvetlen felelős lesz, fel lett telepítve. Eddig ok. Mi jön még?
Bizonyos, a helyes működéshez elengedhetetlen kernel-paramétereket módosítanunk kell, ezek pedig:
# sysctl net.inet.ip.forwarding=1
# sysctl net.inet.esp.enable=1 # Enable the ESP IPsec protocol
# sysctl net.inet.ah.enable=1 # Enable the AH IPsec protocol
# sysctl net.inet.ipcomp.enable=1 # Optional: compress IP datagrams
# sysctl net.pipex.enable=1
Ezeket persze érdemes beszúrni az /etc/sysctl.confba, hogy érvényesüljenek újraindítás után is. Majd létre kell hoznunk konfigurációs állományt, amely hasonlóképp fog kinézni :
# cat /etc/npppd/npppd.conf
interface_list: tun0
interface.tun0.ip4addr: 172.16.0.1
# IP address pool
pool.dyna_pool: 172.16.0.0/24
# Local file authentication
auth.local.realm_list: local
auth.local.realm.acctlist: /etc/npppd/npppd-users.csv
realm.local.concentrate: tun0
lcp.mru: 1400
auth.method: mschapv2 chap
# L2TP daemon
l2tpd.enabled: true
l2tpd.ip4_allow: 0.0.0.0/0
#l2tpd.listener_in: L2TP 192.168.0.1
#l2tpd.purge_ipsec_sa: true
l2tpd.require_ipsec: true
#l2tpd.accept_dialin: true
pptpd.enabled: false
pptpd.ip4_allow: 0.0.0.0/0
pppoed.enabled: false
pipex.enabled: true
Kell még egy „adatbázis”, ahonnan az autentikációs adatok lesznek feldolgozva, erre a fenti konfigban hivatkozik is egy sor:
auth.local.realm.acctlist: /etc/npppd/npppd-users.csv
# cat /etc/npppd/npppd-users.csv
Username,Password,Framed-IP-Address,Framed-IP-Netmask,Description,Calling-Id
user1,secret,172.16.0.5,,memo for user1
user2,secret,172.16.0.6,,memo1 for user
Nem elírás, az első sor azért nincs kikommentezve, mert az npppd nem fogja ezt figyelembe venni, hasonlóan, mintha RADIUS konfig volna. Viszont jól látható, hogy mely oszlop mely autentikációs adatnak fog megfelelni (username,pass, etc.) Továbbá az IP cím, melyet kliens majd meg fog kapni a sikeres csatlakozáskor. Ha ilyet nem adunk meg, akkor a ’pool.dyna_pool’-ban deklarált IP poolból fog osztani egyet véletlenszerűen.
Eddig szép és jó, tulajdonképpen a tunnel, TITKOSÍTÁS NÉLKÜL már most is működne, de mi nem érjük be ennyivel. Ígértünk IPSEC titkosítást is. Nézzük meg ezt is. Ezt nekünk az ’isakmpd’ daemon fogja biztosítani (ezt már szerencsére nem kell külön fordítanunk; megtalálható a disztribúcióban). Hozzunk létre ennek is egy konfigurációs állományt.
# cat /etc/ipsec.conf
ike passive esp transport proto udp from 192.168.55.13 to any port 1701 main auth “hmac-sha1” enc “3des” group modp1024 quick auth “hmac-sha1” enc “aes” psk “password
Gyors magyarázatként a fentebbi ipsec.conf-hoz elmondhatjuk, hogy az IPSEC beágyazott tunnel a 192.168.55.13-as IP-n fog várakozni, UDP 1701 portot használva. Az algoritmusokra, Diffie-Hellmann groupra most nem térnék ki, a ’psk’ azonban nekünk még fontos lesz: a pre-shared-key nekünk most a „password” lesz (értelemszerűen ezt a megosztott kulcsot, mely az encryption-höz kell, érdemes minék bonyolultabbra beállítani (kis- és nagybetű, szám, speciális karakter)).
Ha az előzőekben leírtakkal megvagyunk, indítsuk el az isakmpd daemont, a következő flagekkel:
# isakmpd -4Kv
ahol a -4 jelenti, hogy csak IPv4-en szolgáltat, a –K azt, hogy az algoritmusokat külső alkalmazás szolgáltatja (a mi esetünkben az ipsec alkalmazás, a –v pedig a bőbeszédű logolást).
Ezután indítsuk el az npppd daemont!
# npppd –d (ha szeretnénk a konzolkimenetet látni, vagy –D , ha daemonként futtatjuk).
Majd végül olvastassuk be az isakmpd-nek a titkosítási algoritmusokat:
# ipsecctl –f /etc/ipsec.conf
Mivel, hasonlóan a PPTP-hez, nem tudunk egyedi routekoat leosztani, kénytelen kelletlen a tunnelre fogjuk terelni az összes, nem helyi hálózati forgalmunkat (ill. ha tudjuk, mit csinálunk, és engedi a platform is kliens oldalon, adhatunk egyedi routeokat kézzel is), így a tűzfalunkon NAT szabályt is kell megadnunk (/etc/pf.conf):
pass out on tun0 to !em0 nat-to 192.168.55.13
pass out on em0 to !em0 nat-to 192.168.55.13
Így, mikor a nem-helyi forgalom a tunnelen keresztül a VPN szerver felé indul, és ott nem kerül be a tunnel másik oldalán levő hálózatba, hanem default gatewayen keresztül menne tovább, előbb NAT-olva lesz, lehetővé téve az internettel való kommunikációt.
Szerveroldalról tehát kész vagyunk. A következőkben nézzük a kliens oldalt, legyen ez akár iPhone, Android, ill. Windows. Mivel Windoes kliens konfig már volt, iPhone-om pedig nincs, marad az Android platform, de minimális megfeleltetéssel mindhárom helyen ugyanezek lesznek opciók.
Kliens config
A telefon itt egy Samsung Galaxy SII (GT-I9100), Android ICS 4.0.3-as OS-sel (gyári). Lássuk.
1., Alkalmazások -> Beállítások -> Egyebek -> VPN
Amint a ’VPN’ menüre nyomunk, már jön is a figyelmeztetés:
Ide egy feloldó mintát kell állítanunk, ugyanis a telefon ill. az Android komolyabb feloldási biztonság nélkül nem hagyja, hogy VPN-t állítsunk be.
Válasszuk a mintát, és rajzoljunk valamit 🙂
Tudom, nem lihegtem túl, dehát a teszt az teszt 🙂 Válasszunk a VPN hálózat hozzáadását:
Válasszuk az L2TP/IPSEC PSK módot. Írjuk be a VPN szerver KÜLSŐ IP-jét, majd adjuk meg a pre-shared key-t (amit ugye jó bonyolultra állítottunk).
Mentsük el a konfigot!
A VPN beállításunk kész. Teszteljük! Bökjünk rá, majd azonosítsuk magunkat!
Ha megadtuk az azonosítót ill. jelszót, akkor „Kapcsolódás” !
Látjuk, hogy csatlakoztunk, ill. a bal felső sarokban egy helyes kis kulcs ikon is jelzi, hogy biztonságos hálózati kapcsolatunk aktív.
Ha pedig egy ping tesztet is vizsgálunk, akkor látjuk, hogy teljes mértékben sikeresen konfiguráltunk mindkét oldalon.
A titkosítási szintet Androidon nem tudom megmutatni, azonban idevágom a Windows 7 státuszát (a beállítások pontról pontra megegyeznek!):
Hát, ennyi! Adós vagyok még egy log-részlettel, csak hogy tudjuk, hogy kell vizsgálódnunk, ha bármi is nem működik vagy egyszerűen csak mert kíváncsiak vagyunk:
Jól látszik az isakmpd kezdetű soroknál az IPSEC kapcsolat felépülése, majd az npppd kezdetűeknél a tunnel létrejötte.
Összegzés
Az L2TP/IPSEC a biztonságos tunnelnek már egy jóval magasabb fokát valósítja meg (a titkosítás AES 256 bit is lehet, mint látszik a képen, ez gyakorlatban nem törhető). Sajnos, ezzel arányosan a szerveroldali konfigurációja is bonyolultabbá válik. Az egyedi routeok kiosztása itt is csak komolyabb nehézségek árán valósítható meg (ha szerveroldal Windows AD, valamivel könnyebb). Ám előnyére mondható, hogy amint a cikk elején említettem, ez sem igényel a legtöbb platformon 3rd party alkalmazást. Kinek-kinek egyéni ízlése, hogy VPN irányban mire „szakosodik”, én ezt a megoldást inkább a bemutató kedvéért konfiguráltam be.