1-Introduksjon
La oss fortsette diskusjonen om GRE-tunneler. Hvis du ikke leste artikkelen relatert TIL GRE, vil jeg anbefale at du tar en titt på» Step-by-Step : Understanding GRE Tunnels » – artikkelen.
i denne delen vil vi forbedre topologien vi bygget i forrige innlegg, ved å legge til et sikkerhetslag med IPSec.
som en påminnelse har vi allerede satt opp følgende infrastruktur:
- EN enkel GRE-tunnel mellom Gren-1 og Gren-2 med deres respektive Serielle grensesnitt som endepunkter.
hvorfor bruke GRE Over IPSec i stedet for rene IPSec-tunneler?
DET er flere fordeler med Å bruke GRE-tunneler sammen Med IPSec, først og fremst fordi IPSec ikke støtter annen trafikk enn unicast. Dette kan føre til problemer hvis du planlegger å bruke tjenester som krever en slik type trafikk, for eksempel rutingsprotokoller som OSPF eller EIGRP.
takket VÆRE GRE-innkapslingsprosessen er kringkasting og multicast-trafikk innkapslet i en unicast-pakke som kan behandles Av IPSec, noe som gjør dynamisk ruting mulig mellom jevnaldrende skilt av et usikkert nettverksområde.
du kan ganske enkelt være villig til å implementere IPSec hvis DU ønsker Å dra nytte AV GRE-styrker og er opptatt av personvern(husk AT GRE ikke krypterer trafikk). GRE-tunneler gir også et høyere nivå av elastisitet enn IKE keepalives faktisk gjør.
Ulemper
Selvfølgelig er det flere ulemper ved å bruke denne typen løsning, vurder følgende før du får tak i tekniske ting:
- Bruke GRE bruker båndbredde og påvirker forestillinger. Legge til kryptering kan enda mer endre behandlingsressurser og øke nettverksforsinkelsen. Sørg for at infrastrukturen din støtter det.
- ACL-oppføringer må vedlikeholdes manuelt, noe som kan bli kjedelig for mellomstore bedrifter.
- Bruk Av PUNKT-til-Punkt GRE-Over-IPSec-tunneler skalerer ikke godt. Hvis du planlegger å legge til flere eksterne nettsteder, bør du vurdere å implementere andre løsninger som DMVPN, som dynamisk bygger tunneler mellom eksterne jevnaldrende mens du reduserer administrative administrasjonsoppgaver.
2- Implementering
Merk: for å dra nytte Av IPSec crypto-funksjoner, sørg FOR AT IOS-versjonen støtter dem. Du kan bruke Verktøyet Cisco Feature Navigator for å få en fullstendig liste over støttede funksjoner på http://www.cisco.com/go/fn
Ike Phase 1
IPSec-alternativene som brukes av effektiv kommunikasjon, er definert i et transformasjonssett. I dette konfigurasjonseksemplet bruker VI BÅDE AH og ESP med aes for kryptering, OG SHA for respektive integritetskontroller:
| Gren-1 | Gren-2 |
|
crypto ipsec transform-sett STERK ah-sha-hmac esp-aes 256 esp-sha-hmac crypto kart IPSEC_MAP 10 ipsec-isakmp ip-tilgang-liste utvidet IPSEC_ACL Grensesnitt Serial0 / 0 |
crypto ipsec transform-sett STERK ah-sha-hmac esp-aes 256 esp-sha-hmac crypto kart IPSEC_MAP 10 ipsec-isakmp ip-tilgang-liste utvidet IPSEC_ACL grensesnitt serial0/1 |
den interessante trafikken som må krypteres gjennom tunnelen, er trafikken som samsvarer MED IPSEC_ACL. Nå kan vi bare gruppere alle tunnelens alternativer til et kryptokart, ved å definere den eksterne peer-adressen oghvilken trafikk må krypteres av hvilket spesifikt transformasjonssett. Isakmp-politikken er ikke spesifisert i kryptokartet siden den er relatert til isakmp fase 1 og forhandlet avhengig av hvert endepunkts konfigurasjon.
IPSEC_ACL må speiles mellom de 2 endepunktene. For ord, trafikken du trenger å kryptere må aksepteres på den andre siden. Som et resultat, bare bytte kilde og destinasjon seksjoner for hver oppføring på begge rutere. Du vil legge merke til at vi matcher trafikk som går ut av det fysiske grensesnittet: VI spesifiserer GRE som trafikktype Og kilde / destinasjonsadressene Til Tunnelen
endelig blir kryptokartet brukt på det fysiske grensesnittet. Vær oppmerksom på at bruk av kartet på Tunnelgrensesnittet kanskje ikke fungerer som forventet.
følgende loggmelding skal heves:
%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP ER på
Verifisering
du kan verifisere og feilsøke fase 1 OG 2 SA ved å utstede ‘vis crypto isakmp sa’ og ‘vis crypto ipsec sa’, henholdsvis.
Gren-1 (ISAKMP)
Gren-1#vis krypto isakmp sa
IPv4 Krypto Isakmp sa
dst src state conn-id slot status
203.0.0.6 203.0.0.2 QM_IDLE 1001 0 AKTIV
IPv6 Krypto Isakmp SA
den andre kommandoen kan bidra til å overvåke hvor mange pakker som har vært på reise Gjennom tunnelen:
Gren-1 (IPSec, utdrag)
Gren-1 # vis crypto ipsec sa
grensesnitt: Serial0/0
Crypto kart tag: IPSEC_MAP, lokal adr 203.0.0.2
beskyttet vrf: (ingen)
lokal ident (addr/maske/prot/port): (203.0.0.2/255.255.255.255/47/0)
ekstern ident (adr / maske / prot / port): (203.0.0.6/255.255.255.255/47/0)
current_peer 203.0.0.6 port 500
TILLATELSE, flagg={origin_is_acl,}
#pkts encaps: 4, #pkts kryptere: 4, #pkts fordøye: 4
#pkts decaps: 4, #pkts dekryptere: 4, #pkts verifisere: 4
#pkts komprimert: 0, #pkts dekomprimert: 0
#pkts ikke komprimert: 0, #pkts compr. mislyktes: 0
#pkts ikke dekomprimert: 0, # pkts dekomprimering mislyktes: 0
# send feil 1, # recv feil 0
Hvis vi tar en titt på hvordan pakker ser ut:
Merk at pingen fra 10.0.1.1 til 10.0.2.1 reiser til destinasjonen som en innkapslet pakke som er godkjent (AH) og kryptert (ESP) i henhold til innstillingene som er konfigurert ovenfor.
Merk: noe interessant trafikk må genereres før tunnelen er i full drift. Hvis du jobber med et laboratoriemiljø, kan du snif ISAKMP-trafikken og observere hvordan utvekslingsprosessen fungerer.
denne artikkelen er ment å dele kunnskap. Hvis du finner noe som mangler, eller som bør forbedres, vil jeg gjerne legge til slik informasjon.