News & Blog

IPsec Site-to-Site VPN készítése

News & Blog

Amennyire divatos téma manapság a VPN-ek készítése, sokszor annyira nehéz feladatnak tartják annak konfigurálását. Próbáljuk meg most ennek a területnek az elméleti hátterét áttekinteni, eljutva egy konkrét konfigurációs példáig.


Nagyon sok cikk szól a VPN-ek konfigurálásáról, de sokszor csupán a szükséges konfigurációs parancsok felsorolása és kevéske magyarázaton kívül nem nagyon kapunk többet, ezekből pedig elég nehéz megérteni. Ebben a cikkben először az elméleti háttért tekintjük át, utána pedig megnézzük, hogy mi az a minimális konfiguráció, amellyel már működő site-to-site VPN készíthető. Kezdjük is el.

Miért is van szükségünk VPN-re: Nézzük meg ezt egy cég fejlődésén keresztül. Egy cég indulásakor általában valamennyi számítástechnikai eszköze elfért egy irodában, esetleg egy emeleten. Később aztán megvették az első irodaházukat, majd amikor már terjeszkedni is kezdtek, több különböző telephellyel is rendelkeztek, melyek akár különböző földrészeken is elhelyezkedhettek. Mégis, az az igénye megmaradt a cégnek, hogy ezeket a nagyon is elszórt hálózatokat egyetlen nagy hálózatként kezelhesse, melyek között az adataikat  megbízható módon forgalmazhassák. Korábban ennek érdekében a távközlési szolgáltatóktól rendelték meg azokat a kapcsolatokat (bérelt vonal, Frame Relay, stb.) melyekkel (a szolgáltatókban teljesen megbízva) megteremtették a távoli telephelyek közötti kapcsolatokat. Ez a megoldás viszont amellett hogy rugalmatlan, meglehetősen drága is volt.

Az Internet használatának rohamos elterjedése következtében felmerült az ötlet, mi lenne, ha magát az Internetet használnánk föl a telephelyek összekapcsolására. (Természetesen így minden telephelynek internetes kapcsolattal kell rendelkeznie.) Ez lényegesen olcsóbb, de még megbízhatatlanabb módszer, hiszen az adatok az Internet hálózatán keresztül, teljesen megbízhatatlan módon, számunkra ismeretlen szolgáltatókon és útvonalakon keresztül haladnak.

Az Internet alapját képező TCP/IP protokollcsalád tervezésekor még nem gondoltak a biztonságra, az adatok gyakorlatilag bárki számára hozzáférhetően voltak továbbítva. Hamar felmerült az igény a biztonság növelésére, melynek több területen kellett megvalósulnia:

  • Titkosítással biztosítani kellett az adatok bizalmi jellegét, tehát illetéktelenek, ha meg is tudták szerezni, ne tudják értelmezni.
  • Meg kellett arról győződni, hogy az adatokat az küldi, akitől várjuk, tehát ne lehessen más nevében adatokat feladni. Ez gyakorlatilag a küldő fél azonosítását (hitelesítését) jelenti.
  • Biztosítani kellett, hogy a feladó által küldött adatok menet közben nem változtak meg. Ezt az adatcsomag integritásának nevezzük, melyet szintén a hitelesítés biztosít.
  • Amennyiben egy adat sikeresen megérkezett, ne tudja másvalaki ezt a forgalmat lemásolva újra elküldeni. Ez a visszajátszás elleni védelem.
  • Meg kell akadályozni, hogy egy harmadik fél megállapítsa, ki-kivel kommunikál.

Ezeknek a szempontoknak való megfeleléshez több protokollt és technológiát is kidolgoztak, melyek a hálózat különböző szintjein működnek, és a fenti feltételekből többet-kevesebbet valósítanak meg. A jelenlegi cikk közülük a hálózati rétegben működő IPsec biztonsági architektúrát mutatja be röviden.

Az IPsec nem egy protokoll, hanem gyakorlatilag egy olyan keretrendszer, mely több protokoll együttműködését írja le a fenti biztonsági szempontok megvalósítására. (És éppen ebből adódik az, hogy a konfigurációja olyan sokrétű lehet.) A legnagyobb előnye az, hogy amennyiben a későbbiek során valamelyik protokollban valamilyen sebezhetőséget találnak, könnyen ki lehet cserélni másikra. Az IPsec sokrétűségét mutatja, hogy több mint 30 RFC-ben megfogalmazott szabvány vonatkozik rá.

Az IPsec használatakor meg kell határoznunk azoknak a protokolloknak a készletét, amelyek az adott kommunikáló eszközön működni fognak. És mivel a kommunikációhoz két fél (a forrás és a cél) kell, a másik eszközön is ugyanezt a protokollkészletet kell használni. Külön feladat lesz ezeknek a protokollkészleteknek az egyeztetése. 

