Önálló laboratórium beszámoló VTT5037

Átírás

1 Önálló laboratórium beszámoló VTT5037 Készítette: Kis-Hegedüs Gábor (X563ZP) Tanszéki konzulens: Heszberger Zalán Ipari konzulens: Rab Gergely CCIE #11280 I. Félévi Feladat A félév során egy működő, nemzetközi kapcsolatokkal rendelkező transport hálózat jövőbeli fejlesztésének alapjait kellett átgondolnom, tesztelnem. Napjainknak megfelelően, kulcsfontosságú szerepet játszanak a VPN technológiák, illetve azok titkosítása. A vállalatok szeretnének olyan megoldást, mely skálázható, és biztonságos is egyben. Banki hálózatok esetén is ugyanolyan fontos a QoS és az optimális routing, mint a biztonság. A problémák, melyek a feladat megoldása során felmerültek valósak, és egy valós vállalatról szólnak. 1. A problémák A nemzetközi hálózatokat általában 1-1 központból menedzselik. A hálózat sokféle megoldást tartalmazhat, ilyenek: MPLS VPN Nemzetközi bérelt vonalak Internet feletti VPN A cél az optimális routing, illetve a központi menedzselhetőség. A titkosítás manapság elengedhetetlen, internet feletti VPN és MPLS VPN esetén egyaránt. Titkosításra az IPSEC kiforrott megoldás, azonban ennek sok-sok hátránya is van. IPSEC tunnel-ek használatával ugyanis elvesztjük az optimális útvonalválasztás, illetve a központi menedzselés előnyeit. A problémák tehát összefoglalva: QoS limitációk (ez fontos probléma WAN-on) Hub-and-spoke topológiák: minden forgalom a hub-n keresztül kell hogy haladjon full mesh topológia: N*(N-1)/2 kapcsolat szükséges, nem skálázható. Multicast forgalom nehezen kezelhető (szükség van külön GRE tunnel-ek alkalmazására) A központi menedzsment nehézkesen oldható meg. Az IPSEC szabályokat router-enként kell definiálni A problémákra a Cisco GETVPN nyújt megoldást azonban az csak privát hálózatokon alkalmazható, ezért szükség volt még egy technológia megismerésére is, ez pedig a DMVPN. A vállalat ugyanis alapvetően két részre osztja a hálózatát:

2 Produktív forgalom A banki forgalmak kiszolgálását nemzetközi MPLS VPN-en keresztül valósítják meg. A biztonsági követelmények itt olyan erősek, hogy ez a forgalom nem mehet Interneten keresztül. A nemzetközi MPLS VPN azonban nagyon drága. Office forgalom Az irodai forgalmak a költséghatékonyság növelésének érdekében interneten keresztüli VPN-t használnak a kommunikációra. A fent leírt modell az 1. ábrán látható. A szimulációk alapja tehát egy ilyen hálózat. KS1 DMVPN_HUB EUNET_HQ PE1 AS 6501 RED3 Small Office MPLS VPN INT2 INTERNET PE2 PE3 INT1 AS 6500 A telephely DR1 RED1 DR2 RED2 B telephely 1. ábra Hálózati modell Az ábrán látható hogy a hálózat rendelkezik egy központtal (EUNET_HQ). A VPN-ek itt végződnek, az egész hálózatot innét menedzselik. A nagyobb telephelyeken DR router-nek hívjuk azokat a router-

3 eket melyek a globális MPLS VPN hálózathoz csatlakoznak, illetve RED router-eknek azokat, melyek az irodai forgalmakat viszik át az interneten keresztül. Természetesen ezek a router-ek egy tűzfallal (Cisco PIX, ASA) össze vannak kötve, azonban a feladat megoldásának szempontjából ez most lényegtelen. Látni fogjuk tehát, hogy a GETVPN alkalmazása MPLS VPN felett, megbízható és optimális megoldást nyújt a DR router-ek közötti kommunikációra. A GETVPN önmagában nem használható az interneten (kivétel persze, ha minden eszköznek és gépnek publikus IP címe van), azonban DMVPN-el együtt alkalmazva igen. II. A félév során végzett munka Az alábbi pontokban szeretném ismertetni a félév során végzett gyakorlati és elméleti munkát. 1. Elméleti Áttekintés 1.1. MPLS L3 VPN Az MPLS L3 VPN modell eltér a korábban használt L2 (Második réteg az OSI felfogás szerint) VPN től. L2 VPN-re példa a frame-relay illetve az ATM technológia. Itt virtuális áramköröket hoztak létre minden egyes ügyfélnek, egy adott ügyfél minden telephelye össze volt kötve egymással (full mesh). Ez a megoldás nem jól skálázható nagy mennyiségű kapcsolat esetén. (N*(N-1)/2 db kapcsolatra van szükség). Az MPLS VPN architektúrától elvárjuk, hogy a különböző ügyfelek tudjanak azonos IP címeket használni, illetve hogy külön routing táblával rendelkezzenek. Ezeket az elvárásokat a Cisco MPLS VPN technológiája teljesíti. 2. ábra MPLS VPN modell

