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

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 Code, MAC.) 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 SPI, Security 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:

Az IKE 1. fázisához létrehozunk egy ISAKMP házirendet (ISAKMP policy).
Az IKE 2. fázisához létrehozunk egy transzformációs készletet (Transform Set).
Létrehozunk egy ACL-t, mely arra a forgalomra illeszkedik, melyet az alagúton át akarunk vezetni.
Az előzőeket összefoglaljuk egy Crypto Map-ben.
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

Post Views: 2 400

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ítandó 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