Az IPsec-et IPv4-es és IPv6-os hálózatokra is kidolgozták. IPv4 implementáció esetén megvalósítása opcionális, míg IPv6 esetén erősen ajánlott. (Ez nem azt jelenti, hogy minden IPv6-os hálózatban konfigurálnunk kell, hanem azt, hogy ha akarjuk, akkor konfigurálhatjuk, mert nagy valószínűséggel megvan rá a lehetőség.) Sok dokumentációban azt olvashatjuk, hogy az IPv6 implementációk köztelező része az IPsec, de ezt az RFC 6434 erősen ajánlottá módosította.

Az IPsec a fenti biztonsági területek közül a visszajátszási védelmét csak korlátozottan valósítja meg, mivel a hálózati rétegben (IP) működik, és mivel az IP egy kapcsolat nélküli protokoll, így a felsőbb rétegek tudják teljes körűen biztosítani ezt a biztonsági funkciót.

Mielőtt az IPsec működését megvizsgáljuk, tisztázzuk a VPN fogalmát.

A virtuális magánhálózatok (VPN)

A VPN gyakorlatilag egy olyan hálózat, amelyet az Internet felett építünk ki, vagyis az adatok szállításához az Internet infrastruktúráját használják, de úgy, hogy a kommunikáló eszközök számára úgy tűnik, mintha közvetlen kapcsolatban lennének egymással. Az Interneten ezek a szállított adatok általában nem láthatók, mivel a VPN-t felépítő eszközök titkosítják azokat. (Ez adja a hálózat privát jellegét, bár meg kell mondani, hogy némelyik VPN megoldás nem valósítja meg ezt a bizalmas jelleget, vagyis nem titkosít. Ilyen pl. a GRE.) A VPN tehát nem egy internetelérés, használatához rendelkeznünk kell egy működő internet kapcsolattal.

A VPN-eknek több fajtája létezik, mi most az úgynevezett Site-to-Site VPN-nel ismerkedünk meg, amely két távoli hálózatot köt össze az interneten keresztül. Gyakorlatilag egy alagutat hoz létre a forgalomirányítók között, melyben az adatok titkosítva haladnak. A forgalomirányítók két legfontosabb feladata az adatok titkosítása (kódolása) és egymás hitelesítése. VPN-t nem csak az IPsec segítségével tudunk létrehozni, de mi most ezt a megvalósítást vizsgáljuk meg.

vpn_01

Az IPSEC működési módjai

Az IPsec kétféle módban tud működni. Az első módjában a két kommunikáló végpont között teremt kapcsolatot, ilyenkor transzport (szállítási) módról beszélünk. A másodikban a kommunikáló végpontok átjárókon keresztül érik el egymást, ilyenkor alagút (tunnel) módban működik az IPsec. Mivel mi Site-to-Site VPN-t építünk vele, vagyis a két hálózat mindegyik eszköze akar egymással kommunikálni, értelemszerűen a forgalomirányítóikon keresztül kommunikálnak egymással, így az alagút módra van szükségünk. 

Pár szó a titkosításról

Mint láthattuk, a forgalomirányítók egyik fő feladata a titkosítás. A titkosítás (kódolás) a kriptográfia témakörébe tartozik, és gyakorlatilag annyi a feladata, hogy az információt (melyet nyílt szövegnek is nevezünk) egy megfelelő titkosítási algoritmus segítségével olyan adatsorozattá alakítja, amely értelmezhetetlen minden olyan ember számára, akik nem rendelkeznek a megfejtéséhez (dekódolásához) szükséges kulccsal. Magához a titkosításhoz is szükség van egy kulcsra, mely vagy azonos a dekódolóéval, vagy abból származik. Az egészet úgy kell elképzelni, hogy mint amikor valamit bezárunk egy dobozba. A bezáráshoz (titkosítás, kódolás) is szükség van egy kulcsra, míg a kinyitásához (megfejtés, dekódolás) is. Szimmetrikus titkosításról beszélünk, ha ugyanazzal a kulccsal titkosítunk, mint amelyikkel megfejtünk, míg aszimmetrikus titkosításról, ha a titkosításhoz és megfejtéshez különböző kulcsokat használunk. A szimmetrikus titkosítás kevesebb erőforrást igényel, mint az aszimmetrikus, és gyorsabb is annál, de gondot okoz a kulcsának a biztonságos megosztása, míg az aszimmetrikus titkosításnál ez nem gond. (Hiszen aszimmetrikus titkosításnál csak a titkosítást végző kulcsot kell megosztanunk, a megfejtést végző nem kerül ki az adatforgalomba.) Az aszimmetrikus titkosítás egyik megvalósítása a nyilvános kulcsú titkosítás. Az IPsec-ben használt protokollok a szimmetrikus és az aszimmetrikus titkosítást is használják.

Mivel a kódoló és dekódoló félnek is rendelkeznie kell kulcsokkal, külön feladat azoknak az elkészítése és eljuttatása az egyes felekhez úgy, hogy mások azt ne szerezhessék meg. 

Az IPsec által leggyakrabban használt titkosító algoritmusok a DES, a 3DES és az AES.

Pár szó a hitelesítésről