4 A 9. ábrán látható az MPLS VPN modell, melynek egységei: P router-ek: A szolgáltató hálózatában központi router-ek. Feladatuk a csomagok továbbítása címkék alapján. Nem fut rajtuk BGP, így ezek a router-ek nem lesznek terhelve az ügyfelek hálózatainak nyilvántartásával. PE router-ek: A szolgáltató és az ügyfél között elhelyezkedő router-ek. Feladatuk az ügyfelek aggregálása és forgalmuk elkülönítése. MP-BGP-t (Multi Protokoll BGP) futtatnak, illetve hálózati információkat adnak át az ügyfelek eszközeinek. CE router-ek: Az ügyfelek hálózati eszközei. Ezeken a router-eken nem használunk MPLS-t, és gyakorlatilag bármilyen routing protokollt alkalmazhatunk (static, ospf, eigrp, is-is, ripv2..) MPLS VPN routing modell Az MPLS VPN routing modellje egy CE router szempontjából rendkívül egyszerű. Nem kell tudnia a szolgáltató technológiájáról, nem kell tudnia MPLS-t futtatni, csak egy egyszerű dinamikus routing protokollt, vagy statikus routing-ot kell használnia. Az ügyfelek tehát alkalmazhatnak olcsó eszközöket, a szolgáltató hálózata gyakorlatilag transzparens számukra. VRF (Virtual routing and Forwarding) táblák A PE router-eken az ügyfelek hálózati útjait meg kell különböztetni. Ezt a VRF technológia segítségével tehetjük meg. Minden egyes ügyfél (VPN) saját VRF táblával rendelkezik ahol a saját VPN hálózatának prefixei találhatóak. A 3. ábrán látható a VRF működése. 3. ábra VRF A szolgáltató PE router-ein tehát a globális routing tábla mellett a VPN-ekhez tartozó VRF táblákat is menedzselni kell. Az MPLS architektúrának köszönhetően azonban a P router-eknek nem kell tudniuk a VRF táblákról, csak címke alapján kell továbbítaniuk az adatokat. Cisco implementáció esetében a VRF illetve az MPLS esetén szükséges hogy az eszköz támogassa a CEF-t. (Cisco Express Forwarding) A PE-CE router-ek közötti protokollok, és a VRF működése látható az 4. ábrán.

5 4. ábra PE-CE, VRF Látható, hogy a CE router-en gyakorlatilag bármilyen protokollt használhatunk hálózati információ továbbítására, azonban a PE oldalon ez egy kicsit bonyolultabb. A Cisco IOS (Internetwork Operation System) a különböző routing protokollokat különböző képpen tudja futtatni. Vannak olyanok, melyek esetén több process is futhat egy router-en, ilyen például az OSPF. Vannak olyan protokollok, melyekből csak egy globális példány futhat, viszont ennek másolatai futnak a VRF táblák alatt.(routing Context-ek). A VRF-eket a router-en interface-khez rendeljük, ezek lehetnek fizikaiak vagy logikaiak, azonban egy interface csak egy VRF tagja lehet. RD (Route Distinguiser): Egy olyan azonosító, mely a PE router-ek között kommunikáció során használt. A 64 bites azonosító és a 32 bites IP cím azonosító együttesen alkotja a VPNv4-es címet. Ezzel a PE-PE kommunikáció esetén minden egyes VPN minden prefixe megkülönböztethető lesz. RT (Route Target ): Az azonosító fogja a VPN-eket azonosítani. Tipikusan az alábbi formában adhatjuk meg: 100:1 MPLS VPN Routing: Az architektúrában több protokoll is szerepet játszik. A szolgáltató hálózatában tipikusan IP protokollt, és egy IGP-t használnak a belső információk átvitelére (Control Plane). Ez teljesen független az ügyfelektől, célja a szolgáltatói router-ek közötti kommunikáció megteremtése. Ez szükséges az MP-BGP Session információk, illetve az LDP információk terjesztéséhez. A PE router-ek általában MP-BGP-t futtatnak, és ibgp peer-ként kapcsolódnak egymáshoz. Az ibgp hátránya az, hogy a PE router-ek full mesh kapcsolatban kell, hogy álljanak egymással, ez egy nagy szolgáltató esetén rengeteg TCP session jelenthet. A problémát route reflector használatával lehet megoldani, ilyenkor ugyanis nincs szükség arra, hogy minden PE minden PE vel össze legyen kötve. Az MP-BGP feladata hogy a különböző VRF táblák tartalmát továbbítsa a PE router-ek között. Feladata továbbá, hogy a VPN-ekhez MPLS címkét rendeljen, ez lesz a második címke, ezt tehát nem az LDP menedzseli. Ha tehát egy új hálózat jelenik meg az A ügyfél 1-es telephelyén, akkor az ügyfél routing protokollja ezt a hálózatot áthirdeti a PE router-nek. A PE router a hirdetés következtében a hálózatot felveszi az ügyfélhez rendelt VRF táblába. A PE1 router MP-iBGP hirdetésben továbbadja az információt a PE2

