14.10. VPN IPsec felett
Vissza | 14. fejezet - Biztonság | Előre

## 14.10. VPN IPsec felett

Írta: Clayton, Nik.

VPN létrehozása FreeBSD átjárók használatával két olyan hálózat között, amelyeket egymástól az internet választ el.

### 14.10.1. Az IPsec bemutatása

Írta: Pandya, Hiten M..

Ebben a szakaszban az IPsec beállításának folyamatát vázoljuk fel. Az IPsec beállításához elengedhetetlen, hogy tisztában legyünk egy saját rendszermag fordításának alapjaival (lásd 8. fejezet - A FreeBSD rendszermag testreszabása).

Az IPsec egy olyan protokoll, amely az Internet Protocol (IP) rétegére épül. Segítségével két vagy több számítógép képes biztonságos módon tartani egymással a kapcsolatot (innen ered a neve). A FreeBSD IPsec „hálózati protokollkészlete” a KAME implementációjára épül, mely egyaránt támogatja az IPv4 és IPv6 protokollcsaládokat.

Az IPsec két alprotokollból tevődik össze:

- A hasznos adat biztonságos becsomagolása (Encapsulated Security Payload, ESP) során egy szimmetrikus kriptográfiai algoritmussal (mint például Blowfish, 3DES) titkosítjuk az IP-csomagok tartalmát, ezáltal megvédjük ezeket az illetéktelenektől.

- A Hitelesítési fejléc (Authentication Header, AH) használatával megakadályozzuk, hogy az illetéktelenek meghamisítsák az IP csomagok fejlécét. Ezt úgy érjük el, hogy kiszámolunk egy kriptográfiai ellenőrző összeget és az IP-csomagok fejlécének mezőire egy biztonságos függvénnyel generálunk valamilyen ujjlenyomatot. Az ez után következő kiegészítő fejléc tartalmazza ezt az ujjlenyomatot, amellyel a csomag hitelesíthető.

Az ESP és az AH az alkalmazástól függően használható együtt vagy külön-külön.

Az IPsec akár közvetlenül is használható két számítógép forgalmának titkosítására (ezt Szállítási módnak (Transport Mode) nevezik), vagy két alhálózat között építhetünk ki vele „virtuális tunneleket”, ami remekül alkalmas két vállalati hálózat kommunikációjának bebiztosítására (ez a Tunnel mód (Tunnel Mode)). Ez utóbbit egyszerűen csak Virtuális magánhálózatként (Virtual Private Network, VPN) emlegetik. A FreeBSD IPsec alrendszeréről az ipsec(4) man oldalon találhatunk további információkat.

A rendszermag IPsec támogatásának aktiválásához a következő paramétereket kell beletennünk a konfigurációs állományba:

    options   IPSEC        # IP biztonság
    device    crypto

Ha szükségünk van a IPsec nyomkövetésére, a következő beállítást is hozzátehetjük:

    options   IPSEC_DEBUG  # az IP biztonság nyomkövetése

### 14.10.2. A probléma

Semmilyen szabvány nem fogalmazza meg mi is számít VPN-nek. A virtuális magánhálózatok tucatnyi különböző technológiával valósíthatóak meg, de mindegyiknek megvan a maga erőssége és gyengesége. Ebben a szakaszban körvonalazunk egy ilyen helyzetet, valamint a benne felépített VPN megvalósításához alkalmazott stratégiákat.

### 14.10.3. A forgatókönyv: adott egy otthoni és egy vállalati hálózat, amelyek külön-külön csatlakoznak az internetre, és VPN használatával ezeket egyetlen hálózatként szeretnénk használni

Előfeltételezéseink a következőek:

- legalább két hálózatunk van;

- magán belül mind a két hálózat IP-t használ;

- mind a két hálózat egy FreeBSD átjárón keresztül csatlakozik az internethez;

- a hálózatok átjárói legalább egy publikus IP-címmel rendelkeznek;

- a hálózatok belső címei lehetnek publikus vagy privát IP-címek, nem számít. Fontos viszont, hogy ezek ne ütközzenek, vagyis ne használja egyszerre mind a kettő a `192.168.1.x` címtartományt.

### 14.10.4. Az IPsec beállítása FreeBSD alatt

Írta: Rhodes, Tom.

Kezdésképpen a Portgyűjteményből telepítenünk kell a security/ipsec-tools portot. Ez a programcsomag rengeteg olyan alkalmazást tartalmaz, amely segítségünkre lehet a beállítások elvégzése során.

A következő lépésben létre kell hoznunk két gif(4) típusú pszeudoeszközt, melyeken keresztül a két hálózat között egy tunnel segítségével ki tudjuk építeni a szükséges kapcsolatot. Ehhez `root` felhasználóként futtassuk a következő parancsokat (a `belső` és `külső` megnevezésű paramétereket cseréljük ki a valós belső és külső átjárók címeire):

    # ifconfig gif0 create

    # ifconfig gif0 belső1 belső2

    # ifconfig gif0 tunnel külső1 külső2

