Nota:

Questa esercitazione richiede l'accesso a Oracle Cloud. Per iscriversi a un account gratuito, consulta Inizia a utilizzare Oracle Cloud Infrastructure Free Tier.
Utilizza valori di esempio per le credenziali, la tenancy e i compartimenti di Oracle Cloud Infrastructure. Al termine del laboratorio, sostituisci questi valori con quelli specifici del tuo ambiente cloud.

Utilizzare il servizio VPN da sito a sito di Oracle Cloud Infrastructure in modalità HA con instradamento ECMP da Linux e Libreswan

Introduzione

Nel mondo interconnesso di oggi, è fondamentale garantire la disponibilità e la sicurezza dei dati trasmessi tra le reti. Per soddisfare questa esigenza fondamentale, Oracle Cloud offre efficaci funzionalità di networking, inclusa la possibilità di creare tunnel IPSec ad alta disponibilità. Questa esercitazione descrive il concetto di tunnel IPSec ad alta disponibilità e ti guiderà nel processo di impostazione di un'architettura di rete resiliente in Oracle Cloud mediante il protocollo ECMP (Equaal-cost Multi-path).

In questa esercitazione ci concentreremo sull'utilizzo di Oracle Linux, un sistema operativo potente e sicuro ottimizzato per gli ambienti Oracle Cloud, insieme a Libreswan, un client IPSec ben consolidato, per stabilire tunnel IPSec in modalità route-based. Sfrutteremo la funzionalità del gateway di instradamento dinamico (DRG) fornita da Oracle Cloud Infrastructure (OCI) per consentire failover e bilanciamento del carico trasparenti tra più tunnel IPSec.

Obiettivi

Fornire una guida completa per l'implementazione di tunnel IPSec in OCI utilizzando il protocollo di instradamento ECMP per il traffico di bilanciamento del carico lungoli nello scenario attivo/attivo.

Informazioni di base del protocollo IPSec Site-To-Site
Comprendere le varie modalità IPSec: trasporto e tunnel, basate su criteri e instradamento
Configura Libreswan in Oracle Linux con bilanciamento del carico ECMP
Configurare DRGv2 per i tunnel IPSec ridondanti
Eseguire il test della ridondanza e del bilanciamento del carico dei tunnel con Iperf3

Seguendo questa esercitazione, si avrà una conoscenza completa di IPSec in OCI. Potrai acquisire le competenze necessarie per interconnettere in modo efficace l'infrastruttura on premise con OCI tramite una connessione ridondante.

Prerequisiti

Una tenancy OCI attiva. È necessario disporre delle autorizzazioni necessarie per creare e gestire le risorse di rete in OCI.
Una comprensione di base del sistema operativo Linux, dei concetti di networking e OCI. Ciò include una certa familiarità con concetti fondamentali di rete come l'indirizzamento IP, la sottorete, il routing e il firewall.
Una comprensione di base di Oracle Linux, incluso come installare e configurare. Se non hai esperienza con Oracle Linux, puoi seguire un'esercitazione o una guida di base su Oracle Linux in anticipo.
Una rete cloud virtuale (VCN) e una o più subnet impostate in OCI, con le regole di instradamento appropriate, il gateway Internet, il DRG e le liste di sicurezza configurate.
Una buona comprensione di come utilizzare la console o l'interfaccia CLI OCI per creare e gestire le risorse di rete.

Nota: si consiglia di impostare un ambiente di test in OCI per provare le configurazioni di rete e IPSec prima di implementarle in un ambiente di produzione.

Che cos'è IPSec VPN

La sicurezza del protocollo Internet (IPSec) è una struttura di standard aperti che consente di garantire comunicazioni private e sicure su reti IP (Internet Protocol) utilizzando servizi di sicurezza crittografica. IPSec supporta l'integrità dei dati a livello di rete, la riservatezza dei dati, l'autenticazione dell'origine dei dati e la protezione della replica. Poiché IPSec è integrato a livello Internet (layer 3), garantisce la sicurezza per quasi tutti i protocolli nella suite TCP/IP e poiché IPSec è applicato in modo trasparente alle applicazioni, non è necessario configurare la sicurezza separata per ciascuna applicazione che utilizza TCP/IP.

IPSec aiuta a fornire una difesa approfondita contro gli attacchi basati sulla rete da computer non sicuri, attacchi che possono provocare la negazione del servizio di applicazioni, servizi o rete.