6 router-nek, ahol a hálózat bekerül az ügyfél VRF táblájába. Innen, a helyi PE-CE routing protokoll továbbítja az információt a 2. telephelyhez GETVPN A GETVPN ( Group Encrypted Transport VPN) olyan alagút nélküli IPSEC VPN, mely megoldást nyújt az előző IPSEC modellek negatív tulajdonságára. A GET egy az egyben megőrzi az eredeti IP fejlécet. Ennek köszönhetően alapból támogatottak IP Multicast forgalmak, illetve a különböző QoS megoldások (a ToS mező is megmarad). Mivel nincs szükség alagutak létrehozására, egyszerű, biztonságos és direkt kommunikációt lehet létrehozni a VPN hálózat router-ei között. A GET megoldás nyújt az MPLS VPN-ek titkosítására (habár bármilyen átviteli technológia felett működhet) GETVPN alapfogalmak A következő pontokban ismertetem a GET alap fogalmait. 5. ábra GETVPN GDOI ( Group Domain of Interpretation): A GDOI-t az IETF RFC 3547-ben mutatták be. A protokoll ISAKMP első fázissal van védve, és célja a csoportos kulcs kiosztás megvalósítása. Group Member (GM): A csoporttag regisztrál a kulcsszerverre. Sikeres regisztráció után megkapja az IPSEC SA-t (szabályzatok,kulcsok), ennek segítségével tud majd kommunikálni a csoporttagokkal. A kulcsszerver periódikusan frissíti a csoporthoz tartozó kulcsot, még mielőtt az lejárna. Amennyiben a csoporttag nem kapja meg az új kulcsot, újból regisztrál. Key Server (KS): A kulcsszerver feladata a biztonsági szabályzatok nyilvántartása, illetve a kulcsok menedzselése. Amikor egy csoporttag regisztrál, megkapja a csoporthoz tartozó kulcsokat, illetve szabályzatokat. A csoporttagok bármikor regisztrálhatnak, az aktuális információkat fogják megkapni. Regisztráció esetén elküldik a Group ID-t (ez határozza meg, hogy melyik csoporthoz szeretnének regisztrálni). A szerver két fajta kulcsot tart nyilván: o KEK (Key Encryption key): Az újrakulcsolás (rekey) titkosítására használt kulcs. o TEK (Traffic Encryption key): az a kulcs, mely segítségével titkosítják a forgalmat a csoporttagok egymás között A kulcsszerver kulcsot frissít amennyiben lejár az előző kulcs élettartama, illetve ha módosítunk a szerver beállításain.

