Strongswan
Strongswan è una soluzione VPN open source basata su IPSec. La maggior parte delle distribuzioni Linux includono Strongswan o lo rendono facile da installare. È possibile installarlo sugli host in una rete in locale o in una rete di provider cloud.
Questo argomento fornisce informazioni sulla configurazione per il CPE che esegue Strongswan. Il ramo Strongswan 5.x supporta sia i protocolli di scambio di chiavi IKEv1 che IKEv2 con lo stack NETKEY IPSec nativo del kernel Linux.
Oracle fornisce istruzioni di configurazione per un set testato di fornitori e dispositivi. Utilizzare la configurazione corretta per il fornitore e la versione software.
Se la versione del dispositivo o del software utilizzata da Oracle per verificare la configurazione non corrisponde esattamente al dispositivo o al software, è comunque possibile creare la configurazione necessaria sul dispositivo. Consultare la documentazione del fornitore ed apportare le modifiche necessarie.
Se il dispositivo proviene da un fornitore non incluso nell'elenco dei fornitori e dei dispositivi verificati o se si ha già familiarità con la configurazione del dispositivo per IPSec, vedere l'elenco di parametri IPSec supportati e consultare la documentazione del fornitore per assistenza.
Oracle Cloud Infrastructure offre una VPN da sito a sito, una connessione IPSec sicura tra una rete on premise e una rete cloud virtuale (VCN).
Il diagramma riportato di seguito mostra una connessione IPSec di base a Oracle Cloud Infrastructure con tunnel ridondanti. Gli indirizzi IP utilizzati in questo diagramma sono solo un esempio.
Procedure ottimali
Questa sezione descrive le best practice generali e le considerazioni da tenere presenti per l'utilizzo della VPN da sito a sito.
Configura tutti i tunnel per ogni connessione IPSec
Oracle distribuisce due headend IPSec per le connessioni per fornire alta disponibilità per i carichi di lavoro mission-critical. Per quanto riguarda Oracle, questi due headend si trovano su router diversi a scopo di ridondanza. Si consiglia di configurare tutti i tunnel disponibili per la massima ridondanza. Questa è una parte fondamentale della filosofia "Design for Failure".
Disporre di CPE ridondanti nelle posizioni di rete in locale
Consigliamo a ogni sito che si connette con IPSec a Oracle Cloud Infrastructure di disporre di dispositivi edge ridondanti (noti anche come customer-premise equipment (CPE)). Ogni CPE viene aggiunto alla console Oracle e viene creata una connessione IPSec separata tra un gateway di instradamento dinamico (DRG) e ogni CPE. Per ogni connessione IPSec, Oracle esegue il provisioning di due tunnel in headend IPSec ridondanti a livello geografico. Per ulteriori informazioni, consulta la Guida alla ridondanza della connettività (PDF).
Considerazioni sul protocollo di instradamento
Quando si crea una connessione VPN da sito a sito IPSec, sono disponibili due tunnel IPSec ridondanti. Oracle ti consiglia di configurare il CPE in modo che utilizzi entrambi i tunnel (se il CPE lo supporta). In passato, Oracle ha creato connessioni IPSec con un massimo di quattro tunnel IPSec.
Sono disponibili i tre tipi di instradamento seguenti e si seleziona il tipo di instradamento separatamente per ogni tunnel nella VPN da sito a sito:
- Instradamento dinamico BGP: gli instradamenti disponibili vengono acquisiti in modo dinamico tramite BGP. Il DRG apprende in modo dinamico gli instradamenti dalla rete in locale. Sul lato Oracle, il gateway DRG pubblica le subnet della VCN.
- Instradamento statico: quando si imposta la connessione IPSec al DRG, si specificano gli instradamenti specifici alla rete in locale di cui si desidera che la VCN sia a conoscenza. Inoltre, devi configurare il dispositivo CPE con instradamenti statici alle subnet della VCN. Questi percorsi non vengono appresi in modo dinamico.
- Instradamento basato su criteri: quando si imposta la connessione IPSec al DRG, si specificano gli instradamenti specifici alla rete in locale di cui si desidera che la VCN sia a conoscenza. Inoltre, devi configurare il dispositivo CPE con instradamenti statici alle subnet della VCN. Questi percorsi non vengono appresi in modo dinamico.
Per ulteriori informazioni sull'instradamento con VPN da sito a sito, inclusi i suggerimenti Oracle su come manipolare l'algoritmo di selezione del percorso migliore BGP, vedere Instradamento per VPN da sito a sito.
Altre importanti configurazioni CPE
Assicurarsi che le liste di accesso nel CPE siano configurate correttamente per non bloccare il traffico necessario da o verso Oracle Cloud Infrastructure.
Se si dispone di più tunnel contemporaneamente, si potrebbe verificare l'instradamento asimmetrico. Per tenere conto dell'instradamento asimmetrico, assicurarsi che il CPE sia configurato per gestire il traffico proveniente dalla VCN in uno qualsiasi dei tunnel. Ad esempio, è necessario disabilitare l'ispezione ICMP, configurare il bypass dello stato TCP. Per ulteriori dettagli sulla configurazione appropriata, contattare il supporto del fornitore CPE. Per configurare l'instradamento in modo che sia simmetrico, vedere Instradamento per VPN da sito a sito.
Grotte e limitazioni
Questa sezione copre le caratteristiche e le limitazioni importanti generali di Site-to-Site VPN di cui essere a conoscenza. Per esaminare un elenco dei limiti applicabili e le istruzioni per richiedere un incremento del limite, consulta i limiti del servizio.
Instradamento asimmetrico
Oracle utilizza il routing asimmetrico tra i tunnel che compongono la connessione IPSec. Configurare i firewall tenendo presente questo aspetto. In caso contrario, i test di ping o il traffico dell'applicazione attraverso la connessione non funzionano in modo affidabile.
Quando utilizzi diversi tunnel per Oracle Cloud Infrastructure, ti consigliamo di configurare l'instradamento per instradare il traffico in modo deterministico attraverso il tunnel preferito. Per utilizzare un tunnel IPSec come primario e un altro come backup, configurare instradamenti più specifici per il tunnel primario (BGP) e instradamenti meno specifici (instradamento sintetico o predefinito) per il tunnel di backup (BGP/statico). In caso contrario, se si pubblica lo stesso instradamento (ad esempio, un instradamento predefinito) attraverso tutti i tunnel, restituire il traffico da una VCN a un instradamento di rete in locale a uno qualsiasi dei tunnel disponibili. Questo perché Oracle utilizza l'instradamento asimmetrico.
Per suggerimenti di instradamento Oracle specifici su come forzare l'instradamento simmetrico, vedere Instradamento per VPN da sito a sito.
VPN da sito a sito basata su instradamento o criteri
Il protocollo IPSec utilizza le associazioni di sicurezza (SA) per decidere come cifrare i pacchetti. All'interno di ogni SA, è possibile definire i domini di cifratura per mappare l'indirizzo IP di origine e destinazione di un pacchetto e il tipo di protocollo a una voce nel database SA per definire come cifrare o decifrare un pacchetto.
Altri fornitori o la documentazione del settore possono utilizzare il termine ID proxy, indice dei parametri di sicurezza (SPI) o selettore del traffico quando si fa riferimento a SA o domini di cifratura.
Esistono due metodi generali per l'implementazione dei tunnel IPSec:
- Tunnel basati su instradamento: chiamato anche tunnel basati sul prossimo hop. La ricerca della tabella di instradamento viene eseguita sull'indirizzo IP di destinazione di un pacchetto. Se l'interfaccia di uscita di tale instradamento è un tunnel IPSec, il pacchetto viene cifrato e inviato all'altra estremità del tunnel.
- Tunnel basati su criteri: l'indirizzo IP e il protocollo di origine e destinazione del pacchetto corrispondono a una lista di istruzioni dei criteri. Se viene trovata una corrispondenza, il pacchetto viene cifrato in base alle regole in tale istruzione di criterio.
I backend VPN da sito a sito Oracle utilizzano tunnel basati su instradamento, ma possono funzionare con tunnel basati su criteri con alcune avvertenze elencate nelle sezioni riportate di seguito.
Se il CPE si trova dietro un dispositivo NAT
In generale, l'identificativo CPE IKE configurato all'estremità in locale della connessione deve corrispondere all'identificativo CPE IKE utilizzato da Oracle. Per impostazione predefinita, Oracle utilizza l'indirizzo IP pubblico del CPE, fornito quando si crea l'oggetto CPE nella console Oracle. Tuttavia, se un CPE si trova dietro un dispositivo NAT, l'identificativo CPE IKE configurato all'interno dell'ambiente on premise potrebbe essere l'indirizzo IP privato del CPE, come mostrato nel diagramma seguente.
Alcune piattaforme CPE non consentono di modificare l'identificativo IKE locale. In caso contrario, è necessario modificare l'ID IKE remoto nella console Oracle per trovare la corrispondenza con l'ID IKE locale del CPE. È possibile fornire il valore quando si imposta la connessione IPSec o in un secondo momento modificando la connessione IPSec. Oracle prevede che il valore sia un indirizzo IP o un nome dominio completamente qualificato (FQDN), ad esempio cpe.example.com. Per istruzioni, consulta la sezione relativa alla modifica dell'identificativo CPE IKE utilizzato da Oracle.
Parametri IPSec supportati
Per un elenco dei parametri IPSec supportati indipendentemente dal fornitore per tutte le aree, vedere Parametri IPSec supportati.
L'ASN BGP Oracle per il realm del cloud commerciale è 31898. Se si sta configurando una VPN da sito a sito per il cloud del governo degli Stati Uniti, vedere Parametri VPN da sito a sito obbligatori per Government Cloud e anche ASN BGP di Oracle. Per il cloud del governo del Regno Unito, consulta la sezione relativa alle aree.
Configurazione CPE
Le istruzioni di configurazione in questa sezione sono fornite da Oracle Cloud Infrastructure per questo CPE. Se hai bisogno di supporto o ulteriore assistenza, contatta direttamente il supporto del fornitore CPE.
La figura seguente mostra il layout di base della connessione IPSec.
File di configurazione Strongswan predefiniti
L'installazione Strongswan predefinita crea i seguenti file:
etc/strongswan/ipsec.conf: la radice della configurazione Strongswan./etc/strongswan/ipsec.secrets: la radice della posizione in cui Strongswan cerca i segreti (le chiavi precondivise del tunnel).
Il file etc/strongswan/ipsec.conf predefinito include la riga seguente:
Include /etc/strongswan/*.confIl file etc/strongswan/ipsec.secrets predefinito include la riga seguente:
include /etc/strongswan/ipsec.d/*.secretsLe righe precedenti uniscono automaticamente tutti i file .conf e .secrets nella directory /etc/strongswan ai file di configurazione e segreti principali utilizzati da Strongswan.
Informazioni sull'utilizzo di IKEv2
Oracle supporta Internet Key Exchange versione 1 (IKEv1) e versione 2 (IKEv2). Se si configura la connessione IPSec nella console per utilizzare IKEv2, è necessario configurare il CPE in modo che utilizzi solo IKEv2 e i parametri di cifratura IKEv2 correlati supportati dal CPE. Per un elenco dei parametri supportati da Oracle per IKEv1 o IKEv2, vedere Parametri IPSec supportati.
La versione IKE viene specificata durante la configurazione del file di configurazione IPSec in task 3 nella sezione successiva. In questo file di esempio, un commento mostra come configurare IKEv1 o IKEv2.
Processo di configurazione
Il processo di configurazione seguente descrive la configurazione di un tunnel basato su percorso su Strongswan. Le intestazioni VPN di Oracle utilizzano tunnel basati sull'instradamento. Si consiglia di configurare Strongswan con la sintassi di configurazione VTI (Virtual Tunnel Interface).
Per informazioni dettagliate sui parametri specifici utilizzati nel presente documento, vedere Parametri IPSec supportati.
A seconda della distribuzione Linux che stai utilizzando, potrebbe essere necessario abilitare l'inoltro IP sull'interfaccia per consentire ai client di inviare e ricevere traffico attraverso Strongswan. Nel file /etc/sysctl.conf, impostare i valori seguenti e applicare gli aggiornamenti con sudo sysctl -p.
Se si utilizza un'interfaccia diversa da eth0, modificare eth0 nell'esempio seguente nell'interfaccia (linee 5 e 7).
Se si utilizzano diverse interfacce, configurare anche le righe 5 e 7 per tale interfaccia.
net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.ens3.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.ens3.accept_redirects = 0
La configurazione Strongswan utilizza le seguenti variabili. Decidere i valori prima di procedere con la configurazione.
${cpeLocalIP}: indirizzo IP del dispositivo Strongswan.${cpePublicIpAddress}: L'indirizzo IP pubblico per Strongswan, anche l'indirizzo IP dell'interfaccia esterna. A seconda della topologia di rete, il valore può essere diverso da${cpeLocalIP}.${oracleHeadend1}: per il primo tunnel, l'endpoint IP pubblico Oracle ottenuto dalla console Oracle.${oracleHeadend2}: per il secondo tunnel, l'endpoint IP pubblico Oracle ottenuto dalla console Oracle.${sharedSecret1}: la chiave precondivisa per il primo tunnel. È possibile utilizzare la chiave precondivisa predefinita fornita da Oracle o fornire una chiave quando si imposta la connessione IPSec nella console di Oracle.${sharedSecret2}: la chiave precondivisa per il secondo tunnel. È possibile utilizzare la chiave precondivisa predefinita fornita da Oracle o fornire una chiave quando si imposta la connessione IPSec nella console di Oracle.${vcnCidrNetwork}: intervallo IP VCN.
La configurazione Strongswan utilizza il concetto di sinistra e destra per definire i parametri di configurazione per il dispositivo CPE locale e il gateway remoto. I due lati della connessione (la connessione nella configurazione Strongswan) possono essere a sinistra o a destra, ma la configurazione per tale connessione deve essere coerente. In questo esempio:
- sinistra: il CPE Strongswan locale
- a destra: il headend Oracle VPN
Utilizzare il modello seguente per il file /etc/strongswan/ipsec.conf. Il file definisce i due tunnel creati da Oracle quando si imposta la connessione IPSec.
Se il CPE si trova dietro un dispositivo NAT one-to-one, annullare il commento del parametro leftid e impostarlo su ${cpePublicIpAddress}.
# basic configuration
config setup
conn %default
ikelifetime=28800s
keylife=3600s
rekeymargin=3m
keyingtries=%forever
mobike=no
ike=aes256-sha2_384-ecp384!
esp=aes256gcm16-modp1536!
conn oci-tunnel-1
left=${cpeLocalIP}
#leftid=${cpePublicIpAddress} # See preceding note about 1-1 NAT device
leftsubnet=0.0.0.0/0
leftauth=psk
right=${oracleHeadend1}
rightid=${oracleHeadend1}
rightsubnet=0.0.0.0/0
rightauth=psk
type=tunnel
keyexchange=ikev1 # To use IKEv2, change to ikev2
auto=start
dpdaction=restart
mark=13 # Needs to be unique across all tunnels
conn oci-tunnel-2
left={cpeLocalIP}
#leftid=${cpePublicIpAddress}
leftsubnet=0.0.0.0/0
leftauth=psk
right=${oracleHeadend2}
rightid=${oracleHeadend2}
rightsubnet=0.0.0.0/0
rightauth=psk
type=tunnel
keyexchange=ikev1 # To use IKEv2, change to ikev2
auto=start
dpdaction=restart
mark=14 # Needs to be unique across all tunnels
È possibile modificare istruzioni quali ike= e esp= per parametri specifici in base ai parametri IPSec supportati.
Utilizzare il modello seguente per il file /etc/strongswan/ipsec.secrets . Contiene due linee per connessione IPSec (una linea per tunnel).
${cpePublicIpAddress} ${oracleHeadend1}: PSK "${sharedSecret1}"
${cpePublicIpAddress} ${oracleHeadend2}: PSK "${sharedSecret2}"
Il comando seguente crea un'interfaccia VTI con il nome definito e la associa al tunnel utilizzando gli IP locali e remoti.
ip tunnel add <name> local <local IP> remote <remote IP> mode vti key <mark><name>può essere qualsiasi nome di dispositivo valido (ipsec0, vti0 e così via). Il comando ip considera i nomi che iniziano convticome speciali in alcune istanze (ad esempio quando si recuperano le statistiche del dispositivo). Gli indirizzi IP sono gli endpoint del tunnel IPSec. Un IP privato può essere utilizzato quando il CPE si trova dietro un dispositivo NAT.-
<mark>deve corrispondere al contrassegno configurato per la connessione.
Dopo aver creato il VTI, deve essere abilitato (usare ip link set <name> up) e quindi è possibile installare gli instradamenti e utilizzare i protocolli di routing come mostrato nell'esempio seguente.
ip tunnel add vti1 mode vti local 10.0.3.78 remote 193.123.68.187 key 13
ip link set vti1 upL'installazione del percorso da parte del daemon IKE deve essere disabilitata. A tale scopo, modificare charon.conf come mostrato.
Directory - /etc/strongswan/strongswan.d/Charon.conf
#Uncomment below statement
install_routes = no
Dopo aver configurato i file di configurazione e segreti, è necessario riavviare il servizio Strongswan. Utilizzare il seguente comando:
Strongswan restart
Il riavvio del servizio Strongswan potrebbe influire sui tunnel esistenti.
Utilizzare il comando ip seguente per creare instradamenti statici che inviano traffico a una VCN tramite i tunnel IPSec. Se hai effettuato l'accesso con un account utente senza privilegi, potrebbe essere necessario utilizzare sudo prima del comando.
Gli instradamenti statici creati con il comando ip route non persistono durante il reboot. Per scoprire come rendere persistenti i percorsi, consulta la documentazione della distribuzione Linux scelta.
ip route add ${VcnCidrBlock} nexthop dev ${vti1} nexthop dev ${vti2}
ip route show
Verifica
Un servizio di monitoraggio è disponibile anche da Oracle Cloud Infrastructure per monitorare attivamente e passivamente le risorse cloud. Per informazioni sul monitoraggio di una VPN da sito a sito, vedere Metriche VPN da sito a sito.
In caso di problemi, vedere Risoluzione dei problemi delle VPN da sito a sito.
Puoi anche abilitare la registrazione OCI per ottenere l'accesso ai log VPN.
Verifica dello stato dell'interfaccia tunnel
Verificare lo stato corrente dei tunnel Strongswan utilizzando il comando seguente.
strongswan statusSe l'output restituito è simile all'esempio seguente, viene creato il tunnel.
oci-tunnel-1[591]: ESTABLISHED 43 minutes ago, 10.0.3.78[129.148.216.212]...193.123.68.187[193.123.68.187]
oci-tunnel-1{399}: INSTALLED, TUNNEL, reqid 102, ESP in UDP SPIs: ce6a1525_i 4829c65c_o
oci-tunnel-1{399}: 0.0.0.0/0 === 0.0.0.0/0
In futuro, se è necessario aprire un ticket di supporto con Oracle sul tunnel Strongswan, includere l'output completo del comando strongswan status.
Verifica dello stato dell'interfaccia tunnel
Verificare che le interfacce del tunnel virtuale siano attive o inattive utilizzando il comando ifconfig o ip link show. È anche possibile utilizzare applicazioni quali tcpdump con le interfacce.
Di seguito è riportato un esempio dell'output ifconfig con un'implementazione Strongswan funzionante che mostra i VTI disponibili.
ifconfig
<output trimmed>
vti1: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
inet 10.10.10.1 netmask 255.255.255.252 destination 10.10.10.1
inet6 fe80::5efe:a00:34e prefixlen 64 scopeid 0x20<link>
tunnel txqueuelen 1000 (IPIP Tunnel)
RX packets 69209 bytes 4050022 (3.8 MiB)
RX errors 54 dropped 54 overruns 0 frame 0
TX packets 50453 bytes 3084997 (2.9 MiB)
TX errors 1016 dropped 0 overruns 0 carrier 1016 collisions 0
vti2: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
inet 192.168.10.1 netmask 255.255.255.252 destination 192.168.10.1
inet6 fe80::5efe:a00:34e prefixlen 64 scopeid 0x20<link>
tunnel txqueuelen 1000 (IPIP Tunnel)
RX packets 101256 bytes 6494872 (6.1 MiB)
RX errors 12 dropped 12 overruns 0 frame 0
TX packets 70023 bytes 4443597 (4.2 MiB)
TX errors 2142 dropped 0 overruns 0 carrier 2142 collisions 0
Di seguito è riportato un esempio dell'output ip link show.
ip link show
<output trimmed>
vti2@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ipip 10.0.3.78 peer 139.185.34.172
14: vti1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ipip 10.0.3.78 peer 193.123.68.187
Configurare il routing dinamico con Strongswan
Si consiglia di utilizzare quagga per configurare BGP. Per installare quagga, utilizzare il comando Oracle Linux seguente (se si utilizza una distribuzione Linux diversa, i comandi potrebbero variare leggermente):
sudo yum -y install quaggaModificare la configurazione zebra (/etc/quagga/zebra.conf) per definire l'indirizzo IP VTI, necessario perché BGP utilizza il peering. Definire le seguenti variabili per la zebra:
${vti_name1}: il nome del primo VTI utilizzato. Ad esempio, vti1.${vti_name2}: il nome del secondo VTI utilizzato. Ad esempio, vti2.${vti_ipaddress1}: l'indirizzo IP allocato al primo VTI utilizzato.${vti_ipaddress2}: l'indirizzo IP allocato al secondo VTI utilizzato.${local_subnet}: la subnet CPE locale.
Queste variabili vengono utilizzate nel seguente estratto del file di configurazione:
!
hostname strongswan-centos
log file /var/log/quagga/quagga.log
!
interface ens3
ipv6 nd suppress-ra
!
interface ens5
ipv6 nd suppress-ra
!
interface lo
!
interface <Vti_name1>
ip address ${vti_ipaddress1}
ipv6 nd suppress-ra
!
interface <Vti_name2>
ip address ${vti_ipaddress2}
ipv6 nd suppress-ra
!
ip route ${local_subnet} <Vti_name1>
ip route ${local_subnet} <Vti_name2>
!
ip forwarding
!
!
line vty
!
Il file di configurazione bgpd è necessario anche per la configurazione BGP. Definire le seguenti variabili per bgpd:
${LOCAL_ASN}: ASN BGP della rete on premise.${router-id_ipaddress}: l'ID BGP della rete locale.${local_subnet}: la sottorete locale da pubblicizzare.${bgp_peer-ip _network}: il CIDR /30 per la rete IP peer in OCI.${neighbor_peer_ip_address}: l'indirizzo IP peer BGP OCI.
Queste variabili vengono utilizzate nel seguente estratto del file di configurazione da /etc/quagga/bgpd.conf:
hostname <host-name>
router bgp ${LOCAL_ASN}
bgp router-id ${router-id_ipaddress}
network ${bgp_peer-ip _network}
network ${bgp_peer-ip _network}
network ${local_subnet}
neighbor ${neighbour_peer_ip_address} remote-as 31898
neighbor ${neighbour_peer_ip_address} ebgp-multihop 255
neighbor ${neighbour_peer_ip_address} next-hop-self
neighbor ${neighbour_peer_ip_address} remote-as 31898
neighbor ${neighbour_peer_ip_address} ebgp-multihop 255
neighbor ${neighbour_peer_ip_address} next-hop-self
log file bgpd.log
log stdout
L'abilitazione di strongswan per l'uso di instradamenti e IP virtuali richiede le modifiche a /etc/strongswan/strongswan.d/Charon.conf.
Annullare il commento delle righe che leggono #install_routes = yes e #install_virtual_ip = yes e modificare i valori in "no" come mostrato di seguito.
#Tunnels
install_routes = no
#Install virtual IP addresses.
install_virtual_ip = no
Utilizzare i seguenti comandi per abilitare e avviare il servizio per zebra e BGPD:
systemctl start zebra
systemctl enable zebra
systemctl start bgpd
systemctl enable bgpd