Tekintsük például, hogy a vállalati LAN publikus IP-címe `172.16.5.4`, valamint a privát IP-címe `10.246.38.1`. Az otthoni LAN publikus IP-címe legyen most `192.168.1.12`, valamint a belső privát IP-címe pedig `10.0.0.5`.

Elsőre ez talán még nem teljesen érthető, ezért az ifconfig(8) parancs használatával is nézzük meg a példában szereplő hálózatok konfigurációját:

    Az első átjáró:

    gif0: flags=8051 mtu 1280
    tunnel inet 172.16.5.4 --> 192.168.1.12
    inet6 fe80::2e0::81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6
    inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00

    A második átjáró:

    gif0: flags=8051 mtu 1280
    tunnel inet 192.168.1.12 --> 172.16.5.4
    inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00
    inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4

Miután elvégeztük az iménti beállításokat, a ping(8) paranccsal már mind a két privát IP-tartománynak elérhetőnek kell lennie, ahogy azt az alábbi példa is érzékeltetni kívánja:

    otthoni-halo# ping 10.0.0.5
    PING 10.0.0.5 (10.0.0.5): 56 data bytes
    64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms
    64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms
    64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms
    64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms
    --- 10.0.0.5 ping statistics ---
    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms

    vallalati-halo# ping 10.246.38.1
    PING 10.246.38.1 (10.246.38.1): 56 data bytes
    64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms
    64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms
    64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms
    64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms
    64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms
    --- 10.246.38.1 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms

Az elvárásainknak megfelelően tehát a privát címeken mind a két oldalnak képesnek kell lennie ICMP csomagokat küldenie és fogadnia. A következő lépésben meg kell mondanunk az átjáróknak hogyan irányítsák a csomagokat a két hálózat közti forgalom megfelelő áramlásához. Ezt az alábbi paranccsal elérhetjük el:

    # vallalati-halo# route add 10.0.0.0 10.0.0.5 255.255.255.0

    # vallalati-halo# route add net 10.0.0.0: gateway 10.0.0.5

    # otthoni-halo# route add 10.246.38.0 10.246.38.1 255.255.255.0

    # otthoni-halo# route add host 10.246.38.0: gateway 10.246.38.1

Itt már a belső gépeket az átjárókról és az átjárók mögül egyaránt el tudjuk érni. A következő példa alapján erről könnyedén meg is tudunk győződni:

    vallalati-halo# ping 10.0.0.8
    PING 10.0.0.8 (10.0.0.8): 56 data bytes
    64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms
    64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms
    64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms
    64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms
    64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms
    --- 10.0.0.8 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms

    otthoni-halo# ping 10.246.38.107
    PING 10.246.38.1 (10.246.38.107): 56 data bytes
    64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms
    64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms
    64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms
    64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms
    64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms
    --- 10.246.38.107 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms

A tunnelek beállítása volt igazából a könnyebb rész, egy biztonságos összeköttetés kialakítása azonban már valamivel komolyabb folyamatot rejt magában. A most következő konfigurációban erre „előre ismert” (vagyis pre-shared, PSK) RSA-kulcsokat fogunk használni. A konkrét IP-címektől eltekintve az átjárókon a `/usr/local/etc/racoon/racoon.conf` állományok hasonlóan fognak kinézni, nagyjából valahogy így:

    path    pre_shared_key "/usr/local/etc/racoon/psk.txt"; # az ismert kulcsot tartalmazó állomány helye
    log     debug;	# a naplózás részletességének beállítása: ha végeztünk a teszteléssel és a hibakereséssel, akkor állítsuk át a 'notify' értékre

    padding  # ezeket ne nagyon változtassuk meg
    {
            maximum_length  20;
            randomize       off;
            strict_check    off;
            exclusive_tail  off;
    }

    timer	# időzítési beállítások, állítsuk be igény szerint
    {
            counter         5;
            interval        20 sec;
            persend         1;
    #       natt_keepalive  15 sec;
            phase1          30 sec;
            phase2          15 sec;
    }

    listen	# cím [port], ahol a racoon majd válaszolni fog
    {
            isakmp          172.16.5.4 [500];
            isakmp_natt     172.16.5.4 [4500];
    }

    remote  192.168.1.12 [500]
    {
            exchange_mode   main,aggressive;
            doi             ipsec_doi;
            situation       identity_only;
            my_identifier   address 172.16.5.4;
            peers_identifier        address 192.168.1.12;
            lifetime        time 8 hour;
            passive         off;
            proposal_check  obey;
    #       nat_traversal   off;
            generate_policy off;

                            proposal {
                                    encryption_algorithm    blowfish;
                                    hash_algorithm          md5;
                                    authentication_method   pre_shared_key;
                                    lifetime time           30 sec;
                                    dh_group                1;
                            }
    }

    sainfo  (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $hálózat/$hálózati_maszk $típus address $hálózat/$hálózati_maszk $típus
     		  # (a $típus lehet "any" vagy "esp")
    {		  # a $hálózat a két összekapcsolni kívánt belső hálózat legyen
            pfs_group       1;
            lifetime        time    36000 sec;
            encryption_algorithm    blowfish,3des,des;
            authentication_algorithm        hmac_md5,hmac_sha1;
            compression_algorithm   deflate;
    }

A példában szereplő összes opció részletes kifejtése jóval meghaladná ezen leírás kereteit, ezért a bővebb információkkal kapcsolatban inkább a racoon beállításaihoz tartozó man oldal elolvasását javasoljuk.

A gépek közti hálózati forgalom titkosításához be kell még állítanunk egy SPD házirendet is, így a FreeBSD és a racoon képes kódolni és dekódolni a csomagokat.

Ezt a most következő, a vállalati átjárón találhatóhoz hasonló egyszerű shell szkripttel tudjuk elvégezni. Ezt az állományt a rendszer indításakor fogjuk felhasználni, melyet `/usr/local/etc/racoon/setkey.conf` néven mentsünk el:

    flush;
    spdflush;
    # Az otthoni hálózati felé
    spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use;
    spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use;

Ahogy ezzel megvagyunk, a racoon az egyes átjárókon a következő paranccsal indítható el:

    # /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log

A parancs eredménye ennek megfelelően nagyjából a következő lesz:

    vallalati-halo# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf
    Foreground mode.
    2006-01-30 01:35:47: INFO: begin Identity Protection mode.
    2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon
    2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon
    2006-01-30 01:36:04: INFO: ISAKMP-SA established 72.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a
    2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 72.16.5.4[0]192.168.1.12[0]
    2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 92.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2)
    2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426)
    2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
    2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b)
    2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66)

A tunnel megfelelő működését úgy tudjuk ellenőrizni, ha átváltunk egy másik konzolra és a tcpdump(1) program segítségével figyeljük a hálózati forgalmat. A példában szereplő `em0` interfészt természetesen ne felejtsük el kicserélni a megfelelő eszköz nevére.

    # tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12

Ennek hatására az alábbiakhoz hasonló adatoknak kellene megjelennie a konzolon. Amennyiben nem ez történik, valamilyen hiba történt, ezért meg kell keresnünk azt a visszakapott adatok alapján.

    01:47:32.021683 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xa)
    01:47:33.022442 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xb)
    01:47:34.024218 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xc)

Itt már mind a két hálózatnak elérhetőnek kell lennie és egyként kell látszódnia. A hálózatokat ezen felül még érdemes külön védeni egy tűzfallal is. Ilyenkor a csomagok két hálózati közti zavartalan oda-vissza vándorlásához további szabályokat kell még felvennünk a tűzfal szabályrendszerébe. A ipfw(8) tűzfal esetén ez a következő sorok hozzáadását jelenti a tűzfal konfigurációs állományához:

    ipfw add 00201 allow log esp from any to any
    ipfw add 00202 allow log ah from any to any
    ipfw add 00203 allow log ipencap from any to any
    ipfw add 00204 allow log udp from any 500 to any

### Megjegyzés:

A szabályok számozását mindig az adott gép aktuális beállításainak megfelelően kell módosítani.

A pf(4) és ipf(8) felhasználók számára ehhez a következő parancsot javasoljuk:

    pass in quick proto esp from any to any
    pass in quick proto ah from any to any
    pass in quick proto ipencap from any to any
    pass in quick proto udp from any port = 500 to any port = 500
    pass in quick on gif0 from any to any
    pass out quick proto esp from any to any
    pass out quick proto ah from any to any
    pass out quick proto ipencap from any to any
    pass out quick proto udp from any port = 500 to any port = 500
    pass out quick on gif0 from any to any

Végezetül a következő sor hozzáadásával engedélyezzük az `/etc/rc.conf` állományban a VPN indítását a rendszer indítása során:

    ipsec_enable="YES"
    ipsec_program="/usr/local/sbin/setkey"
    ipsec_file="/usr/local/etc/racoon/setkey.conf" # engedélyezzük az spd házirend beállítását a rendszer indításakor
    racoon_enable="yes"

Vissza | Fel | Előre
14.9. OpenSSL | Főoldal | 14.11. OpenSSH

Ha kérdése van a FreeBSD-vel kapcsolatban, a következő címre írhat (angolul): <questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon: <gabor@FreeBSD.org>.