7 6. ábra GETVPN működés A 6. ábrán látható a GET működése: (1) A csoporttagok regisztrálnak a kulcs szerverre, a szerver azonosítja a csoporttagokat, letöltődnek a biztonsági szabályzatok (IPSEC SA) az eszközökre (2) A csoporttagok egymással közvetlenül kommunikálnak biztonságos csatornán a kapott TEK felhasználásával (3) Periodikus kulcsfrissítést végez a kulcsszerver A kulcs kiosztása történhet multicast, illetve unicast módon. A multicast alapú kulcskiosztás lényegesen hatékonyabb, mint az unicast, azonban ehhez a transport hálózatnak támogatnia kell a multicast kommunikációt. A 7. ábrán látható a regisztráció, melyet ISAKMP első fázis véd. Az ISAKMP első fázis osztott kulccsal azonosítjuk, de használhatunk PKI-t is. 7. ábra GDOI regisztráció A GDOI protokoll UDP 848-as porton kommunikál, illetve NAT-T támogatás esetén az UDP 4500-as porton. Amennyiben hibatűrő megoldást szeretnénk, lehetőség van több kulcsszerver használatára is. Ebben az esetben lesznek elsődleges kulcsszerverek, illetve másodlagosak ( Cooperative key server). Minden csoport rendelkezhet 1 vagy több másodlagos kulcsszerverrel. A másodlagos kulcsszerverek beállításai automatikusan szinkronizálódnak, elég csak az elsődleges kulcsszervert konfigurálni. A GETVPN alagút nélküli IPSEC megoldás. A 8. ábrán látható a GETVPN és a hagyományos ipsec tunnel módban használt IP csomag felépítése.

8 8. ábra GETVPN IP fejléc megőrzés A vállalatok általában privát IP címeket használnak a hálózatukban. A GETVPN ebben az esetben nem használható internetes VPN titkosítására, hiszen megőrzi az eredeti IP fejlécet, és az eredeti (Privát) IP forrás címet és cél címet. Az interneten a privát címek nem route-olhatóak. MPLS VPN esetén ez nem probléma. GETVPN alapú DMVPN t használva azonban az internetes VPN-k is élvezhetik a GET nyújtotta előnyöket. További szolgáltatások (csak említés szintjén): Time-Based Anti-Replay VRF-Lite interface támogatása Recieve only SA feature NAT-T támogatás 1.3. GETVPN alapú DMVPN Az IPSEC tunnel módban való alkalmazásához rengeteg konfigurációra, és kapcsolatra volt szükség a korábbi VPN modellek esetén. N db router esetén ugyanis N*(N-1)/2 db point-to-point tunnel-t kellett létrehozni (vagy hub-and-spoke topológiát kellett alkalmazni). Ezekre a problémákra nyújtott megoldást a DMVPN (Dynamic Multipoint VPN) DMVPN összetevők Generic Routing Encapsulation (GRE) protocol: A Cisco által létrehozott protokoll, melynek feladata hogy IP unicast, multicast illetve broadcast forgalmat csomagoljon be. Next Hop Resolution Protocol (NHRP): Az NHRP egy layer2-es kliens-server cím feloldó protokoll. Működése hasonlít az ARP illetve a Reverse ARP-hoz. NHRP esetén a tunnel interface-hez rendelt címeket kell fizikai (valós) címekhez rendelni. Az NHRP táblát a hub router tartja nyilván.

9 GETVPN végzi a titkosítást és nem a DMVPN-nél megszokott ipsec profile-ok GETVPN alapú DMVPN működése KS1 DMVPN_HUB Static tunnel NHRP resolution req INT2 AS 6501 INTERNET Static Tunnel RED3 Small Office AS 6500 INT1 Dynamic Tunnel RED1 RED2 9. ábra DMVPN topológia a szimulációban GETVPN Regisztráció: minden spoke router és a DMVPN hub router beregisztrál GDOI protokollon a KS kulcsszerverbe DMVPN Regisztráció: Minden spoke router (red1,2,3) beregisztrál a DMVPN hub routerre, és közli a valós (illetve a privát tunnel interface-n definiált) IP címét. Az NHRP tábla a hub router-en van nyilvántartva. Amikor egy spoke router egy másik spoke router-en lévő privát IP címre csomagot akar küldeni, először lekérdezi NHRP-vel a hub router-t, hogy mi a valós IP címe a másik routernek. Amikor az NHRP server visszaadta a kívánt IP címet, dinamikus tunnel jön létre a két spoke router között. A kommunikáció innentől kezdve direkt. A titkosításért a GET felel.

10 2. Gyakorlati munka 2.1. GNS3 Cisco szimulátor program Szimulációkra az open-source GNS3 programot használtam fel. A program valós Cisco hardware-t emulál, és valós Cisco IOS-t futtat. A virtuális router-ek konzol portja localhost-on telnet segítségével érhető el. A program a 10. ábrán látható. A felhasznált hardware: IBM T60 laptop 1.5 GB DDR2 RAM Core2 duo, 1.86 Ghz intel cpu 10. ábra A szimuláció megvalósítása GNS3 programmal Felhasznált Cisco IOS: c7200-advipservicesk9-mz t1 Az emulált Cisco hardware-k: Cisco 7206VXR, 256 MB RAM 2.2. A szimuláció részletes bemutatása A feladatot három részre bontottam: Hálózati modell, és IP címzés létrehozása GETVPN MPLS L3 VPN felett. A DR router-ek kommunikációja GETVPN alapú DMVPN megvalósítása. A red router-ek kommunikációja