Dati danneggiati
Furto dati
Furto personale
Controllo amministrativo di server, altri computer e la rete.

VPN da sito a sito

Una VPN IPSec (Internet Protocol Security) site-to-site, nota anche come VPN da rete a rete, stabilisce una connessione sicura e cifrata tra due o più reti tramite Internet. Consente la trasmissione sicura di dati tra siti distribuiti in varie aree geografiche, creando una rete privata virtuale (VPN) che estende la portata della rete oltre i suoi confini fisici.

In una rete IPSec VPN site-to-site, le reti partecipanti, solitamente appartenenti a organizzazioni diverse o rami remoti della stessa organizzazione, sono connesse tramite tunnel IPSec dedicati. Questi tunnel incapsulano e cifra il traffico di rete, garantendo la riservatezza, l'integrità e l'autenticità mentre attraversano reti non sicure, come Internet.

D'altra parte, una VPN point-to-site (P2S) stabilisce una connessione sicura tra i singoli dispositivi client e una rete remota. A differenza delle VPN site-to-site, che connettono le reti, le VPN P2S consentono l'accesso remoto sicuro per i singoli dispositivi per accedere alle risorse di rete. Le VPN P2S vengono in genere utilizzate per consentire l'accesso sicuro a dipendenti remoti, collaboratori esterni o utenti mobili che devono connettersi alla rete dell'organizzazione da sedi esterne.

Nota: questo ambito di esercitazione è limitato a IPSec VPN da sito a sito che è attualmente l'unico supportato in OCI DRGv2.

Concetti sui tunnel VPN IPSec

IPSec indica Internet Protocol Security o IP Security. IPSec è una suite di protocolli che cifra l'intero traffico IP prima che i pacchetti vengano trasferiti dal nodo di origine alla destinazione. IPSec può essere configurato in due modalità:

Modalità di trasporto: IPSec cifra e/o autentica solo il payload effettivo del pacchetto e le informazioni sull'intestazione rimangono invariate.
Modalità tunnel: IPSec cifra e/o autentica l'intero pacchetto. Dopo la cifratura, il pacchetto viene quindi incapsulato per formare un nuovo pacchetto IP UDP con informazioni di intestazione diverse.

I tunnel site-to-site IPSec VPN offrono i seguenti vantaggi:

Non è necessario acquistare linee di leasing costose dedicate da un sito all'altro, poiché le linee di telecomunicazione pubbliche sono utilizzate per trasmettere i dati.
Gli indirizzi IP interni delle reti e dei nodi partecipanti sono nascosti agli utenti esterni.
L'intera comunicazione tra i siti di origine e destinazione è crittografata, riducendo significativamente le possibilità di furto di informazioni. OCI supporta solo la modalità tunnel della VPN IPSec e viene offerta come self-service utilizzando la console Web.

Nota: la VPN da sito a sito OCI supporta solo la modalità tunnel, pertanto sarà l'unica modalità disponibile in OCI.

Architettura

OCI IPSec con ECMP è costituito da liste che includono:

DRGv2 collegato a VCN1 e VCN2 utilizzando tabelle di instradamento predefinite e tabelle di instradamento generate automaticamente RT2 "Tabella di instradamento Drg generata automaticamente per allegati VCN" nell'area Francoforte.
Stesso valore DRGv2 con una connessione IPSec che include due tunnel:
- tunnel 1, indirizzo IP VPN Oracle 193.122.x.x con tabella di instradamento generata automaticamente RT1 "Tabella di instradamento Drg generata automaticamente per collegamenti RPC, VC e IPSec".
- tunnel 2, indirizzo IP Oracle VPN 158.101.x.x con tabella di instradamento generata automaticamente RT1 "Tabella di instradamento Drg generata automaticamente per collegamenti RPC, VC e IPSec".
Una VM Oracle Linux come client IPSec con supporto ECMP da on premise, in esecuzione nell'intervallo CIDR privato 192.168.0.0/16, IP pubblico 143.47.48.219.
Iperf3 in Oracle Linux in locale come client e come server in Oracle OCI.
CPE configurato come Libreswan con IP pubblico 143.47.x.x.
ECMP ha abilitato Oracle Linux 8 e il lato OCI.

Task 1: Configura impostazioni OCI