Amikor valaki kap egy üzenetet két dologról szeretne mindenképpen megbizonyosodni. Az első az, hogy biztos attól kapta-e az üzenetet, akinek tulajdonítja, míg a másik, hogy az üzenet pontosan az-e, amit a feladó küldött, tehát nem változott meg (akár véletlenül, akár szándékosan) útközben. (A magyar nyelv jól fejezi ki ez utóbbit a “hiteles másolat” kifejezéssel.) Ezt a két feladatot látja el a hitelesítés.

A hitelesítéshez, akár csak a titkosításhoz egy algoritmusra és egy kulcsra van szükség. Az algoritmust hash függvénynek is hívjuk. Az üzenetet küldő eszközön az algoritmus a kulcs felhasználásával kiszámol egy kivonatot az üzenetből, és hozzá csatolja. (Ennek a kivonatnak a neve a Message Authentication CodeMAC.) A fogadó eszköz miután megkapta az üzenetet a kivonattal együtt, szintén kiszámolja a kulcs és az üzenet ismeretében ezt a kivonatot, és összehasonlítja a fogadottal. Ha egyeznek, akkor az üzenet hitelesítése sikerült, ha nem egyeznek, akkor nem sikerült. (Végül is ez nagyon hasonlít a memóriák paritásvizsgálatára, vagy az Ethernet keretek FCS mezőjére, csak azoknál nem kellett kulcsot használni, és azok az üzenet integritását ellenőrizték csak.) Ezzel a módszerrel elértük, hogy látjuk, olyan eszköz küldte az üzenetet, aki ugyanazzal a kulccsal rendelkezik, amelyikkel mi (amennyiben szimmetrikusat használ), és az üzenet tartalma (integritása) sem változott meg.

Az IPsec által a leggyakrabban használt hitelesítő algoritmusok az MD5 és az SHA.

Pár szó a kulcsokról

Mint olvashattuk, mind a titkosításhoz, mind a hitelesítéshez szükségünk van kulcsokra. Ezeket a kulcsokat elő kell állítani, és meg kell osztani a kommunikáló eszközök között. A megfejtéshez szükséges kulcsokra nagyon kell vigyázni, hiszen birtokukban a titkosított üzenet visszafejthető, tehát a kulcsok megosztását is biztonságos körülmények között kell megoldanunk. De akkor hogy van ez? Ahhoz, hogy biztonságos körülményeket teremtsünk, ahhoz kellenek a kulcsok, tehát már a kulcsok elosztásához is kellenének kulcsok. De akkor azokat hogyan osszuk meg biztonságosan?

Szimmetrikus titkosítás esetén, mivel egyetlen kulccsal rendelkezünk, ezt a kulcsot valamilyen megbízható csatornán keresztül kell megosztania a két kommunikáló félnek egymással. Például felhívjuk a másik felet, és belesuttogjuk a telefonba a kulcsot, reménykedve, hogy senki nem hallgatja le közben. Persze jobb lenne ténylegesen megbízható, vagyis titkosított csatornát használni, de akkor jön az előbb említett probléma, milyen kulccsal titkosítsuk le ezt a csatornát?

Erre ad megoldást a nyilvános kulcsú titkosítás, amely az előzőekben elmondottak szerint más kulcsot (a nyilvánosat) használ az üzenet titkosítására, és más kulcsot (a titkosat) használ a titkosított üzenet megfejtésére. Ilyenkor aki előállítja a kulcspárt (nyilvános és titkos kulcs), a titkos kulcsára nagyon vigyáz, senkinek nem adja meg, a nyilvános kulcsát viszont világgá kürtöli, hogy tessék, ezzel titkosítva lehet nekem rejtjeles üzenetet küldeni. Ez csak első ránézésre bonyolult. Gondoljunk az email-re! Ha email-t küldünk valakinek, akkor ehhez a címzett email címét használjuk. Ha a levelet titkosítva szeretnénk neki elküldeni, akkor elkérjük a címzett nyilvános kulcsát is, és azzal titkosítunk. Amikor megkapja a nyilvános kulcsával titkosított levelet, akkor majd az ehhez a nyilvános kulcshoz tartozó titkos kulcsával fejti meg. A titkos és a nyilvános kulcs szorosan összetartozik, egyszerre generálják azokat, az egyikből a másik nem következtethető ki. A titkos kulcs tehát nem titkosít, hanem megfejt ebben az összefüggésben, bár a szerepeik felcserélhetők. (Természetesen az is megoldandó feladat, hogy meggyőződjünk arról, a nyilvános kulcs tényleg azé-e akinek gondoljuk, mint ahogyan az email címről is jó tudni, hogy a címzetthez tartozik-e, vagy sem. Ez a probléma elvezetne minket a megbízhatósági láncok, elektronikus aláírás és tanúsítványok világába, de ennek a cikknek most nem ez a célja.)

A kulcsok előállítása külön tudomány. Az alapja relatív prímek és olyan véletlen számok, melyek csakugyan véletlenek. Ilyet számítógépes algoritmusok nem nagyon tudnak előállítani (azok pszeudo-véletlen számokat generálnak), ehhez fizikai folyamatok kellenek. (Például 100 lávalámpa másodpercenként 1000x lefényképezett éppen aktuális fényéből generálnak véletlen számot, vagy a kulcsgeneráló program megkéri, hogy mozgassuk már egy kicsit az egeret össze-vissza az asztalon, mert abból próbál véletlenszerű adatokat gyűjteni.)