11 A hálózati modell, IP cím kiosztás Lo0: /32 F1/0: /30 F1/1: /28 Tun100: /28 F1/0: /28 F1/1: /28 EUNET_HQ KS1 DMVPN_ HUB Lo0: /32 F0/0: /30 F1/0: /30 PE1 AS 6501 Lo0: /32 F1/0: /30 F1/1: /28 Lo0: /32 F1/0: /30 F1/1: /30 F2/0: /30 Lo0: /32 F1/0: /30 F1/1: /30 P Lo0: /32 F1/1: /30 F1/0: /30 PE3 AS 6500 INT2 INT1 Lo0: /32 F1/0: /30 F1/1: /30 F2/0: /30 PE2 A telephely DR1 RED1 DR2 Lo0: /32 Tun10: /24 Lo0: /32 F1/0: /30 F1/0: /30 F1/0: /30 RED2 Tun10: /24 B F1/0: /30 telephely 11. ábra IP cím kiosztás A 11. ábrán látható a címkiosztás. A modellben a PE1, PE2, PE3 és P router-ek alkotják az MPLS VPN-t. Az INT1 és INT2 router-ek alkotják az Internetet (AS 6500 és 6501). A red1 és DR1 router-ek az egyik ügyfelet, míg a red2 és dr2 router-ek a másik ügyfelet GETVPN MPLS L3 VPN felett A feladathoz létre kellett hozni egy MPLS VPN szolgáltatót. Az MPLS VPN szolgáltató 1 VPN-t tartalmaz (ennek azonosítója 100:1), és ebben a VPN-ben van a három router (KS1, DR1, DR2). Ezeken a router-eken EIGRP (AS=1) fut. A konfigurációs lépések leírása meghaladja a dokumentum terjedelmét, a mellékletben megtalálhatóak az MPLS router-ek konfigurációi. Alapvető IP kapcsolat ellenörzése a DR1 és DR2 router-ek között: DR1#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 272/352/436 ms

12 Traceroute segítségével ellenőriztem, hogy milyen útvonalon jutott el a csomag a másik DR routerhez: DR1#traceroute Type escape sequence to abort. Tracing the route to msec 68 msec 36 msec [MPLS: Labels 16/22 Exp 0] 324 msec 232 msec 260 msec [MPLS: Label 22 Exp 0] 140 msec 320 msec 148 msec msec 308 msec * DR1# A traceroute eredményén látható, hogy a csomag egy MPLS VPN-n keresztül jutott el a másik DR router-hez. A példa kedvéért, a PE3 router-n az MPLS forwarding tábla így néz ki: PE3#sh mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag /32 0 Fa1/ Pop tag /30 0 Fa1/ Pop tag /30 0 Fa1/ /32 0 Fa1/ /32 0 Fa1/ Aggregate /30[V] 0 22 Untagged /32[V] 3954 Fa1/ PE3# Végezetül a DR1 routing tábláján látszik, hogy az MP-BGP és az EIGRP redistributio-ja sikeres volt. DR1#sh ip eigrp neighbors IP-EIGRP neighbors for process 1 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num Fa1/ :23: DR1# DR1#sh ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set D /32 is subnetted, 3 subnets [90/158720] via , 00:23:39, FastEthernet1/0

13 C is directly connected, Loopback0 D [90/158720] via , 00:23:39, FastEthernet1/ /30 is subnetted, 3 subnets D [90/30720] via , 00:23:39, FastEthernet1/0 C is directly connected, FastEthernet1/0 D [90/30720] via , 00:23:39, FastEthernet1/0 DR1# A D betüvel jelölt prefix-eket a router EIGRP-n keresztül tanulta meg. A titkosítás (GETVPN) konfigurációja. Miután az alapvető kapcsolat megvolt a DR és KS router-ek között, a GETVPN konfigurációja következett. A kulcsszerver konfigurációja: ISAKMP policy létrehozása, AES titkosítással, osztott kulcsú autentikációval crypto isakmp policy 1 encr aes 256 authentication pre-share group 2 lifetime 60 Az ISAKMP első fázishoz szükséges osztott titok definiálása: crypto isakmp key cisco address IPSEC transform set-k definiálása: crypto ipsec transform-set GDOI-TSET esp-aes 256 esp-sha-hmac GDOI IPSEC profile definiálása: crypto ipsec profile GDOI-PROFILE set security-association lifetime seconds 1800 set transform-set GDOI-TSET GDOI paraméterek definiálása: crypto gdoi group GDOI-GROUP1 identity number 1 server local rekey retransmit 10 number 2 rekey authentication mypubkey rsa rsa_key rekey transport unicast sa ipsec 1 profile GDOI-PROFILE match address ipv4 101 no replay address ipv

