1 – Introduktion
lad os fortsætte vores diskussion om GRE-tunneler. Hvis du ikke læste artiklen relateret til GRE, vil jeg anbefale, at du kigger på artiklen “trin for trin : forståelse af GRE-tunneler”.
i dette afsnit forbedrer vi den topologi, vi byggede i det forrige indlæg, ved at tilføje et sikkerhedslag med IPSec.
som en påmindelse har vi allerede oprettet følgende infrastruktur:
- en simpel GRE tunnel mellem Branch-1 og Branch-2 med deres respektive serielle interface som endepunkter.
Hvorfor bruge GRE over IPSec i stedet for rene IPSec tunneler?
der er flere fordele ved at bruge GRE-tunneler sammen med IPSec, primært fordi IPSec ikke understøtter anden trafik end unicast. Dette kan føre til problemer, hvis du planlægger at bruge tjenester, der kræver en sådan type trafik, såsom routingprotokoller som OSPF eller EIGRP.
takket være GRE-indkapslingsprocessen indkapsles broadcast-og multicast-trafik i en unicast-pakke, der kan behandles af IPSec, hvilket muliggør dynamisk routing mellem jævnaldrende adskilt af et usikkert netværksområde.
du kan simpelthen være villig til at implementere IPSec, hvis du ønsker at drage fordel af GRE-styrker og er bekymret for privatlivets fred (husk, at GRE ikke krypterer trafik). GRE-tunneler giver også et højere niveau af elasticitet end IKE keepalives faktisk gør.
ulemper
selvfølgelig er der flere ulemper ved at bruge denne slags løsning, overvej følgende, før du får hænder på tekniske ting:
- ved hjælp af GRE forbruger båndbredde og virkninger forestillinger. Tilføjelse af kryptering kan endnu mere ændre behandlingsressourcer og øge netværksforsinkelsen. Sørg for, at din infrastruktur understøtter det.
- ACL-poster skal vedligeholdes manuelt, hvilket kan blive kedeligt for mellemstore virksomheder.
- brug af punkt-til-punkt GRE-over-IPSec-tunneler skalerer ikke godt. Hvis du planlægger at tilføje flere eksterne sider, skal du overveje at implementere andre løsninger såsom DMVPN, som dynamisk bygger tunneler mellem eksterne jævnaldrende, samtidig med at de administrative ledelsesopgaver reduceres.
2- implementering
Bemærk: For at drage fordel af IPSec-kryptofunktioner skal du sikre dig, at din IOS-version understøtter dem. Du kan bruge Cisco Feature Navigator-værktøjet for at få en komplet liste over de understøttede funktioner på http://www.cisco.com/go/fn
Ike Phase 1
IPSec-indstillingerne, der bruges af effektiv kommunikation, er defineret i et transformationssæt. I dette konfigurationseksempel bruger vi både AH og ESP med AES til kryptering og SHA til respektive integritetskontrol:
| Branch-1 | Branch-2 |
|
crypto ipsec transform-set STRONG ah-sha-hmac esp-aes 256 esp-sha-hmac crypto map IPSEC_MAP 10 ipsec-isakmp ip adgang-liste udvidet IPSEC_ACL Interface Serial0 / 0 |
crypto ipsec transform-set STRONG ah-sha-hmac esp-aes 256 esp-sha-hmac crypto map IPSEC_MAP 10 ipsec-isakmp ip adgang-liste udvidet IPSEC_ACL interface serial0/1 |
den interessante trafik, der skal krypteres gennem tunnelen, er den trafik, der matcher IPSEC_ACL. Nu kan vi simpelthen gruppere alle tunnelens muligheder i et krypto-kort ved at definere den eksterne peer-adresse oghvilken trafik skal krypteres af hvilken specifik transform sæt. ISAKMP-politikken er ikke specificeret i kryptokortet, da den er relateret til ISAKMP fase 1 og forhandles afhængigt af hvert slutpunkts konfiguration.
IPSEC_ACL skal spejles mellem de 2 endepunkter. For ord skal den trafik, du har brug for at kryptere, accepteres på den anden side. Som et resultat skal du blot skifte kilde-og destinationsafsnit for hver post på begge routere. Du vil bemærke, at vi matcher trafik, der forlader den fysiske grænseflade: vi angiver GRE som trafiktype og kilde / destinationsadresser på tunnelen
endelig anvendes kryptokortet på den fysiske grænseflade. Bemærk, at anvendelse af kortet på Tunnelgrænsefladen muligvis ikke fungerer som forventet.
følgende logmeddelelse skal hæves:
%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP er tændt
verifikation
du kan verificere og fejlfinde fase 1 og 2 SA ved at udstede ‘Vis crypto isakmp sa’ og ‘vis crypto ipsec sa’, henholdsvis.
Branch-1 (ISAKMP)
Branch-1#vis crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
203.0.0.6 203.0.0.2 KM_IDLE 1001 0 aktiv
IPv6 Crypto ISAKMP SA
den anden kommando kan hjælpe med at overvåge, hvor mange pakker der er rejst gennem tunnelen:
Branch-1 (IPSec, uddrag)
Branch-1#vis crypto ipsec sa
interface: Serial0/0
Crypto map tag: IPSEC_MAP, lokal addr 203.0.0.2
beskyttet vrf: (ingen)
lokal ident (addr/mask/prot/port): (203.0.0.2/255.255.255.255/47/0)
remote ident (addr / maske / prot / port): (203.0.0.6/255.255.255.255/47/0)
current_peer 203.0.0.6 port 500
tilladelse, flag={origin_is_acl,}
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
#pkts decaps: 4, #pkts decaps: 4, #pkts decapts: 4,#pkts verificer: 4
#pkts komprimeret: 0,#pkts dekomprimeret: 0
#pkts ikke komprimeret: 0, # pkts compr. mislykkedes: 0
#pkts ikke dekomprimeret: 0, #pkts dekomprimering mislykkedes: 0
#send Fejl 1, #recv fejl 0
hvis vi ser på, hvordan pakker ser ud:
Bemærk, at ping fra 10.0.1.1 til 10.0.2.1 rejser til sin destination som en indkapslet pakke, der er godkendt (AH) og krypteret (ESP) i henhold til de indstillinger, der er konfigureret ovenfor.
Bemærk: Der skal genereres noget interessant trafik, før tunnelen er fuldt operationel. Hvis du arbejder på et laboratoriemiljø, kan du snif ISAKMP-trafikken og observere, hvordan udvekslingsprocessen fungerer.
denne artikel er beregnet til at dele viden. Hvis du finder noget mangler, eller der bør forbedres, ville jeg være glad for at tilføje sådanne oplysninger.