De hogyan is juttatjuk el a kulcsokat az egyes eszközökhöz? (Itt most a szimmetrikus kulcs eljuttatása a kérdés, hiszen az aszimmetrikus kulcsoknál a nyilvános kulcs eljuttatását nem kell titkosan kezelni, a titkos kulcsot meg nem kell eljuttatni, arra csak nagyon kell vigyáznunk.)

Az egyik megoldás az, amikor mi magunk megyünk el az eszközökhöz személyesen (vagy valamilyen távoli kapcsolaton keresztül), és gyakorlatilag begépeljük, közben vigyázunk arra, nehogy valaki meglessen minket. (Se személyesen, se egy billentyűzet figyelő vagy hálózat monitorozó programon keresztül.) Ezt nevezzük manuális kulcskezelésnek, melyet ugyan támogat az IPsec, de nagyszámú eszköz esetén nehezen kivitelezhető, hiszen az eszközök páronként használják a kulcsokat. (Ha például van 10 eszközünk, akkor 10×9/2=45 kulcs karbantartásáról kellene gondoskodnunk.)

A másik megoldás az automatizált kulcskezelés, amikor egy protokollra bízzuk rá a kulcsok megbízható kiosztását. Ezek a protokollok megbízható csatornát kialakítva (mint említettük, ezekhez is kellenek kulcsok) osztják meg az eszközök között a kulcsokat.

A kulcsokat időnként cserélni kell. Vagy azért, mert korrumpálódtak (vagyis valaki megszerezte azokat), vagy azért, mert a biztonsági házirend előírja. Egy kulcs minél tovább él, annál nagyobb a valószínűsége annak, hogy sikerül feltörni. (Ha egy kulcsot 2 hét alatt lehet feltörni, akkor hetente lecserélve már neki sem érdemes kezdeni.) Manuális esetben ez a csere nagyon sok munkát jelent, az automatikus kiosztás ezt is megoldja. Sőt, egy kommunikációs folyamat közben is cserélgetik a kulcsokat, hogy még nehezebben lehessen megfejteni azt.

Az automatikus kulcscserét az IPsec-ben az IKE (Internet Key Exchange) protokoll végzi, mely felhasználja az ISAKMP (Internet Security Association and Key Management Protocol) keretrendszert, a Diffie-Helmann kulcscsere protokollt, az Oekley Key Determination Protocol-t  és a SKEME (Secure Key Exchange Mechanism) kulcscsere módszert.

Ennyi bevezető után térjünk rá, hogyan is működik a VPN központi elemét alkotó IPSec.

Az IPsec protokolljai

Az IPsec a fentebb bemutatott funkciókat három protokoll használatával valósítja meg:

  • AH (Authentication headers)
  • ESP (Encapsulating Security Payloads)
  • SA (Security Associations)

Természetesen ezek a protokollok számos más protokollt használnak fel működésük során, emlékezzünk csak a több mint 30 RFC-re. Vizsgáljuk meg ezeket a protokollokat röviden:

Az AH protokoll (Authentication Headers)

Az AH protokoll segítségével az IPsec ellenőrizni képes adatcsomagok integritását, hitelesíteni tudja a küldő felet, és félig-meddig visszajátszás elleni védelmet is nyújt. Legnagyobb hátránya viszont az, hogy nem titkosít. Az AH támogatja mind a transzport, mind az alagút módot. Az eredeti IP csomagot egy új AH fejléccel egészíti ki, melyben azokat a paramétereket helyezi el, melyekkel megvalósítja a biztonsági funkcióit. Nézzük meg a különböző módokban az új IP csomag szerkezetét:

vpn 02

Jól látszik, hogy alagút módban az IP csomagra új IP fejléc kerül. Ez nem meglepő, hiszen a forgalomirányítók a saját maguk nevében továbbítják az eredeti csomagot. Szállítási módban ez nem történik meg. Az AH fejléc az egész csomagot védi (a címinformációkkal együtt). Ez a védelem nem titkosítás (hiszen az AH nem titkosít), hanem integritásvédelem. (Az IP fejlécben természetesen megengedi azoknak a mezőknek a menet közbeni változását, amelyeket útközben a forgalomirányítók módosíthatnak. Ilyen például IPv4 esetén a TTL mező.) Az ábrán szereplő TCP és UDP protokollokon kívül természetesen bármilyen más IP feletti protokollt is képes szállítani.

Az ESP protokoll (Encapsulating Security Payloads)

Az ESP protokoll az AH-val szemben már képes a titkosításra is. Rendelkezik a hitelesítés képességével is, amit vagy használunk vagy nem. (Ha nem, akkor az AH-t használhatjuk helyette.) Nem csak ESP fejléccel, hanem ESP lábléccel is ellátja a csomagot, sőt ha a hitelesítési funkcióját is használjuk, akkor egy ESP hitelesítési láblécet is használ az ábrának megfelelően:

vpn 03

Alagút módban látható itt is, hogy új IP fejléccel lesz ellátva a csomag, amelyet se nem hitelesít, se nem titkosít a protokoll, de az eredeti teljes IP csomag mind hitelesítve, mind titkosítva lesz. Transzport módban viszont az eredeti csomagból csak a payload (a szegmens) lesz hitelesítve és titkosítva. (Ilyenkor ha az IP fejlécet is titkosítanák, akkor a forgalomirányítók nem tudnák kiolvasni belőle az továbbításhoz szükséges információkat.)

A biztonsági összerendelés (SA, Security Associations)

Összefoglalva a fentieket, három fő feladatot kell elvégeznie az IPsec-nek, a titkosítást, a hitelesítést és a kulcsok kezelését. Ezeket ráadásul többféle protokollal is képes megvalósítani, így az, hogy melyik eszközön ezt hogyan teszi meg, az eszközönként más és más lehet. De két egymással kommunikáló eszközön természetesen azonos módon kell működnie, hiszen ha az egyik például 3DES-sel titkosít, MD5-tel hitelesít, és IKE-vel kezeli a kulcsokat, míg a másik ezt az AES, SHA és IKE-vel teszi, kicsi a valószínűsége, hogy megértik egymást. (De ha például mindketten a 3DES titkosítást használja, de más-más paraméterekkel, akkor sem tudnak megegyezni a titkosításban.)

A biztonsági összerendelésben állapodik meg a két kommunikáló fél a titkosítási és hitelesítési algoritmusban, a kulcsokban, a kulcskezelés módjában, és számos más, a kommunikációt befolyásoló paraméterben. Az IPsec biztonsági összerendelés protokollja az SA (Security Associations).

A biztonsági összerendelés (vagyis az SA) két fázisból áll. Az első fázisban a két fél hitelesíti egymást, majd létrehoz egy biztonságos csatornát, melyen az SA a további paramétereit egyeztetik. Ez a hitelesítés vagy előre kiosztott kulcsokkal, vagy nyilvános kulcsú titkosítással történhet. Ennek a cikknek a kereteit meghaladja a nyilvános kulcsú technikák bemutatása, így a konkrét példában az előre kiosztott kulcsokat fogjuk használni. A második fázisban történik a titkosítási és hitelesítési protokollok paramétereinek és kulcsainak az egyeztetése. (Vagyis az, hogy majd a felhasználói adatforgalmat hogyan kell titkosítani és hitelesíteni.) Fontos, hogy sem az 1., sem a 2. fázisban sincsen még szó a felhasználói forgalom átviteléről! Az 1. fázis a 2. fázis számára készít egy biztonságos csatornát. Láthatjuk, hogy mindkét fázisban van hitelesítés és titkosítás. Az első fázis hitelesítése a VPN-t kiépítő eszközöket hitelesíti, és az SA 2. fázisban forgalmazott egyeztető üzeneteit titkosítja. A  2. fázisban azt beszélik meg a forgalomirányítók, hogy a felhasználói forgalmat mi módon hitelesítsék és titkosítsák.

Amikor a két fél között az SA kiépíti a kapcsolatot, akkor az AH és az ESP fejléceiben elhelyezésre kerül a kapcsolat azonosítója (az SPISecurity Parameter Index mezőben), így minden csomagról tudható, hogy ehhez a kapcsolathoz tartozik, vagy nem.

Ha nyomon szeretnénk követni az IKE működését, érdemes tudni, hogy UDP protokollt használ az 500-as porttal.

Site-to-Site VPN konfigurálása

Ennyi elméleti bevezető után térjünk át arra, hogy egy konkrét példán keresztül konfiguráljunk egy Site-to-Site VPN-t. A konfiguráció során sokszor az alapértelmezett beállításokat használjuk annak érdekében, hogy minél egyszerűbb legyen. R1 és R2 között építjük ki a IPsec VPN kapcsolatot alagút módban, a forgalomirányítók mögötti hálózatot a loopback interfészekkel szimuláljuk, a távoli hálózatok között statikus forgalomirányítást állítunk be.

vpn 04

Elsőként konfiguráljuk az interfészek IP címeit, és a statikus forgalomirányítást:

R1#conf t
R1(config)#int lo0
R1(config-if)#ip add 192.168.1.1 255.255.255.0
R1(config-if)#int fa0/0
R1(config-if)#ip add 10.0.0.1 255.0.0.0
R1(config-if)#no sh
R1(config-if)#ip route 192.168.2.0 255.255.255.0 10.0.0.2

R2#conf t
R2(config)#int lo0
R2(config-if)#ip add 192.168.2.1 255.255.255.0
R2(config-if)#int fa0/0
R2(config-if)#ip add 10.0.0.2 255.0.0.0
R2(config-if)#no sh
R2(config-if)#ip route 192.168.1.0 255.255.255.0 10.0.0.1