14 Fontos hogy a klienseken is az identity number 1 legyen (ez a csoport ID). A 101-es ACL-el definiáltuk azokat a forgalmakat, melyeket a router-ek titkosítani fognak. access-list 101 deny udp any any eq 848 access-list 101 deny udp any eq 848 any access-list 101 deny eigrp any any access-list 101 permit ip access-list 101 permit icmp any access-list 101 permit icmp any Az acl-ben deny azt jelenti, hogy az NE legyen titkosítva. Az UDP 848 a GDOI protokoll. Az EIGRP-t sem szabad titkosítani. A kulcsszerver ellenőrzése: KS1#sh crypto gdoi ks Total group members registered to this box: 2 Key Server Information For Group GDOI-GROUP1: Group Name : GDOI-GROUP1 Group Identity : 1 Group Members : 2 IPSec SA Direction : Both ACL Configured: access-list 101 Tehát sikeresen regisztrált mindkét router. Egy regisztráció nyomon követése (clear crypto gdoi a DR1 router-n az újra regisztráció eléréséhez): KS1# *May 12 21:07:55.119: GDOI:INFRA:(0:0:N/A:0): Adding KEK Policy to the current ks_group *May 12 21:07:55.127: GDOI:INFRA:(0:0:N/A:0): Setting unicast rekey for KEK policy. *May 12 21:07:55.139: GDOI:INFRA:(0:1006:HW:0:1): Construct tek: spi is 0x0 *May 12 21:07:55.143: GDOI:INFRA:(0:1006:HW:0:1): Construct tek: spi is 0x0 *May 12 21:07:55.147: GDOI:INFRA:(0:1006:HW:0:1): Construct tek: spi is 0x0 *May 12 21:07:55.151: GDOI:INFRA:(0:0:N/A:0): lifetime is 609 seconds *May 12 21:07:55.151: GDOI:INFRA:(0:1006:HW:0:1): Construct tek: spi is 0x *May 12 21:07:55.155: GDOI:INFRA:(0:0:N/A:0): lifetime is 609 seconds *May 12 21:07:55.159: GDOI:INFRA:(0:1006:HW:0:1): Construct tek: spi is 0x *May 12 21:07:55.163: GDOI:INFRA:(0:0:N/A:0): lifetime is 609 seconds *May 12 21:07:55.167: GDOI:INFRA:(0:1006:HW:0:1): Construct tek: spi is 0x *May 12 21:07:55.175: GDOI:INFRA:(0:1006:HW:0:1):GDOI SA sent successfully by KS *May 12 21:07:55.727: GDOI:INFRA:(0:1006:HW:0:1):GDOI KD sent successfully by KS KS1# A regisztráció sikeresen megtörtént. GNS3-ban lehetőség van bármely router interface-en csomagok rögzítésére. Így a program olyan.cap fájlt állít elő, melyet a wireshark dekódolni tud. Egy DR1 és DR2 közötti ping bemutatása Wiresharkal:

15 A képen jól látható hogy az ICMP csomagok kódoltak (Protocol ESP), és hogy azok direktbe a DR2 router-hez mennek a cél cím alapján. A GETVPN egyik legnagyobb előnye tehát hogy direkt, védett kommunikációt biztosít. A fent látható adatok a DR1 router F1/0 interface-n készültek. A kliens beállítása: ISAKMP policy és osztott titok definiálása: crypto isakmp policy 1 encr aes 256 authentication pre-share group 2 lifetime 3600 crypto isakmp key cisco address GDOI kulcsszerver definiálása, és a GDOI crypto map létrehozása: crypto gdoi group group1 identity number 1 server address ipv crypto map map-group1 local-address Loopback0 crypto map map-group1 10 gdoi set group group1 Ellenőrzés: DR1#show crypto gdoi gm Group Member Information For Group group1: IPSec SA Direction : Both ACL Received From KS : gdoi_group_group1_temp_acl Re-register Remaining time : 406 secs GETVPN alapú DMVPN létrehozása Az internetre kapcsolódó router-ek red1, red2. Az internetet az INT1 és INT2 router alkotja. KS1 illetve DMVPN_HUB router-ek azonos subneten vannak, de ez nem követelmény. Két külön router kell viszont, mert egy router nem lehet egyszerre kulcsszerver és kliens is GET modellben. Sajnos GETVPN alapú DMVPN esetén nem támogatott a redundáns kulcsszerverek használata jelenleg.

