MOLEHAND Solutions - Nagyvállalati megoldások mindenkinek

 
okt. 9

Written by: MOLEHAND
2014. 10. 09. 6:41

  1. 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.

  2. 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.)

  3. init-config
  4. notepad vars.bat

  5. Á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

  6. Állítsuk át 2048 bitre a kulcsméretet
    set KEY_SIZE=2048

  7. 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

  8. 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.

  9. vars
  10. clean-all

  11. 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.

  12. 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.

  13. 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

  14. 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.

  15. build-dh
    Generáljuk le a Diffie Hellman paramétereket.

  16. cd C:\Program Files\OpenVPN\bin
  17. openvpn --genkey --secret ta.key

  18. 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.

  19. 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!

  20. 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...)

  21. 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.

  22. 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-----


  1. 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

  2. Meg kell még adnunk a kliensnek, hogy hol találja a szervert, és melyik porton:
    remote molehand.eu 1194

  3. 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.

  4. 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.

  5. Nyissuk ki a routeren az OpenVPN portot, ill. forwardoljuk.
    Alapból ez az UDP 1194-es port.

  6. 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).

  7. 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.

  8. 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

  1. 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

  2. Másoljuk a létrejött crl.pem fájlt a config mappába

  3. Ellenőrizhetjük a fájlt a következő paranccsal

    openssl crl -in "c:\program files\openvpn\config\crl.pem" -text

  4. Adjuk hozzá a következő direktívát a szerver konfigjához:

    crl-verify "C:\\Program Files\\OpenVPN\\config\\crl.pem"

  5. Indítsuk újra az OpenVPN szervert. (Volt, amikor 2x kellett megtenni, hogy a beállítás érvényre jusson.)

  6. 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

  1. 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...

  2. Ne PowerShellt használjunk a beállításokhoz, azzal nem mennek a scriptek!

  3. 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-----

  4. 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ó!

  5. 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

Tags:

Your name:
Title:
Comment:
Security Code
Enter the code shown above in the box below
Add Comment    Mégsem  
 

Számítsa ki költségeit
  kalkulátorunkkal

tovább    

és nyerje meg
50 000 Ft értékű

ajándékunkat  

Akciós ajánlatunk

 Több szolgáltatót is volt szerencsém kipróbálni. Jelenleg minden projektünk a MOLEHAND-nél van elhelyezve, mert Ők nem csak egy szelet számítógépet adnak, hanem valódi szolgáltatást: Akármibe ütközök számíthatok a gyors és szakszerű reakcióra!