Most jön a lényegi rész, konfiguráljuk az IPsec VPN-t. Ezt 5 lépésben tesszük meg:

  1. Az IKE 1. fázisához létrehozunk egy ISAKMP házirendet (ISAKMP policy).
  2. Az IKE 2. fázisához létrehozunk egy transzformációs készletet (Transform Set).
  3. Létrehozunk egy ACL-t, mely arra a forgalomra illeszkedik, melyet az alagúton át akarunk vezetni.
  4. Az előzőeket összefoglaljuk egy Crypto Map-ben.
  5. A Crypto Map-et alkalmazzuk a megfelelő interfészre.

 1. lépés: IKE 1. fázis: az ISAKMP házirend (policy) konfigurálása

Emlékezzünk vissza, az ISAKMP az a protkoll, amely a kulcscserét támogatja az IKE folyamatában. Az IKE az 1. fázisában hitelesíti az IPsec-ben résztvevő eszközöket (vagyis a két forgalomirányítót), és kialakít egy biztonságos csatornát a 2. fázis számára. A forgalomirányítók a következő paraméterekben állapodnak meg:

  • Titkosítási algoritmus (DES, 3DES vagy AES, alapértelmezett a DES)
  • Hitelesítési algoritmus (MD5 vagy SHA-1, alapértelmezett az SHA-1)
  • Diffie-Hellmann (DH) csoport (A Diffie-Hellmann kulcscsere protokoll által használt paraméterek, alapértelmezett az 1-es csoport)
  • Előre megosztott kulcsok vagy RSA/DSA tanúsítványok használata

Az ISAKMP házirend konfigurálásakor gyakorlatilag ezeket a paramétereket állítja be. Természetesen mindkét forgalomirányítón egyező házirendeket kell készítenünk. Érdekesség, hogy nem csak egyetlen házirend készíthető, hanem több is. Mindegyiknél definiálunk egy prioritást, és az egyeztetés során ezeken lépkednek végig az eszközök, a legmagasabb prioritástól kezdve. (Az alacsonyabb szám nagyobb prioritást jelent.) Mi most csak egyetlen, 10-es prioritásút készítünk.

Mielőtt konfigurálnánk, nézzük meg, hogy alapértelmezetten milyen beállításokkal rendelkezik. Ehhez használjuk a show crypto isakmp policy parancsot:

R1#sh crypto isakmp policy
Global IKE policy
Default protection suite
        encryption algorithm:   DES – Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit

Mint látjuk, alapértelmezetten a DES titkosítást, az RSA (nyilvános kulcsú) hitelesítési módszert, az SHA hash algoritmust és az 1-es Diffie-Hellman csoportot használja. A lifetime idő az SA élettartamát határozza meg, alapértelmezetten 24 óra. Utána új egyeztetés kezdődik. A két kommunikáló eszközön (melyek között létrejön az SA) a policy minden paramétere meg kell egyezzen, kivéve a lifetime. Különböző értékű lifetime esetén a rövidebbet használja. Mivel mi előre megosztott kulcsokkal szeretnénk a hitelesítést elvégezni, ezért amennyiben a többi paramétert alapértelmezett értéken hagyjuk, csupán ezeket kell konfigurálni.

R1#conf t
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#exit
R1(config)#crypto isakmp key jelszo address 10.0.0.2

 crypto isakmp policy 10 Létrehozza a 10-es prioritású házirendet.
 authentication pre-share Előírjuk az előre megosztott kulcsú hitelesítést.
 crypto isakmp key jelszo address 10.0.0.2     Definiáljuk a megosztott kulcsot és a távoli peert.

Természetesen ezt a konfigurációt R2-n is meg kell tenni azzal a különbséggel, hogy a kulcs definiálásakor R1 IP címét adjuk meg.

R2#conf t
R2(config)#crypto isakmp policy 10
R2(config-isakmp)#authentication pre-share
R2(config-isakmp)#exit
R2(config)#crypto isakmp key jelszo address 10.0.0.1

Mivel most az a célunk, hogy a legegyszerűbb konfigurációhoz jussunk el, így az IKE 1. fázisának konfigurációját ezzel az alapkonfigurációval fejezzük be. Persze a további konfiguráció sem lenne túl bonyolult. Ha például a hitelesítéshez az MD5-öt, míg titkosításhoz a 3DES-t szertnénk használni, mellette az 5-ös Difife-Hellmann csoportot, és a lifetime pedig 3600 másodpercre akarjuk állítani, akkor a következőképpen kellene eljárnunk:

R1#conf t
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#hash md5
R1(config-isakmp)#encryption 3des
R1(config-isakmp)#group 5
R1(config-isakmp)#lifetime 3600

Természetesen ezt az R2-n is ugyanígy meg kellene tenni.

Az IKE 1. fázisát kétféle módon tudja a protokoll végrehajtani. Main módban 3 üzenetcserét alkalmaz (titkosított csatorna létrehozására, Diffie-Hellmann kulcscsere, és egymás hitelesítése), míg agresszív módban gyorsabban, kevesebb üzenetváltással zajlik le ez a fázis azzal a hátránnyal, hogy nem minden üzenet megy titkosított csatornán. (Távoli hozzáférés használata esetén még további két móddal egészül ez ki, a hibrid (hybrid) és az irodai (office) móddal.)