16 Az alapvető kapcsolat létrejöttét ping-el ellenőriztem. Az internetes router-eken BGP fut, a belső interface-n tiltottak a privát forrás címmel érkező csomagok (ahogy az összes internetes router-en). A kulcsszerveren fel kellett venni egy új crypto gdoi csoportot a DMVPN-ben résztvevő router-ek miatt. crypto gdoi group dmvpn identity number 10 server local rekey lifetime seconds 300 rekey retransmit 10 number 2 rekey authentication mypubkey rsa rsa_key rekey transport unicast sa ipsec 10 profile GDOI-PROFILE match address ipv4 110 no replay address ipv Itt természetesen más identity number-t adtam meg, hiszen ez egy másik GET csoport. A 110-es acl tartalma: KS1#sh access-lists 110 Extended IP access list deny udp any any eq deny udp any eq 848 any 30 permit gre any any KS1# A DMVPN_HUB, red1, red2 router-k hasonló módon lettek konfigurálva, mint a DR1, DR2 router-ek. Sikeresen beregisztráltak a KS1 szerverre. A DMVPN_HUB router konfigurációja A DMVPN_HUB router-en létre kell hozni egy Tunnel interface-t. Ezen a router-en NHRP szerver fog futni. A routing-ért EIGRP AS=2 fog felelni. interface Tunnel100 description DMVPN - EIGRP net bandwidth 2000 ip address no ip redirects ip mtu 1400 no ip next-hop-self eigrp 2 ip pim nbma-mode ip pim sparse-dense-mode ip nhrp map multicast dynamic ip nhrp network-id 1000 ip nhrp server-only ip nhrp cache non-authoritative no ip split-horizon eigrp 2 no ip mroute-cache tunnel source FastEthernet1/0

17 tunnel mode gre multipoint tunnel key router eigrp 2 network network no auto-summary A Tunnel interface címe privát IP cím. EIGRP esetén le kell tiltani a split-horizon és a next-hop-self funkciókat a hub-and-spoke topológia miatt. Ahhoz hogy az EIGRP működjön, a multicast forgalmat is mappelni kell. A tunnel forrás címe/interface a WAN interface lesz. DMVPN kliens konfiguráció: A kliens-en a tunnel interface a következőképpen néz ki: interface Tunnel10 ip address no ip redirects ip mtu 1400 ip pim sparse-dense-mode ip multicast rate-limit out 128 ip nhrp map ip nhrp map multicast ip nhrp network-id 1000 ip nhrp holdtime 300 ip nhrp nhs ip nhrp registration no-unique ip nhrp cache non-authoritative tunnel source FastEthernet1/0 tunnel mode gre multipoint tunnel key A klienseken csinálunk egy statikus NHRP bejegyzést a szerver címére. Az NHRP szervert definiálni kell, illetve azt is, hogy a multicast forgalmat milyen címre irányítsa a router. Ellenőrzésként, a DMVPN_HUB-n az NHRP tábla: DMVPN_HUB#sh ip nhrp /32 via , Tunnel100 created 00:48:02, expire 00:03:37 Type: dynamic, Flags: registered NBMA address: /32 via , Tunnel100 created 00:46:54, expire 00:03:49 Type: dynamic, Flags: registered NBMA address: Látható, hogy a valós, publikus ip cím az NBMA cím. Egy dinamikus tunnel felépülésének menete, a DMVPN_HUB-n debuggolva. RED1 router-ről pingeltem red2-t. *May 12 22:49:28.051: NHRP: Receive Resolution Request via Tunnel100 vrf 0, packet size: 72 *May 12 22:49:28.059: NHRP: netid_in = 1000, to_us = 0

