1-Introduktion
låt oss fortsätta vår diskussion om GRE tunnlar. Om du inte läste artikeln relaterad till GRE rekommenderar jag att du tittar på artikeln ”steg-för-steg : förstå gre-tunnlar”.
i det här avsnittet kommer vi att förbättra topologin vi byggde i föregående inlägg genom att lägga till ett säkerhetslager med IPSec.
som en påminnelse har vi redan satt upp följande Infrastruktur:
- en enkel gre tunnel mellan Branch – 1 och Branch-2 med sina respektive seriella gränssnitt som slutpunkter.
varför använda GRE över IPSec istället för rena IPSec-tunnlar?
det finns flera fördelar med att använda gre-tunnlar tillsammans med IPSec, främst eftersom IPSec inte stöder annan trafik än unicast. Detta kan leda till problem om du planerar att använda tjänster som kräver sådan typ av trafik, till exempel routingprotokoll som OSPF eller EIGRP.
tack vare gre-inkapslingsprocessen är sändning och multicast-trafik inkapslad i ett unicast-paket som kan behandlas av IPSec, vilket gör dynamisk routing möjlig mellan kamrater åtskilda av ett osäkert nätverksområde.
du kan helt enkelt vara villig att implementera IPSec om du vill dra nytta av GRE-styrkor och handlar om integritet (kom ihåg att GRE inte krypterar trafik). Gre-tunnlar ger också en högre nivå av elasticitet än IKE keepalives faktiskt gör.
nackdelar
naturligtvis finns det flera nackdelar med att använda denna typ av lösning, överväga följande innan du får tag på tekniska saker:
- att använda GRE förbrukar bandbredd och påverkar prestanda. Att lägga till kryptering kan ännu mer förändra bearbetningsresurser och öka nätverksfördröjningen. Se till att din infrastruktur kommer att stödja den.
- ACL-poster måste underhållas manuellt, vilket kan bli tråkigt för medelstora företag.
- att använda punkt-till-punkt gre-over-IPSec-tunnlar skalar inte bra. Om du planerar att lägga till flera fjärrwebbplatser kan du överväga att implementera andra lösningar som DMVPN, som dynamiskt bygger tunnlar mellan fjärranslutna kamrater samtidigt som de administrativa hanteringsuppgifterna minskas.
2- implementering
Obs: För att dra nytta av IPSec crypto funktioner, se till att din IOS-version stöder dem. Du kan använda verktyget Cisco Feature Navigator för att få en fullständig lista över de funktioner som stöds på http://www.cisco.com/go/fn
Ike Phase 1
IPSec-alternativen som används av effektiv kommunikation definieras i en transform-uppsättning. I det här konfigurationsexemplet använder vi både AH och ESP med AES för kryptering och SHA för respektive integritetskontroller:
| gren-1 | gren-2 |
|
crypto ipsec transform-set STRONG ah-sha-hmac esp-aes 256 esp-sha-hmac crypto map IPSEC_MAP 10 ipsec-isakmp ip access-lista utökad IPSEC_ACL gränssnitt Serial0 / 0 |
crypto ipsec transform-set STRONG ah-sha-hmac esp-aes 256 esp-sha-hmac crypto map IPSEC_MAP 10 ipsec-isakmp ip access-lista utökad IPSEC_ACL gränssnitt serial0/1 |
den intressanta trafiken som måste krypteras genom tunneln är den trafik som matchar IPSEC_ACL. Nu kan vi helt enkelt gruppera alla tunnelens alternativ till en kryptokarta genom att definiera fjärransluten peer-adress ochvilken trafik måste krypteras med vilken specifik transformationsuppsättning. Isakmp-policyn anges inte i kryptokartan eftersom den är relaterad till isakmp-fas 1 och förhandlas beroende på varje slutpunkts konfiguration.
IPSEC_ACL måste speglas mellan de 2 slutpunkterna. För ord måste trafiken du behöver kryptera accepteras på andra sidan. Som ett resultat byter du bara käll-och destinationsavsnitten för varje post på båda routrarna. Du kommer att märka att vi matchar trafik som lämnar det fysiska gränssnittet: vi anger GRE som trafiktyp och käll- / destinationsadresserna för tunneln
slutligen tillämpas kryptokartan på det fysiska gränssnittet. Observera att det kanske inte fungerar som förväntat att använda kartan på tunnelgränssnittet.
följande loggmeddelande bör höjas:
%CRYPTO-6-isakmp_on_off: ISAKMP är på
verifiering
du kan verifiera och felsöka fas 1 och 2 SA genom att utfärda ’visa crypto isakmp sa’ respektive ’visa crypto ipsec sa’.
gren-1 (Isakmp)
Branch-1#Visa crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
203.0.0.6 203.0.0.2 QM_IDLE 1001 0 aktiv
IPv6 Crypto ISAKMP SA
det andra kommandot kan hjälpa till att övervaka hur många paket har rest genom tunneln:
gren-1 (IPSec, utdrag)
Branch-1 # Visa crypto ipsec sa
gränssnitt: Serial0/0
Crypto karta tagg: IPSEC_MAP, lokal addr 203.0.0.2
skyddad vrf: (ingen)
lokal ident (addr/mask/prot/port): (203.0.0.2/255.255.255.255/47/0)
fjärr ident (addr / mask / prot / port): (203.0.0.6/255.255.255.255/47/0)
current_peer 203.0.0.6 port 500
tillstånd, flaggor={origin_is_acl,}
#pkts encaps: 4, #pkts kryptera: 4, #pkts digest: 4
#pkts decaps: 4, #pkts dekryptera: 4, #pkts verifiera: 4
#pkts komprimerad: 0, #pkts dekomprimerad: 0
#pkts inte komprimeras: 0, #pkts compr. misslyckades: 0
#pkts inte dekomprimerad: 0, #pkts dekomprimering misslyckades: 0
# skicka fel 1, # recv-fel 0
om vi tittar på hur paket ser ut:
Observera att ping från 10.0.1.1 till 10.0.2.1 reser till sin destination som ett inkapslat paket som är autentiserat (AH) och krypterat (ESP) enligt inställningarna som konfigurerats ovan.
Obs: en del intressant trafik måste genereras innan tunneln är i full drift. Om du arbetar med en labbmiljö kan du snif isakmp-trafiken och observera hur utbytesprocessen fungerar.
denna artikel är avsedd att dela kunskap. Om du hittar något som saknas, eller som bör förbättras, skulle jag gärna lägga till sådan information.