2. lépés: IKE 2. fázis: Transzformációs készlet (Transform Set) konfigurálása

A 2. fázis már nem a forgalomirányítókról, hanem a forgalomról szól. Gyors (quick) módnak vagy IPsec fázisnak is nevezik. Arról szól, hogyan lesz majd hitelesítve és titkosítva a forgalomirányítók által továbbított forgalom. Ennek leírására létrehozunk egy transzformációs készletet. A készletet névvel azonosítjuk. Egy ilyen készlet egy, kettő vagy három transzformációt írhat le. Mindegyik transzformáció az IPsec egy protokollját (EPS vagy AH), annak algoritmusát és esetleges paramétereit tartalmazza. Kérdezzük le lehetséges protokollkombinációkat:

R1(config)#crypto ipsec transform-set TSETR1 ?
  ah-md5-hmac   AH-HMAC-MD5 transform
  ah-sha-hmac   AH-HMAC-SHA transform
  comp-lzs      IP Compression using the LZS compression algorithm
  esp-3des      ESP transform using 3DES(EDE) cipher (168 bits)
  esp-aes       ESP transform using AES cipher
  esp-des       ESP transform using DES cipher (56 bits)
  esp-md5-hmac  ESP transform using HMAC-MD5 auth
  esp-null      ESP transform w/o cipher
  esp-sha-hmac  ESP transform using HMAC-SHA auth

 Válasszuk ki most az esp-aes titkosítást, és nézzük meg a további lehetőségeket:

R1(config)#crypto ipsec transform-set TSETR1 esp-aes ?
  128           128 bit keys.
  192           192 bit keys.
  256           256 bit keys.
  ah-md5-hmac   AH-HMAC-MD5 transform
  ah-sha-hmac   AH-HMAC-SHA transform
  comp-lzs      IP Compression using the LZS compression algorithm
  esp-md5-hmac  ESP transform using HMAC-MD5 auth
  esp-sha-hmac  ESP transform using HMAC-SHA auth

Mi most a 256 bites kulcs használatát írjuk elő a transzformációban. Írjuk elő még a esp-md5-hmac hitelesítést. Végezetül a transzformációs készletben adjuk meg, hogy az IPsec melyik módját használjuk. Természetesen mindkét forgalomirányítón létre kell hozni ugyanazokkal a paraméterekkel a készleteket. (Több készlet is létrehozható forgalomirányítónként, és majd kiválasztják az egyezőket.) 

R1(config)#crypto ipsec transform-set TSETR1 esp-aes 256 esp-md5-hmac
R1(cfg-crypto-trans)#mode tunnel

R2(config)#crypto ipsec transform-set TSETR2 esp-aes 256 esp-md5-hmac
R2(cfg-crypto-trans)#mode tunnel

A definiált transzformációs készlet bármikor lekérdezhető:

R1#sh crypto ipsec transform-set 
Transform set TSETR1: { esp-256-aes  } 
   will negotiate = { Tunnel,  },

3. lépés: A titkosítandó forgalomra illeszkedő ACL létrehozása

A konfiguráció ezen lépése nagyon egyszerű. Definiálnunk kell azt a kiterjesztett ACL-t, amelyik arra a forgalomra illeszkedik, amelyet a forgalomirányítóknak titkosítva kell továbbítania. Ez a konfiguráció magyarázatot nem igényel.

R1(config)#access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

R2(config)#access-list 101 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

4. lépés: Az előzőekben konfiguráltak egymáshoz rendelése

Most, hogy elkészítettük a házirendet, a transzformációs készletet és a hozzáférési listát, rendeljük azokat egymáshoz. Ehhez egy ún. crypto map-et hozunk létre, melyet névvel azonosítunk. Nézzük az egyes (egyértelmű) konfigurációs lépéseket, és a magyarázatukat:

R1(config)#crypto map R1-R2 10 ipsec-isakmp
R1(config-crypto-map)#set peer 10.0.0.2
R1(config-crypto-map)#match address 101
R1(config-crypto-map)#set transform-set TSETR1

 crypto map R1-R2 10 ipsec-isakmp Létrehozza a crypto map-et a R1-R2 néven a 10-es sorszámmal
 set peer 10.0.0.2 Az alagút másik végén lévő forgalomirányító kijelölése
 match address 101    
 A titkosítsandó forgalomra illeszkedő hozzáférési lista azonosítása
 set transform-set TSETR1    
 A forgalom titkosítását definiáló transzformációs készlet azonosítása

Majd R2-n is ugyanezt tesszük:

R2(config)#crypto map R2-R1 10 ipsec-isakmp
R2(config-crypto-map)#set peer 10.0.0.1
R2(config-crypto-map)#match address 101
R2(config-crypto-map)#set transform-set TSETR2

5. lépés: A Crypto Map alkalmazása a kimenő interfészre

Az utolsó lépés nagyon egyszerű, az előzőekben definiált Crypto Map-et a kimenő interfészhez rendeljük:

R1(config)#int fa0/0
R1(config-if)#crypto map R1-R2