Per questa esercitazione, abbiamo creato un'istanza VM Oracle Linux 7 e installato Libreswan 3.25 su di essa. Per installare Libreswan in Linux, è possibile seguire la seguente documentazione Oracle: Accesso ad altri cloud con Libreswan. È possibile installare Libreswan nell'ambiente desiderato. Per questa esercitazione, abbiamo scelto un'altra area remota in OCI come client Libreswan e responsabile avvio del tunnel.

Dopo aver installato Libreswan (senza aver ancora configurato), prendere nota dell'IP pubblico della VM Linux 7 nonché dell'intervallo CIDRIPv4 CIDR IPv4 privato in cui è stato installato Libreswan.

Configurare le impostazioni OCI

Eseguire il login alla console OCI e andare alla scheda Networking per creare VCN1 e VCN2, come descritto di seguito. Creare la VCN.
Creare VCN1 con CIDR 10.0.0.0/16 e due subnet: Subnet A 10.0.1.0/24 e subnet B 10.0.0.0/24.
Creare VCN2 con CIDR 172.20.0.0/16 e due subnet: Subnet C 172.20.1.0/24 e subnet D 172.20.2.0/24.
Creare le VM nelle subnet di destinazione in OCI per eseguire il test dei tunnel IPSec. In questa esercitazione sono state create 3 VM (origin1, origin2 e origin3).
Ora creiamo un DRG in Networking, connettività cliente, gateway di instradamento dinamico.
Una volta creato il gateway DRG, sarà necessario creare un collegamento alla rete cloud virtuale sia a VCN1 che a VCN2.
- Una volta creati, avremo due collegamenti di rete (uno per ogni VCN) che connettono entrambi i VCN al DRG con una tabella di instradamento DRG AutoGenerated per i collegamenti VCN (tabella di instradamento RT2 nell'architettura principale).
- In questa tabella di instradamento verrà indicato a DRG dove inviare/instradare il traffico in entrata dai VCN appena collegati: qualsiasi traffico indirizzato a "CIDR di destinazione" verrà inviato/instradato al collegamento hop successivo come indicato di seguito:
- In un secondo momento, quando creeremo tunnel IPSec, avremo una tabella di instradamento generata automaticamente simile per il traffico in entrata da ambienti on premise tramite il tunnel IPSec.
Ora, creiamo la connettività IPSec. Prima di creare IPSec, sarà necessario creare il CPE (Customer-Premises Equipment) che rappresenta il dispositivo in locale che si connette a OCI tramite IPSec, in Networking, connettività del cliente, apparecchiatura in locale del cliente, Crea CPE:
- X.X.X.X deve essere l'indirizzo IP PUBLIC dal quale si sta connettendo il dispositivo in locale. NON confondere con l'indirizzo IP privato assegnato al computer Oracle Linux Libreswan installato nei passi precedenti. Molto probabilmente la tua VM Oracle Linux sarà dietro NAT (non sarà proprietaria direttamente dell'IP pubblico). Se non conosci l'indirizzo IP pubblico, puoi sempre eseguire il comando seguente dalla console Linux per scoprire: curl ifconfig.co.
- Per questa esercitazione, scegliere Vendor Libreswan versione 3.18 o successiva.
Andare a Networking, Connettività del cliente, VPN Site-to-Site, Crea connessione IPSec e fornire i dettagli riportati di seguito.

Nota: è possibile utilizzare la Creazione guidata VPN, ma non rientra nell'ambito di questa esercitazione.
- Nome della configurazione IPSec
- Crea nel compartimento: il compartimento in uso
- Apparecchiatura in locale del cliente nel compartimento: scegliere il dispositivo CPE creato nel passo precedente
  - Questo CPE si trova dietro un dispositivo NAT: ciò influirà direttamente su come l'ID Internet Key Exchange (IKE) sarà "presentato" in OCI da on premise. Si supponga che Libreswan sia in esecuzione dietro NAT, se si desidera utilizzare l'IP privato da cui Libreswan è in esecuzione come ID IKE, contrassegnare questa opzione. Altrimenti, se si desidera utilizzare l'IP pubblico da cui si connette Libreswan, non contrassegnare questa opzione. Configurare questo ID IKE in un secondo momento dalla configurazione Libreswan.
- Compartimento del gateway di instradamento dinamico: scegliere il DRG configurato nei passi precedenti.
- Percorsi alla rete on premise: l'instradamento dinamico non rientra nell'ambito di questa esercitazione. Ci concentreremo su ECMP per il bilanciamento del carico e la ridondanza, utilizzando la configurazione IPSec basata su instradamento. Aggiungeremo qui manualmente/staticamente gli instradamenti/CIDRS on premise che vogliamo raggiungere da OCI a on premise. Per questa esercitazione utilizziamo la versione 192.168.0.0/16 come CIDR on premise.
  - Tunnel 1:
    - Nome
    - Fornire il segreto condiviso del cliente: è possibile utilizzare la propria chiave precondivisa IKE (password) o lasciarla vuota in modo che OCI ne scelga una (la utilizzeremo in seguito durante l'impostazione di Libreswan)
    - Versione IKE: per questa esercitazione si utilizzerà IKEv1
    - Tipo di instradamento: per questa esercitazione verrà utilizzato l'instradamento statico per la configurazione IPSec basata su instradamento, quindi scegliere "Instradamento statico"
    - IPv4 all'interno dell'interfaccia tunnel - CPE e Oracle: lasciare vuota questa opzione
    - Indirizzamento IPv6: lasciare vuoto il campo in quanto IPv6 non rientra nell'ambito di questa esercitazione
  - Tunnel 2: compilare il tunnel 2 nello stesso modo del tunnel 1 (versione IKE, tipo di instradamento e così via).
- Fare clic su Crea connessione IPSec. Se tutto va bene, dopo alcuni minuti dovrebbe essere in esecuzione una configurazione IPSec con due tunnel per la ridondanza.
- Ora che abbiamo il gateway DRG e IPSec, dobbiamo assicurarci che ogni traffico proveniente da VCN in OCI verso le soluzioni on-premise raggiunga il gateway DRG. Una volta raggiunto il gateway DRG, il traffico sarà tunnel verso le soluzioni on premise tramite i due tunnel IPSec recentemente configurati. A tale scopo, abbiamo bisogno di aggiungere il CIDR in locale come regola di instradamento per ogni tabella di instradamento della subnet in VCN (abbiamo scelto la tabella di instradamento predefinita nell'esercitazione), il tipo di destinazione Gateway di instradamento dinamico, il tipo di destinazione Blocco CIDR, quindi aggiungere l'instradamento in locale, in questo caso 192.168.0.0/16.
Nota: il motivo per cui è necessario aggiungere questo instradamento è che OCI non dispone di un instradamento implicito per gli indirizzi CIDR all'esterno del realm VCN. Di conseguenza, dobbiamo aggiungere manualmente il blocco CIDR per assicurarci che il traffico raggiunga il gateway DRG.

Task 2: configurazione delle impostazioni Linux e Libreswan

Questa parte dell'esercitazione sarà incentrata sui passi di configurazione del sistema operativo Linux e di Libreswan. Il Libreswan installato in precedenza fungerà da responsabile avvio del tunnel da sito a sito e da DRG OCI come rispondente del tunnel.

Accedi al tuo sistema operativo Oracle Linux tramite SSH. Aumentare i privilegi per eseguire importanti comandi (admin)
- sudo su: diventerà utente root.
- Assicurarsi che Libreswan sia installato con la versione corretta: ipsec -version. Si dovrebbe vedere Libreswan versione 3.25 o successiva. In caso contrario, passare al task 1: configurazione delle impostazioni OCI e seguire le istruzioni per installare Libreswan.
- Vai alla cartella di configurazione: cd /etc.
- Libreswan memorizza tutta la configurazione dei tunnel nel file ipsec.conf. Utilizza il tuo editor di file preferito. "vi" è una buona opzione: vi ipsec.conf
  - Libreswan ipsec.conf:
    - conn [TunnelName1}: nome tunnel
    - type= tunnel (modalità tunnel)
    - authby=secret (l'autenticazione utilizzerà una passphrase segreta)
    - pfs=yes (Perfetta segretezza abilitata)
    - keyexchange=visualizzazione
    - leftid= n.n.n.n. (Si tratta dell'indirizzo IP pubblico da cui si connette Libreswan. Verrà utilizzato come identificativo ID IKE, a meno che non sia stata selezionata l'opzione 'CPE si trova dietro NAT' durante la creazione di IPSec. In tal caso, qualsiasi indirizzo IP o nome dominio completamente qualificato (FQDN) può essere impostato come identificativo)
    - leftsourceip= m.m.m. (Questo è l'IP privato assegnato a Libreswan, ad esempio 192.168.1.1)
    - leftsubnet= x.x.x.x/x (Il blocco CIDR assegnato a Libreswan, ad esempio 192.168.0.0/16)
    - right= y.y.y.y (Questo è l'indirizzo IP "Pubblico" della VPN OCI assegnato a tunnel1 durante la creazione di IPSec in Networking, connettività del cliente, VPN da sito a sito, YourIPSEC)
    - rightid= y.y.y.y (Questo è l'ID IKE inviato da OCI. In genere si tratta dell'indirizzo IP "Pubblico" della VPN OCI, in genere lo stesso parametro corretto)
    - leftsubnet=0.0.0.0/0 (Questo è il blocco CIDR che verrà inviato a OCI come parte del protocollo di negoziazione del selettore traffico SA Internet Key Exchange (IKEv2) 2.2.9. Ciò NON significa che tutto il traffico da OCI verrà instradato in locale. Ciò che viene eseguito da questo blocco CIDR, invece, determina quale traffico specifico verrà accettato, cifrato e ottimizzato tramite il tunnel IPSec. Il tunnel IPSec descritto qui sarà rappresentato da un'interfaccia virtuale denominata Virtual Tunnel Interface (VTI), che funge da interfaccia di rete virtuale (come una scheda di rete virtuale) che rappresenta il tunnel stesso. Diciamo che il VTI è chiamato vti01. Qualsiasi traffico instradato verso l'interfaccia vti01 diventerà parte del tunnel IPSec e verrà inviato in modo sicuro all'altra estremità della connessione. Questo approccio, in cui le decisioni di instradamento vengono prese in base al tunnel IPSec specifico e al VTI associato, è denominato instradamento basato su instradamento IPSec)
    - rightsubnet=0.0.0.0/0 (Lo stesso vale per il traffico accettato da OCI on premise)
    - mark=n/0xffffff (*opzione necessaria per l'uso con le interfacce VTI per contrassegnare i pacchetti incapsulati all'interno del tunnel IPSec associato a questa interfaccia VTI). Deve essere univoco in tutti i tunnel, ad esempio 5/0xffffffff*)
    - vti-interface=vtinn (*nome dell'interfaccia VTI, ad esempio vti01*)
    - vti-routing=no (Se gli instradamenti devono essere creati automaticamente nel dispositivo VTI. Scegliere NO perché non si desidera creare automaticamente un instradamento 0.0.0.0/0
    - encapsulation= yes/auto (yes forza il codice di rilevamento NAT a mentire e comunicare al peer remoto che l'incapsulamento di RFC-3948 (ESP nei pacchetti UDP della porta 4500). Automaticamente forzerà il rilevamento automatico NAT)
    - aggrmode= no
    - ike=aes_cbc256-sha2_384;modp1536 (algoritmo di cifratura/autenticazione IKE da utilizzare per la connessione (fase 1, Aka ISAKMP SA). Il formato è "cipher-hash;modpgroup, cipher-hash;modpgroup, ...)
    - esp=aes_gcm256;modp1536 (Specifica gli algoritmi che verranno offerti/accettati per una negoziazione SA figlio. Il formato per ESP è ENC-AUTH seguito da un PFSgroup facoltativo. Ad esempio, "aes_gcm256" o "aes256-sha2_512-dh14" o "aes-sha2_512+sha2_256")
    - ikev2= no (Per utilizzare IKEv2, passare a ikev2=insist)
- Vai alla cartella di configurazione: cd /etc/ipsec.d.
- Libreswan memorizza tutti i tunnel condividono i segreti (password) nel file shared.secrets.
  - Formato shared.secrets di Libreswan: destra di sinistra: PSK "secret"
    - leftid: l'ID IKE configurato in IPSec.conf (leftid). In genere l'indirizzo IP pubblico di Libreswan.
    - destra: indirizzo IP pubblico del tunnel OCI.
    - "secret": il segreto o la password condivisi del tunnel corrente configurati in OCI. È possibile ottenere queste informazioni dalla console OCI in Networking, connettività del cliente, VPN da sito a sito, YourIPSEC, TunnelName, informazioni sul tunnel, segreto condiviso, Show.
Per questa esercitazione, abbiamo creato i seguenti ipsec.conf e shared.secrets (gli IP pubblici sono nascosti):

ipsec.conf

shared.secrets
Ora, cerchiamo di stabilire i due tunnel HA su OCI.
- Riavviare il servizio Libreswan: come utente root, eseguire ipsec restart . Se tutto va bene non verranno mostrati errori, altrimenti vedrete qualcosa del genere:
  
  Job per ipsec.service non riuscito perché il processo di controllo è terminato con codice di errore. Per i dettagli, vedere "systemctl status ipsec.service" e "journalctl -xe".
- Ora controlliamo lo stato corrente dei tunnel IPSec: esegui ipsec status. Verranno visualizzate molte informazioni sui tunnel correnti configurati in base a ESP (piano dati) e IKE (piano di segnalazione), subnet consentite e così via. Per il momento, ci concentreremo sulla lista delle connessioni.
  
  000 Elenco connessioni:
  
  000
  
  000 Totale connessioni IPSec: *caricato 0, attivo 0
- Attualmente non è stata caricata alcuna configurazione del tunnel, né è attiva.
- Eseguire ipsec auto --add ConnName1, ad esempio ipsec auto --add home_liftvti.
  - 002 ha aggiunto la descrizione della connessione "home_liftvti" <- Ora la connessione è "caricata" non ancora attiva. Controllalo con lo stato di ipsec.
- Eseguire ipsec auto --up ConnName1 per avviare il tunnel 1, ovvero ipsec auto --up home_liftvti. Se tutto va bene, vedrai la IPSec modalità tunnel stabilita da SA, altrimenti vedrai errori IKE/IPSec diversi di cui avrai bisogno per risolvere i problemi.
- Ora è attiva il secondo tunnel: eseguire ipsec auto -add ConnName2, ovvero ipsec auto -add home_liftvti2
  - 002 ha aggiunto la descrizione della connessione "home_liftvti2" <- Ora la connessione è "caricata" non ancora attiva. Controlla con stato di ipsec
- Eseguire ipsec auto -up ConnName2 per avviare il tunnel 1, ovvero ipsec auto -up home_liftvti2. Se tutto va bene vedrai "IPSec SA stabilisce la modalità tunnel", altrimenti vedrai diversi errori IKE/IPSec che dovrai risolvere

Task 3: configurazione dell'instradamento IP e del traffico tunnel

Questa parte dell'esercitazione si concentrerà sull'instradamento IP e sul traffico tunnel.

Ora che entrambi i tunnel sono attivi e in esecuzione, provare a eseguire il ping di alcuni computer in OCI da Libreswan per eseguire il test dei tunnel. Ad esempio, eseguire il ping su origin1 con IP 10.0.0.109. Vedrete che fallirà.
```
PING 10.0.0.109 (10.0.0.109) 56(84) bytes of data.

  10.0.0.109 ping statistics
  26 packets transmitted, 0 received, 100% packet loss,
```
Potresti chiederti perché non funziona, anche se i tunnel IPSec sono attivi e in esecuzione su OCI. La risposta è che i due tunnel stabiliti rispetto a OCI sono "basati su instradamento" e ogni tunnel è rappresentato da un'interfaccia virtuale (VTI). Puoi vedere ogni VTI come scheda NIC (Virtual Network Interface Card) che rappresenta un tunnel IPSec. Qualsiasi traffico indirizzato al VTI viene incapsulato utilizzando il protocollo ESP (Encapsulate Security Payload) e inviato all'altra estremità del tunnel. Il VTI funge da gateway per il traffico che deve essere protetto e trasmesso tramite il tunnel IPSec.
Nello scenario di test sono disponibili due interfacce VTI, vti01 e vti02, ognuna delle quali rappresenta home_liftvti e home_liftvti02 sul DRG OCI. È possibile vederli facilmente eseguendo il comando Linux ifconfig.
Ora è sufficiente aggiungere un instradamento del sistema operativo Linux verso tali interfacce VTI per garantire che il traffico raggiunga OCI attraverso i due tunnel. Tenere presente che qualsiasi traffico indirizzato a un'interfaccia VTI verrà incapsulato nel tunnel IPSec associato e instradato a OCI.
- Il comando per aggiungere l'instradamento ha il seguente formato: ip route add {vcnCidrBlock} nexthop dev {vti1} weight {priority}nexthop dev {vti2} weight {priority}`
- Nel nostro caso di test, vogliamo essere in grado di raggiungere OCI VCN1 con CIDR 10.0.0.0/16: ip route add 10.0.0.0/16 nexthop dev vti01 peso 1 nexthop dev vti02 peso 1

Ora il ping dovrebbe funzionare immediatamente.

ping 10.0.0.109
   PING 10.0.0.109 (10.0.0.109) 56(84) bytes of data.
   64 bytes from 10.0.0.109: icmp_seq=1 ttl=61 time=29.0 ms
   64 bytes from 10.0.0.109: icmp_seq=2 ttl=61 time=29.4 ms
   64 bytes from 10.0.0.109: icmp_seq=3 ttl=61 time=29.0 ms

Ora abbiamo due tunnel che funzionano.

Task 4: configurazione del bilanciamento del carico e della ridondanza ECMP

Questa parte dell'esercitazione si concentrerà sul bilanciamento del carico e sulla ridondanza ECMP.

A questo punto dell'esercitazione, attualmente abbiamo due tunnel IPSec stabiliti e operativi con OCI. Entrambi i tunnel utilizzano lo stesso instradamento verso la nostra rete on premise, come specificato nel nostro caso di test 192.168.0.0/16.
- Tunnel 1 192.168.0.0/16 -> On-premise
- Tunnel 2 192.168.0.0/16 -> Onprem
Poiché entrambi i tunnel stanno utilizzando lo stesso instradamento on premise (192.168.0.0/16), questo instradamento verrà propagato verso il resto dei collegamenti di rete DRG in modo che altri elementi di rete (VCN, subnet e così via) possano raggiungere on premise tramite IPSec. Come vedrai nella foto successiva, avremo un conflitto sull'instradamento 192.168.0.0/16 che sarà lo stesso per i due tunnel Sec IP nella tabella DRG generata automaticamente per i collegamenti VCN.
Con questa configurazione, useremo solo un tunnel e ignoreremo l'altro. L'obiettivo di questa esercitazione è poter utilizzare entrambi i tunnel contemporaneamente per garantire alta disponibilità (attiva/attiva) e raddoppiare le prestazioni aggiungendo il throughput di due tunnel. È qui che entra in gioco ECMP. Per attivare ECMP, è innanzitutto necessario abilitarlo nella tabella DRG generata automaticamente per ogni collegamento VCN: Networking, Connettività cliente, gateway di instradamento dinamico, DRGName, Dettagli tabella di instradamento DRG, Pulsante di modifica (è necessario eseguire questa operazione su ogni tabella di collegamento DRG).
Si noterà che il conflitto di instradamento nella tabella di instradamento DRG generata automaticamente per i collegamenti VCN è stato risolto.
Attivare ECMP in Linux e Libreswan. Per supportare Equal-cost Multi-path Routing (ECMP), Linux introduce una scelta di criteri hash utilizzando fib_multipath_hash_policy, una nuova impostazione sysctl che controlla il criterio hash da utilizzare per gli instradamenti multipath. Quando fib_multipath_hash_policy è impostato su 1, il kernel esegue l'hash L4, che è un hash multipath per i pacchetti IPv4 in base a un set di valori 5-tuple (IP di origine, porta di origine, IP di destinazione, porta di destinazione, tipo di protocollo IP). Quando fib_multipath_hash_policy è impostato su 0 (predefinito), viene utilizzato solo l'hash L3 (indirizzi IP di origine e destinazione). Dalla console Linux, come utente root, eseguire le operazioni riportate di seguito.

sysctl -w net.ipv4.fib_multipath_hash_policy=1
Ora, ECMP è stato attivato in entrambe le estremità, pertanto entrambi i tunnel verranno utilizzati in modalità attiva/attiva, con l'aggiunta di un throughput totale di due tunnel IPSec. Per i nostri test abbiamo usato il comando iperf3 per ispezionare il traffico e abbiamo ottenuto i seguenti risultati:
```
 From Libreswan: iperf3 -c 10.0.0.109  -b 1100Mb  -P  8 -t 300

 From OCI Origin1: iperf3 -s

 [SUM]   0.00-1.75   sec   249 MBytes  1.20 Gbits/sec  7122             sender
```

Approvazioni

Autori - Luis Catalán Hernández (Esperto di rete cloud OCI e Multi Cloud), Antonio Gamir (Esperto di rete cloud OCI)

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a contenuti di formazione gratuiti sul canale YouTube di Oracle Learning. Inoltre, visitare education.oracle.com/learning-explorer per diventare Explorer di Oracle Learning.

Per la documentazione sul prodotto, visitare il sito Oracle Help Center.

Titolo e informazioni sul copyright

Use Oracle Cloud Infrastructure Site-to-Site VPN service in HA mode with ECMP routing from Linux and Libreswan

F84216-01

July 2023