1 – Introduzione
Continuiamo la nostra discussione sui tunnel GRE. Se non hai letto l’articolo relativo a GRE, ti consiglio di dare un’occhiata all’articolo “Step-by-Step : Understanding GRE Tunnels”.
In questa sezione miglioreremo la topologia che abbiamo costruito nel post precedente, aggiungendo un livello di sicurezza con IPSec.
Come promemoria, abbiamo già impostato la seguente infrastruttura:
- Un semplice tunnel GRE tra Branch-1 e Branch-2 con la rispettiva interfaccia seriale come endpoint.
Perché utilizzare GRE su IPSec invece di tunnel IPSec puri?
Ci sono diversi vantaggi nell’utilizzo dei tunnel GRE insieme a IPSec, principalmente perché IPSec non supporta il traffico diverso da unicast. Questo può portare a problemi se si prevede di utilizzare servizi che richiedono tale tipo di traffico, come protocolli di routing come OSPF o EIGRP.
Grazie al processo di incapsulamento GRE, il traffico broadcast e multicast sono incapsulati in un pacchetto unicast che può essere trattato da IPSec, rendendo possibile il routing dinamico tra peer separati da un’area di rete non sicura.
Potresti semplicemente essere disposto a implementare IPSec se desideri beneficiare dei punti di forza di GRE e sei interessato alla privacy (ricorda che GRE non crittografa il traffico). Inoltre, i tunnel GRE forniscono un livello più elevato di resilienza rispetto ai keepalives IKE.
Svantaggi
Naturalmente, ci sono diversi svantaggi nell’utilizzo di questo tipo di soluzione, considerare quanto segue prima di mettere le mani su cose tecniche:
- L’utilizzo di GRE consuma larghezza di banda e influisce sulle prestazioni. L’aggiunta di crittografia può ancora più alterare le risorse di elaborazione e aumentare la latenza di rete. Assicurati che la tua infrastruttura lo supporti.
- Le voci ACL devono essere mantenute manualmente, il che può diventare noioso per le aziende di medie e grandi dimensioni.
- L’utilizzo di tunnel GRE-over-IPSec Point-to-Point non è scalabile. Se si prevede di aggiungere più siti remoti, considerare l’implementazione di altre soluzioni come DMVPN, che crea dinamicamente tunnel tra peer remoti riducendo le attività di gestione amministrativa.
2- Implementazione
Nota: per beneficiare delle funzionalità di crittografia IPSec, assicurati che la tua versione IOS le supporti. È possibile utilizzare lo strumento Cisco Feature Navigator per ottenere un elenco completo delle funzionalità supportate inhttp://www.cisco.com/go/fn
IKE Phase 1
Le opzioni IPSec utilizzate dalle comunicazioni efficaci sono definite in un set di trasformazioni. In questa configurazione, per esempio, usiamo AH ed ESP con AES per la crittografia, e SHA per i rispettivi controlli di integrità:
| Ramo-1 | Ramo-2 |
|
crittografia ipsec trasformare-set di FORTE ah-sha-hmac esp-aes a 256 esp-sha-hmac crypto map IPSEC_MAP 10 ipsec-isakmp ip access-list extended IPSEC_ACL Interface Serial0/0 |
crittografia ipsec trasformare-set di FORTE ah-sha-hmac esp-aes a 256 esp-sha-hmac crypto map IPSEC_MAP 10 ipsec-isakmp ip access-list extended IPSEC_ACL Interface Serial0/1 |
L’interessante di traffico che devono essere crittografati attraverso il tunnel è il traffico che corrisponde all’IPSEC_ACL. Ora possiamo semplicemente raggruppare tutte le opzioni del tunnel in una cripto-mappa, definendo l’indirizzo peer remoto e il traffico che deve essere crittografato da quale set di trasformazioni specifico. Il criterio ISAKMP non è specificato nella crypto-map poiché è correlato alla fase 1 di ISAKMP e negoziato in base alla configurazione di ciascun endpoint.
L’IPSEC_ACL deve essere rispecchiato tra i 2 endpoint. In parole d’ordine, il traffico è necessario crittografare deve essere accettato dall’altra parte. Di conseguenza, è sufficiente cambiare le sezioni di origine e di destinazione per ogni voce su entrambi i router. Noterai che corrispondiamo al traffico in uscita dall’interfaccia fisica: specifichiamo GRE come tipo di traffico e gli indirizzi di origine / destinazione del Tunnel
Infine, la crypto-map viene applicata sull’interfaccia fisica. Si noti che l’applicazione della mappa sull’interfaccia del tunnel potrebbe non funzionare come previsto.
Dovrebbe essere generato il seguente messaggio di log:
%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP è ATTIVO
Verifica
È possibile verificare e risolvere i problemi della fase 1 e 2 SA emettendo rispettivamente “show crypto isakmp sa” e “show crypto ipsec sa”.
Ramo-1 (ISAKMP)
Ramo-1#mostra crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst, src stato conn-id slot status
203.0.0.6 203.0.0.2 QM_IDLE 1001 0 ACTIVE
IPv6 Crypto ISAKMP SA
Il secondo comando può aiutare a monitorare quanti pacchetti sono stati in viaggio attraverso il tunnel:
Filiale di 1 (IPSec, estratto)
Ramo-1#mostra di crittografia ipsec sa
interfaccia: Serial0/0
Crypto map tag: IPSEC_MAP, locale addr 203.0.0.2
protetto vrf: (nessuno)
locale ident (ind/maschera/prot/porta): (203.0.0.2/255.255.255.255/47/0)
remoto ident (ind/maschera/prot/porto): (203.0.0.6/255.255.255.255/47/0)
current_peer 203.0.0.6 porta 500
PERMESSO, flag={origin_is_acl,}
#pkts encaps: 4, #pkts cifrare: 4, #pkts digest: 4
#pkts decaps: 4, #pkts decifrare: 4, #pkts verificare: 4
#pkts compressi: 0, #pkts decompresso: 0
#pkts non compressi: 0, #pkts compr. non riuscito: 0
#pkts non decompresso: 0, # pkts decompresso non riuscito: 0
#invia errori 1, # errori recv 0
Se diamo un’occhiata a come appaiono i pacchetti:
Si noti che il ping da 10.0.1.1 a 10.0.2.1 viaggia a destinazione come un pacchetto incapsulato autenticato (AH) e crittografato (ESP) in base alle impostazioni configurate sopra.
Nota: è necessario generare traffico interessante prima che il tunnel sia pienamente operativo. Se si sta lavorando su un ambiente di laboratorio, è possibile snif il traffico ISAKMP e osservare come funziona il processo di scambio.
Questo articolo ha lo scopo di condividere la conoscenza. Se trovate qualcosa che manca, o che dovrebbe essere migliorato, sarei lieto di aggiungere tali informazioni.