By Halász István on
2014. 10. 09. 6:41
- Töltsük le a programot innen, és installáljuk fel a szerverre úgy, hogy bepipáljuk az OpenSSL Utilities-t és a Certificate Management Scripts-et is.
- Indítsunk egy rendszergazdai parancssort és navigáljunk a C:\Program Files\OpenVPN\easy-rsa mappába. (A kiadandó parancsokat félkövérrel írom.)
- init-config
- notepad vars.bat
- Állítsuk át az elérési utat rövidnevesre. Előtte teszteljük, hogy jó helyre mutat-e:
HOME=c:\Progra~1\OpenVPN\easy-rsa
- Állítsuk át 2048 bitre a kulcsméretet
set KEY_SIZE=2048
- Szerkesszük az alábbi sorokat értelemszerűen:
set KEY_COUNTRY=US
set KEY_PROVINCE=CA
set KEY_CITY=SanFrancisco
set KEY_ORG=OpenVPN
set KEY_EMAIL=mail@host.domain
- Mentsük a fájlt, és lépjünk ki a notepadből. Már backupolhatjuk is ezt a fájlt, hogy véletlen törlés esetén ne kelljen újra belőni.
- vars
- clean-all
- Ezután akár érdemes is átnevezni a clean-all.bat-ot pl. clean-all.ba_-ra, hogy ne tudjuk véletlenül kitörölni a tanúsítványokat egy mozdulattal.
- build-ca
Amikor bekéri a script, adjuk be a paramétereket. A default praméterek szögletes zárójelben vannak.
Ha a default paraméter megfelel, csak Entert kell nyomni.
Üres stringet úgy tudunk megadni, ha egy pontot írunk, és utána Entert nyomunk. Az OU és a Name nyugodtan lehet üres string, a Common Name az igazán fontos, annak kell egyedinek lennie.
Ebben a lépésben érdemes Common Namenek "Cégnév-CA"-t megadni.
- build-key-server
Ezzel a paranccsal hozzuk létre a szerver tanúsítványát.
A build-key parancsok paramétere lesz a fájl neve (jelen esetben .crt, .key, stb.)
A Common Name nyugodtan lehet szintén .
A sign the certificate? kérdésnél y és enter
A commit? kérdésnél y és enter
- build-key-pass mike-laptop
Ezzel a paranccsal hozzuk létre a kliens tanúsítványokat. Ebben a példában Mike laptopjához csinálunk egy tanúsítványt, méghozzá egy jelszóval titkosítottat, mely jelszót az első lépésben be fog kérni a script.
Lehetőség van rá, hogy jelszó nélküli tanúsítványt hozzunk létre, ekkor az adott gépen nem lesz szükség jelszó megadására a VPN-hez való csatlakozáshoz, szimplán a tanúsítvány szolgál majd azonosításra. Ehhez a build-key mike-laptop parancsot kell használjuk.
- build-dh
Generáljuk le a Diffie Hellman paramétereket.
- cd C:\Program Files\OpenVPN\bin
- openvpn --genkey --secret ta.key
- Másoljuk a létrejött ta.key-t a keys mappába (hogy később meglegyen), valamint tegyük a Config mappába a másik négy konfigurációs fájllal (ca.crt, .crt, .key, dh2048.pem) együtt.
- Keressük meg a minta config fájlokat. A következő lépésekben ezeket editáljuk majd.
Start Menu -> All Programs -> OpenVPN -> OpenVPN Sample Configuration Files
A parancsok előtti ; szintén "kommentet" jelöl, azaz ezeket a sorokat nem veszi figyelembe a program!
- Nyissuk meg a server.ovpn-t, és állítsuk be az alábbi sorokban az elérési utakat az alábbiakhoz hasonlóan, majd mentsük el a Config mappába a végeredményt.
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\hspsrv.crt"
key "C:\\Program Files\\OpenVPN\\config\\hspsrv.key"
dh "C:\\Program Files\\OpenVPN\\config\\dh2048.pem"
tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 0
A tls-auth direktíva használata nem kötelező, de érdemes használni. Segítségével az összes SSL/TLS handshake csomag integritását ellőrzi a program kapcsolódáskor. Azaz titkosítja ezzel a kulccsal, és ha a másik oldalon nem stimmel a kicsomagolás, akkor eldobálja a csomagokat. (Csak egy példa: amelyik szerver esetén ez be volt kapcsolva, ott nem lehetett a Heartbleed hibát kihasználni...)
- Figyelembe ajánlott, opcionális szerver konfigurációs parancsok (a használatukhoz kommenteljük ki őket):
push "route 172.20.20.0 255.255.255.0"
A szerver LAN ip tartományáról szerezhetnek így tudomást a kliensek.
push "redirect-gateway def1 bypass-dhcp"
Azt mondjuk ezzel a kliensnek, hogy minden internetnek szánt csomagot a VPN kapcsolaton keresztül küldjön. Ahhoz, hogy ki is lásson a kliens az internetre a VPN szerveren keresztül, extra konfigurációra van szükség a szerver oldalon, amelynek utána kell nézni.
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
push "dhcp-option WINS 10.0.0.100"
No comment. :)
duplicate-cn
Ha egy tanúsítvánnyal többszörös párhuzamos kapcsolódást is szeretnénk engedélyezni, ezt a direktívát kell használjuk.
- A client.ovpn-nnel hasonlóképp járhatunk el, azonban macerás elmagyarázni az ügyfélnek, hogy ezt a sok fájlt másolja be ide, ha 64bites a gép, akkor meg oda. Szerenécsere van egy szebb megoldás, be lehet az ovp fájlokba építeni a cert-eket/kulcsokat, így egy db fájlunk lesz kliensenként. Ekkor töröljük ki az elérésí utas sorokat, és az alábbi struktúrába másoljuk bele a notepaddel megnyitott fájlokból a megfelelő részeket:
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN ENCRYPTED PRIVATE KEY-----
...
-----END ENCRYPTED PRIVATE KEY-----
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
- Ha az elérési utas megoldást választottuk, akkor a kliens konfigokban a tls-auth direktíva 1-esre végződik (ezzel jelezzük, hogy ez a kliens oldal):
tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 1
ha pedig a kulcs "beépítést", akkor a következő sort kell hozzáadnunk a konfighoz:
key-direction 1
- Meg kell még adnunk a kliensnek, hogy hol találja a szervert, és melyik porton:
remote molehand.eu 1194
- remote-cert-tls server
Amennyiben egy rosszindulatú személy megszerezne egy kliens konfigot, akkor az ahhoz tartozó tanúsítványokat szerver üzemmódban is tudja futtatni, és így man-in-the-middle támadást tud létrehozni, amikor is azt hiszed, hogy a céges VPN szerverhez csatlakozol, miközben az ő szerverként futtatott kliens konfigjához. A build-key-server és build-key scriptek "megjelölik" a tanúsítványokat, hogy "kérem ez a tanúsítvány szervernek / kliensnek lett létrehozva". A fenti direktívával biztosra mehetünk, csak "szerver" azonosítójú tanúsítványhoz lesz hajlandó a kliens csatlakozni.
- Ezzel a konfig fájlokkal végeztünk, másoljuk be őket a config mappába. Ehhez a klienseken is telepítsük fel az OpenVPN-t (az OpenSSL Utilities és a Certificate Management Scripts ezeken nem fog kelleni). Ne lepődjünk meg, a kliens és a szerver telepítő teljesen ugyanaz, csak a konfig fájlok döntik el, hogy egy gép szerverként vagy kliensként viselkedik.
- Nyissuk ki a routeren az OpenVPN portot, ill. forwardoljuk.
Alapból ez az UDP 1194-es port.
- Ha el kell érni a LAN-t a VPN-en keresztül, azaz használjuk az alábbi direktívát
push "route 172.20.20.0 255.255.255.0"
egy statikus útvonalat is fel kell venni a routerben, hogy a csomagok visszataláljanak:
route add 10.8.0.0 mask 255.255.255.0 metric
Ezen kívül szükség van még egy dologra: az OpenVPN szervernek is kell tudnia route-olnia, hogy a VPN hálózatból a LAN hálózatba átforgassa a csomagokat és vissza. Ezért amennyiben nem működik a kapcsolódás a LAN-ra a fenti beállítások elvégzése után, úgy a következő registry módosítást kell eszközöljük:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters
Itt az IpEnableRouter bejegyzést állítsuk 1-re (ill. hozzuk létre, ha nincs).
- A szerveren a szolgáltatások között keressük meg az OpenVPN service-t, állítsuk Automatikus indulásúra, és indítsuk is el.
- A klienseken az OpenVPNGUI parancsikonnal tudjuk indítani.
Abban az esetben, ha van a usernek rendszergazda joga, állítsuk be a parancsikont, hogy mindig rendszergazdaként indítsa a GUI-t. Erre azért van szükség, mert az útvonal hozzáadáshoz rendszergazda jogokra van szükség Windows alatt.
Ha nincs, itt is a service-ként való futtatás jelenti a megoldást. A service-hez tudunk jogosultságot adni, így nem feltétlenül kell ilyen esetben feltétlenül folyamatos VPN kapcsolatot fenntartani.
A tanúsítványokat/kulcsokat őrizzük meg jól, érdemes a rendszeres mentésbe belevenni a keys mappát! Erre azért van szükség, mert nem szeretnénk MINDEN tanúsítványt újra elkészíteni, amennyiben egy eszközt ellopnak, rajta a VPN konfiggal. Ezt úgy tudjuk megspórolni, ha az adott tanúsítványt visszavonjuk, ezt azonban csak akkor tudjuk megtenni, ha megvan maga a tanúsítvány!
TANÚSÍTVÁNYOK VISSZAVONÁSA
- Tanúsítvány visszavonó lista létrehozása (Certificate Revoking List (CRL))
revoke-full
A parancs végrehajtása után az utolsó sorban ezt kell lássuk:
error 23 at 0 depth lookup:certificate revoked
- Másoljuk a létrejött crl.pem fájlt a config mappába
- Ellenőrizhetjük a fájlt a következő paranccsal
openssl crl -in "c:\program files\openvpn\config\crl.pem" -text
- Adjuk hozzá a következő direktívát a szerver konfigjához:
crl-verify "C:\\Program Files\\OpenVPN\\config\\crl.pem"
- Indítsuk újra az OpenVPN szervert. (Volt, amikor 2x kellett megtenni, hogy a beállítás érvényre jusson.)
- Ha mindent jól csináltunk, minden, ezzel a tanúsítvánnyal történő csatlakozás innentől meg fog hiúsulni, és a következőhöz hasonló lesz látható a kliens logban:
CRL CHECK FAILED: C=US, ST=CA, L=City, O=name, OU=name.example.org, CN=client, name=client, emailAddress=openvpn@example.org is REVOKED
HIBAKERESÉS
- Ha a tűzfal kikapcsolt állapotában minden oké, de bekapcsoltan nem működik, akkor valószínűleg a VPN hálózat azonosítatlan (Unidentified) besorolásával lesz a probléma. Erre szép megoldást még nem találtam*, de workaround van: át kell állítani a Local Security Policy-ben, hogy az Unidentified hálózatok alapértelmezés szerint ne Public, hanem Private besorolást kapjanak. Mivel wifi elvétve van a szerverekben, így ez nem tűnik annyira komoly biztonsági kockázatnak.
*A kézi átállítást úgy tűnik nem jegyzi meg a Windows, újraindítás után újra Public lesz a VPN hálózat...
- Ne PowerShellt használjunk a beállításokhoz, azzal nem mennek a scriptek!
- Ha nem sikerül kapcsolódni a következőhöz hasonló hibával a logban
SIGUSR1[soft,private-key-password-failure]
akkor valószínűleg "beépítős" konfig fájlt használunk, és egy plusz sortörés karakter került a konfigba egy ------ -es sor és maga a cert/kulcs közé. Notepad++-al megnyitva a konfig fájlt, és bekapcsolva a speciális karakterek mutatását, ellenőrizzük le. Általában a [*]
-vel jelölt helyen lévő sortörés szokott problémát okozni:
CRLF
-----BEGIN ENCRYPTED PRIVATE KEY-----LF
[*]
xxxxxxxxxxxxxxxxxxxxxxxxxxxLF
xxxxxxxxxxxxxxxxxxxxxxxxxxxLF
xxxxxxxxxxxxxxxxxxxxxxxxxxxLF
-----END ENCRYPTED PRIVATE KEY-----LF
CRLF
Az is lehet a probléma gyökere, ha lusták voltunk, és nem egy-az-egyben másoltuk a kulcsot, hanem csak a ------- -ek közötti részt, ugyanis a fejlécek különbözőek jelszavas és jelszó nélküli esetben. Jelszó nélküli esetben ilyen a fejléc:
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
- Script futtatásakor (build-key például) az alábbi hibaüzenethez hasonlót látunk:
STR_COPY:variable has no value
Amennyiben a vars.bat-ban valamelyik paraméter default értékének üres stringet adtunk meg, akkor találkoztam vele, ekkor ugyanis nem fog létrejönni az adott környezeti változó!
- ERROR: Windows route add command failed: returned error code 1073807366 a kliens logban
Győződjünk meg róla, hogy rendszergazdaként indítottuk az OpenVPNGUI-t. Ha nem ez a gond, akkor adjuk hozzá a következő direktívát a kliens konfighoz:
ip-win32 ipapi