R2(config)#int fa0/0
R2(config-if)#crypto map R2-R1

Érdemes tudni, hogy a VPN még nem épült fel, noha minden konfigurációs lépést megtettünk. Ennnek az az oka, hogy a VPN kiépítését az első olyan forgalom indítja el, amelyre illeszkedik a 101-es ACL. (Emiatt a forgalom első pár csomagja el is veszik!)

Teszteljük le a hálózatot egy egyszerű ping paranccsal. (A VPN kiépítése miatt kieső csomagoktól itt most eltekintünk.) A forgalmat mentsük le, és próbáljuk visszafejteni. Először R1-ről pingessük meg R2-t simán (ping 10.0.0.2): A lementett forgalom:

vpn 05

Azt látjuk, hogy felismerhető az ICMP protokoll, semmi titkosítás nem történik. Persze, hiszen csak a 192.168.1.0/24 és a 192.168.2.0/24 hálózatok közötti forgalmat vezetjük át a VPN-en. Pingessük meg most R1-ről R2 loopback interfészét. (ping 192.168.2.1)

vpn 06

Megint nem látunk semmi különöset. Ennek is az előző az indoka, hiszen a 10.0.0.0/8 és 192.168.2.0/24 hálózatok közötti forgalmat sem titikosítjuk. Pingessük meg most R1 192.168.1.1-es címéről az R2 mögötti 192.168.2.1-es címet. (Használjuk a kiterjesztett ping parancsot)

vpn 07

És működik! Nem ismerhető fel a forgalomirányítók mögötti hálózatokból küldött protokoll, elfedte az IP címeket, és az ESP protokollt használva teremti meg a kapcsolatot a VPN alagút két végével. Nézzük meg, hogy mind a két irányú forgalomhoz kiépült egy-egy SA, melyeket az SPI index azonosít. Jól látható, hogy minden azonos irányba haladó csomag ugyanahhoz az SA példányhoz tartozik, ezért azonos az SPI-je.

Töröljük az SA-t:

R1()#clear crypto sa

Adjuk ki az előző ping parancsot, miközben mentjük a forgalmat. (Szűrjük az ISAKMP-re.) Ne lepődjünk meg, hogy az első pár ping nem sikerül, idő kell, amíg az SA kiépül.

vpn 08

Jól látható, ahogyan az ISAKMP kiépíti az SA-t. (Látható, hogy UDP-t használ az 500-as porttal.) Adjuk ismét a ping parancsot.

vpn 09

Ismét láthatjuk a forgalmat titkosítva, de már más SPI indexek azonosítják az újraépült SA-t.

Számos parancsunk van, amellyel az IPsec működését leellenőrizhetjük.

Korábban már láttuk, hogy a kulcscseréről  a show crypto isakmp policy paranccsal jeleníthetünk meg információt. Ha például az SA-ról szeretnénk információt megjeleníteni, használhatjuk a show crypto ipsec sa address parancsot:

R1#sh crypto ipsec sa address
vrf/address: /10.0.0.1
   protocol: ESP
      spi: 0x3AD2A003(986882051)
        transform: esp-256-aes ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: R1-R2
        sa timing: remaining key lifetime (k/sec): (4553624/867)
        IV size: 16 bytes
        replay detection support: N

vrf/address: /10.0.0.2
   protocol: ESP
      spi: 0x4DBC5388(1304187784)
        transform: esp-256-aes ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: R1-R2
        sa timing: remaining key lifetime (k/sec): (4553624/867)
        IV size: 16 bytes
        replay detection support: N

Szemezgessünk nyugodtan a parancs kimenetéből. Kiolvashatjuk a titkosításhoz használt protokollt, az IPsec módját, a kialakult munkameneteket (hasonlítsuk össze a lementett forgalomban található SPI indexszel). A transzformációs készletünket a show crypto ipsec transform-set paranccsal nézhetjük meg:

R1#sh crypto ipsec transform-set        
Transform set TSETR1: { esp-256-aes  } 
   will negotiate = { Tunnel,  },

A teljes Crypto Map-ről a sh crypto map paranccsal írhatunk ki információkat:

R1#sh crypto map
Crypto Map “R1-R2” 10 ipsec-isakmp
        Peer = 10.0.0.2
        Extended IP access list 101
            access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
        Current peer: 10.0.0.2
        Security association lifetime: 4608000 kilobytes/3600 seconds
        PFS (Y/N): N
        Transform sets={ 
                TSETR1, 
        }
        Interfaces using crypto map R1-R2:
                FastEthernet0/0

És készen is vagyunk. Remélem az elméleti háttér bemutatásával az egyes konfigurációs lépések már érthetők. Ne felejtsük el, ha bármit változtatunk a konfiguráción, az IPsec alagutat újra fel kell építeni, hogy a változások életbe lépjenek. (Én GNS3 alatt dolgoztam, javarészt elég volt az SA újraindítása, de volt, hogy csak a forgalomirányítók újraindításával értem el az új konfigurációk használatát.) Érdemes kísérletezni, a kiadható parancsok listáját böngészni, és bátran kipróbálni a többi lehetőséget is.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük