1-Inleiding
laten we onze discussie over GRE tunnels voortzetten. Als je het artikel met betrekking tot GRE niet hebt gelezen, zou ik raden u een kijkje nemen op de “stap-voor-stap : begrip GRE Tunnels” artikel.
in deze sectie zullen we de topologie verbeteren die we in het vorige bericht hebben gebouwd, door een beveiligingslaag met IPSec toe te voegen.
ter herinnering, we hebben al de volgende infrastructuur opgezet:
- een eenvoudige GRE tunnel tussen Branch-1 en Branch-2 met hun respectievelijke seriële interface als eindpunten.
waarom GRE over IPSec gebruiken in plaats van pure IPSec-tunnels?Er zijn verschillende voordelen van het gebruik van GRE-tunnels naast IPSec, voornamelijk omdat IPSec geen ander verkeer dan unicast ondersteunt. Dit kan tot problemen leiden als u van plan bent services te gebruiken die een dergelijk type verkeer vereisen, zoals routeringsprotocollen zoals OSPF of EIGRP.
dankzij het GRE-encapsulatieproces worden broadcast-en multicast-verkeer ingekapseld in een unicast-pakket dat door IPSec kan worden behandeld, waardoor dynamische routing mogelijk is tussen peers gescheiden door een onveilig netwerkgebied.
u kunt gewoon bereid zijn om IPSec te implementeren als u wilt profiteren van GRE sterke punten en bent betrokken bij privacy (vergeet niet dat GRE geen verkeer versleutelt). Ook, GRE tunnels bieden een hoger niveau van veerkracht dan IKE keepalives eigenlijk doen.
nadelen
natuurlijk zijn er verschillende nadelen van het gebruik van dit soort oplossingen, overweeg het volgende voordat u technische zaken in handen krijgt:
- het gebruik van GRE verbruikt bandbreedte en beïnvloedt prestaties. Het toevoegen van encryptie kan de verwerkingsbronnen nog meer veranderen en de netwerk latency verhogen. Zorg ervoor dat uw infrastructuur het ondersteunt.
- ACL-gegevens moeten handmatig worden bijgehouden, wat vervelend kan worden voor middelgrote ondernemingen.
- het gebruik van punt-tot-punt GRE-over-IPSec-tunnels schaalt niet goed. Als u van plan bent meerdere externe sites toe te voegen, kunt u overwegen andere oplossingen te implementeren, zoals DMVPN, dat dynamisch tunnels bouwt tussen externe peers en tegelijkertijd de beheertaken vermindert.
2- implementatie
OPMERKING: Om te profiteren van IPSec crypto-functies, zorg ervoor dat uw iOS-versie deze ondersteunt. U kunt het hulpprogramma Cisco Feature Navigator gebruiken om een volledige lijst te krijgen van de ondersteunde functies op http://www.cisco.com/go/fn
Ike Fase 1
de IPSec-opties die worden gebruikt voor effectieve communicatie zijn gedefinieerd in een transformatieset. In deze configuratie voorbeeld gebruiken we zowel AH en ESP met AES-encryptie, en SHA voor de betreffende integriteit controleert:
| Tak-1 | Tak-2 |
|
crypto ipsec-transform-set STERKE ah-sha-hmac-esp-aes 256-esp-sha-hmac crypto map IPSEC_MAP 10 ipsec-isakmp ip-toegang-lijst uitgebreid IPSEC_ACL Interface Serial0/0 |
crypto ipsec-transform-set STERKE ah-sha-hmac-esp-aes 256-esp-sha-hmac crypto map IPSEC_MAP 10 ipsec-isakmp ip-toegang-lijst uitgebreid IPSEC_ACL Interface Serial0/1 |
Het interessante van het verkeer dat moet worden gecodeerd door de tunnel is het verkeer dat overeenkomt met de IPSEC_ACL. Nu kunnen we eenvoudig alle opties van de tunnel groeperen in een crypto-map, door het bepalen van het externe peer-adres en welk verkeer moet worden gecodeerd door welke specifieke transformatieset. Het ISAKMP-beleid wordt niet gespecificeerd in de crypto-map, omdat het gerelateerd is aan ISAKMP fase 1 en wordt onderhandeld afhankelijk van de configuratie van elk eindpunt.
de IPSEC_ACL moet gespiegeld worden tussen de 2 eindpunten. In volgorde woorden, het verkeer dat u moet versleutelen moet worden geaccepteerd aan de andere kant. Als gevolg daarvan, gewoon schakelen de bron en bestemming secties voor elke ingang op beide routers. U zult merken dat we het verkeer dat de fysieke interface verlaat matchen: we specificeren GRE als het verkeerstype en de bron / bestemmingsadressen van de Tunnel
tenslotte wordt de crypto-map toegepast op de fysieke interface. Merk op dat het toepassen van de kaart op de Tunnelinterface mogelijk niet werkt zoals verwacht.
het volgende Logbericht moet worden weergegeven:
% CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is op
verificatie
u kunt de fase 1 en 2 SA verifiëren en oplossen door respectievelijk ’toon crypto ISAKMP sa’ en ’toon crypto ipsec sa’ uit te geven.
Branch-1 (ISAKMP)
Tak-1#toon crypto-isakmp sa
IPv4 Crypto-ISAKMP SA
dst src staat conn-id slot status
203.0.0.6 203.0.0.2 QM_IDLE 1001 0 ACTIEF
IPv6 Crypto-ISAKMP SA
De tweede opdracht kan helpen bij het controleren van hoeveel pakketten zijn reizen door de tunnel:
Tak-1 (IPSec, uittreksel)
Tak-1#toon crypto ipsec sa
interface Serial0/0
Crypto map tag: IPSEC_MAP, lokale addr 203.0.0.2
beveiligde vrf: (geen)
lokale ident (addr/masker/winst/de haven): (203.0.0.2/255.255.255.255/47/0)
externe ident (addr/masker/winst/de haven): (203.0.0.6/255.255.255.255/47/0)
current_peer 203.0.0.6 poort 500
TOESTAAN, vlaggen={origin_is_acl,}
#pkts encaps: 4, #pkts coderen: 4, #pkts digest: 4
#pkts decaps: 4, #pkts decoderen: 4, #pkts controleren: 4
#pkts gecomprimeerde: 0, #pkts gedecomprimeerd: 0
#pkts niet gecomprimeerd: 0, #pkts compr. mislukt: 0
# pkts niet gedecomprimeerd: 0, # pkts decomprimeren mislukt: 0
# send errors 1, # recv errors 0
als we kijken hoe pakketjes eruit zien:
merk op dat de ping van 10.0.1.1 tot 10.0.2.1 naar zijn bestemming reist als een ingekapseld pakket dat is geverifieerd (AH) en versleuteld (ESP) volgens de Instellingen hierboven geconfigureerd.
Opmerking: Er moet interessant verkeer worden gegenereerd voordat de tunnel volledig operationeel is. Als u werkt aan een lab omgeving, kunt u snif het ISAKMP verkeer en observeren hoe het uitwisselingsproces werkt.
dit artikel is bedoeld om kennis te delen. Als u merkt dat er iets ontbreekt, of dat verbeterd moet worden, voeg ik daar graag dergelijke informatie aan toe.