1 – Bevezetés
folytassuk a vitát a GRE alagutak. Ha nem olvasta a GRE-hez kapcsolódó cikket, azt javaslom, hogy nézze meg a “lépésről lépésre : a GRE alagutak megértése” cikket.
ebben a szakaszban javítjuk az előző bejegyzésben beépített topológiát, egy biztonsági réteg hozzáadásával az IPSec segítségével.
emlékeztetőül, már felállítottuk a következő infrastruktúrát:
- egy egyszerű gre alagút Branch – 1 és Branch-2 a megfelelő soros interfész végpontként.
miért érdemes a GRE-t IPSec-en keresztül használni a tiszta IPSec-alagutak helyett?
a GRE alagutak használatának számos előnye van az IPSec mellett, elsősorban azért, mert az IPSec nem támogatja az unicast-on kívüli forgalmat. Ez problémákhoz vezethet, ha olyan szolgáltatásokat kíván használni, amelyek ilyen típusú forgalmat igényelnek, például olyan útválasztási protokollokat, mint az OSPF vagy az EIGRP.
a GRE beágyazási folyamatnak köszönhetően a broadcast és a multicast forgalom egy unicast csomagba van beágyazva, amely IPSec-vel kezelhető, így dinamikus útválasztást tesz lehetővé a nem biztonságos hálózati területtel elválasztott társaik között.
lehet, hogy egyszerűen hajlandó végrehajtani az IPSec-et, ha szeretné kihasználni a GRE erősségeit, és aggódik a magánélet miatt (ne feledje, hogy a GRE nem titkosítja a forgalmat). A GRE alagutak magasabb szintű rugalmasságot biztosítanak, mint az IKE keepalives valójában.
hátrányok
természetesen számos hátránya van ennek a megoldásnak, fontolja meg a következőket, mielőtt technikai dolgokat kapna:
- a GRE használata sávszélességet igényel és hatással van a teljesítményre. A titkosítás hozzáadása még jobban megváltoztathatja a feldolgozási erőforrásokat és növelheti a hálózati késleltetést. Győződjön meg arról, hogy infrastruktúrája támogatni fogja.
- az ACL bejegyzéseket manuálisan kell karbantartani, ami unalmassá válhat a közepes méretű vállalatok számára.
- a pont-pont gre-over-IPSec alagutak használata nem méretezhető jól. Ha több távoli webhelyet kíván hozzáadni, fontolja meg más megoldások megvalósítását, például a DMVPN-t, amely dinamikusan épít alagutakat a távoli társaik között, miközben csökkenti az adminisztrációs menedzsment feladatokat.
2- végrehajtás
megjegyzés: annak érdekében, hogy részesüljenek az IPSec crypto funkciók, győződjön meg arról, hogy az IOS verzió támogatja őket. Használhatja a Cisco Feature Navigator eszköz annak érdekében, hogy egy teljes listát a támogatott funkciók http://www.cisco.com/go/fn
IKE Phase 1
az IPSec lehetőségek által használt hatékony kommunikáció vannak meghatározva egy transzformációs készlet. Ebben a konfigurációs példában mind az AH-t, mind az ESP-t AES-sel használjuk a titkosításhoz, az SHA-t pedig a megfelelő integritás-ellenőrzésekhez:
| ág-1 | ág-2 |
|
crypto ipsec transform-set erős ah-sha-hmac esp-aes 256 esp-Sha-hmac crypto térkép IPSEC_MAP 10 ipsec-isakmp ip access-lista kiterjesztett IPSEC_ACL Interface Serial0 / 0 |
crypto ipsec transform-set erős ah-sha-hmac esp-aes 256 esp-Sha-hmac crypto térkép IPSEC_MAP 10 ipsec-isakmp ip access-lista kiterjesztett IPSEC_ACL interfész Serial0/1 |
az alagúton keresztül titkosítani kívánt érdekes forgalom az IPSEC_ACL-nek megfelelő forgalom. Most egyszerűen csoportosíthatjuk az alagút összes opcióját egy kriptográfiai térképbe, meghatározva a távoli peer címet és melyik forgalmat kell titkosítani, hogy melyik konkrét transzformációs készlet. Az ISAKMP házirend nincs megadva a kriptográfiai térképen, mivel az az ISAKMP 1. fázisához kapcsolódik, és az egyes végpontok konfigurációjától függően kerül megtárgyalásra.
az IPSEC_ACL-t tükrözni kell a 2 végpont között. A szavak sorrendjében a titkosításhoz szükséges forgalmat a másik oldalon el kell fogadni. Ennek eredményeként egyszerűen kapcsolja be a forrás és a cél szakaszokat minden egyes bejegyzéshez mindkét útválasztón. Észre fogja venni, hogy a fizikai interfészből kilépő forgalmat egyeztetjük: a GRE-t a forgalom típusaként és az alagút forrás / célcímeként adjuk meg
végül a kriptográfiai térképet alkalmazzuk a fizikai interfészen. Ne feledje, hogy a térkép alkalmazása az alagút felületén nem biztos, hogy a várt módon működik.
a következő naplóüzenetet kell felemelni:
%CRYPTO-6-ISAKMP_ON_OFF: az ISAKMP be van kapcsolva
Verification
az 1.és 2. fázisú SA ellenőrzése és hibaelhárítása a ‘show crypto isakmp sa’ és a ‘show crypto ipsec sa’ kiadásával lehetséges.
1-es ág (ISAKMP)
Branch-1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src állam conn-id slot állapota
203.0.0.6 203.0.0.2 QM_IDLE 1001 0 aktív
IPv6 Crypto ISAKMP SA
a második parancs segítségével nyomon követheti, hogy hány csomag utazott az alagúton keresztül:
Branch – 1 (IPSec, részlet)
Branch-1 # show crypto ipsec sa
interfész: Serial0 / 0
Crypto térkép címke: IPSEC_MAP, helyi cím 203.0.0.2
védett vrf: (nincs)
helyi azonosító (cím/maszk/prot/port): (203.0.0.2/255.255.255.255/47/0)
távoli azonosító (addr / maszk / prot / port): (203.0.0.6/255.255.255.255/47/0)
current_peer 203.0.0.6 port 500
engedély, flags={origin_is_acl,}
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
#pkts compressed: 0, #pkts decpressed: 0
#pkts nincs tömörítve: 0, #pkts compr. sikertelen: 0
#a pkts nincs kibontva: 0, #a pkts kicsomagolása sikertelen: 0
#küldési hibák 1, #recv hibák 0
ha megnézzük, hogyan néznek ki a csomagok:
vegye figyelembe, hogy a 10.0.1.1-től 10.0.2.1-ig terjedő ping egy kapszulázott csomagként érkezik a rendeltetési helyére, amely hitelesített (AH) és titkosított (ESP) a fent konfigurált beállítások szerint.
Megjegyzés: Néhány érdekes forgalmat kell generálni, mielőtt az alagút teljesen működőképes lenne. Ha laboratóriumi környezetben dolgozik, snif az ISAKMP forgalmat, és figyelje meg, hogyan működik az exchange folyamat.
ez a cikk az ismeretek megosztására szolgál. Ha úgy találja, hogy valami hiányzik, vagy ezen javítani kell, örömmel adnék hozzá ilyen információkat.