18 *May 12 22:49:28.059: NHRP: nhrp_rtlookup yielded Tunnel100 *May 12 22:49:28.063: NHRP: netid_out 1000, netid_in 1000 *May 12 22:49:28.067: NHRP: nhrp_cache_lookup_comp returned 0x66D763E0 *May 12 22:49:28.067: NHRP: Forwarding request due to authoritative request. *May 12 22:49:28.071: NHRP: Attempting to send packet via DEST *May 12 22:49:28.075: NHRP: Encapsulation succeeded. Tunnel IP addr *May 12 22:49:28.079: NHRP: Forwarding Resolution Request via Tunnel100 vrf 0, packet size: 92 *May 12 22:49:28.083: src: , dst: *May 12 22:49:28.087: NHRP: 92 bytes out Tunnel100 *May 12 22:49:28.355: NHRP: Receive Resolution Request via Tunnel100 vrf 0, packet size: 72 *May 12 22:49:28.359: NHRP: netid_in = 1000, to_us = 0 *May 12 22:49:28.363: NHRP: nhrp_rtlookup yielded Tunnel100 *May 12 22:49:28.367: NHRP: netid_out 1000, netid_in 1000 *May 12 22:49:28.367: NHRP: nhrp_cache_lookup_comp returned 0x66D762C8 *May 12 22:49:28.371: NHRP: Forwarding request due to authoritative request. *May 12 22:49:28.375: NHRP: Attempting to send packet via DEST *May 12 22:49:28.379: NHRP: Encapsulation succeeded. Tunnel IP addr *May 12 22:49:28.379: NHRP: Forwarding Resolution Request via Tunnel100 vrf 0, packet size: 92 *May 12 22:49:28.383: src: , dst: *May 12 22:49:28.387: NHRP: 92 bytes out Tunnel100 A dinamikus tunnel felépült, a red1-en az nhrp bejegyzések: /32 via , Tunnel10 created 00:01:56, expire 00:03:04 Type: dynamic, Flags: router NBMA address: Látható hogy a felépült Tunnel dinamikus, és 3 perc múlva lejár. Az EIGRP a Tunnel interface-eken keresztül szomszédságot kötött (ez csak a multicast mapping után működött). A red2-n létrehozott új prefix gond nélkül áthirdetődött a red1 router-re : /30 is subnetted, 1 subnets C is directly connected, FastEthernet1/ /32 is subnetted, 1 subnets D [90/ ] via , 00:27:31, Tunnel10 C /24 is directly connected, Tunnel10 S* /0 [1/0] via red1# Wireshark segítségével megfigyeltem a red1 és red2 router közötti ICMP csomagokat egy ping esetén. Az eredmény a vártnak megfelelő: direkt kommunikáció jön létre a két router között, amennyiben felépült a dinamikus tunnel. Ha nincs dinamikus tunnel felépülve, amíg felépül, a hub-on keresztül jutnak el a csomagok a red2 router-re. (A lenti ábrán látható hogy az ICMP csomagok titkosítva, és direktbe jutnak el a címről a címre )

19 III. Konklúzió Az I. pontban leírt problémákra a tesztek alapján megoldást nyújt a GETVPN: IP fejléc megőrzése, alagút nélküli IPSEC megoldás: o Direkt kommunikáció o QoS alkalmazása o Native routing, nem overlay o Egyszerű konfiguráció o Failover megoldás (redundáns kulcsszerverek) Központi menedzsment o Ipsec policy download DMVPN-el alkalmazva publikus cím tartomány felett is alkalmazható, ezzel azonban bonyolultabb lesz a konfiguráció, a megoldás skálázható. IV. Felhasznált Irodalom - Cisco Expo Ács György előadása - Implementing Group Domain of Interpretation in a Dynamic Multipoint VPN - Cisco ECT-Based Group Encrypted Transport VPN - Cisco Networkers 2008: BRKSEC-3006.pdf, BRKSEC-3008.pdf, BRKSEC-2007.pdf előadások - Hardware-Routers-General-Cisco GET (Group Encrypted Transport) VPN Technical Overview.pdf - CCIE Professional Development Series Network Security Technologies and Solutions V. Mellékletek A konfigurációk: P router: upgrade fpd auto version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption hostname P

20 boot-start-marker boot-end-marker no aaa new-model ip cef multilink bundle-name authenticated archive log config hidekeys interface Loopback0 ip address interface FastEthernet0/0 duplex half interface FastEthernet1/0 ip address mpls ip interface FastEthernet1/1 ip address mpls ip interface FastEthernet2/0 ip address mpls ip interface FastEthernet2/1 router ospf 1 router-id log-adjacency-changes network area 0 no ip http server no ip http secure-server logging alarm informational control-plane gatekeeper