IBM Cloud Docs
Informazioni sui gateway VPN site-to-site

Informazioni sui gateway VPN site-to-site

È possibile utilizzare il servizio IBM Cloud VPN for VPC per collegare in modo sicuro il Virtual Private Cloud (VPC) a un'altra rete privata. Utilizza una VPN statica, basata sull'instradamento o una VPN basata sulla politica per impostare un tunnel da sito a sito IPsec tra il tuo VPC e la tua rete privata in loco o un altro VPC.

La VPN basata sull'instradamento è ora disponibile in aggiunta alla VPN basata sulla politica. Per iniziare, seleziona basato sull'instradamento come modalità quando crei un gateway VPN e crea instradamenti utilizzando il tipo di connessione VPN.

VPN for VPC caratteristiche

Il servizio IBM Cloud VPN for VPC include le seguenti funzionalità:

MD-5 e SHA-1, i gruppi DH 2 e 5 e l'algoritmo di crittografia 3-DES sono stati deprecati il 20 settembre 2022 e non sono più supportati dalla console.

  • Autenticazione- IBM Cloud VPN for VPC supporta una chiave precondivisa per l'autenticazione dei peer di fase 1. Gli algoritmi di autenticazione supportati per entrambe le fasi includono SHA-256, SHA-384 e SHA-512.

  • Alta disponibilità- IBM Cloud VPN for VPC è costruito su due dispositivi VPN per fornire ridondanza a livello di appliance. Una VPN basata su criteri opera in modo Attivo - Standby con un singolo IP gateway VPN condiviso tra i membri, mentre una VPN basata sull'instradamento offre ridondanza Attivo - Attivo con due IP gateway VPN.

    Una VPN statica, basata sull'instradamento, viene distribuita in modalità di ridondanza Active - Active. Due tunnel VPN sono collegati al gateway VPN peer; tuttavia, il gateway IBM utilizza sempre il tunnel con l'IP pubblico piccolo come percorso di uscita primario. Il tunnel con l'IP pubblico di grandi dimensioni è il percorso di uscita secondario. Il traffico dalla VPC IBM alla rete on-premise passa attraverso il percorso di uscita primario se entrambi i tunnel sono attivi. Il traffico passa attraverso il percorso di uscita secondario se il percorso di uscita primario è disabilitato. Il gateway VPN in loco deve utilizzare la priorità di instradamento per scegliere lo stesso percorso preferito. Ulteriori informazioni

  • Rilevamento peer inattivo- meccanismo configurabile per rilevare la disponibilità di un peer IPsec.

  • Diffie - Hellman (DH)- Protocollo di scambio di chiavi utilizzato nella Fase 1 per generare una chiave segreta condivisa tra peer VPN. Facoltativamente, gli utenti possono abilitare PFS (Perfect Forward Secrecy) e un gruppo DH per la negoziazione IPsec fase 2. IBM Cloud VPN for VPC supporta i gruppi DH 14-24 e 31.

  • Crittografia- IBM Cloud VPN for VPC supporta AES-128, AES-192 e AES-256 per la crittografia dei dati durante la fase 1 e la fase 2 di IKE.

  • IKE (Internet Key Exchange)- IKE è una parte del protocollo IPsec utilizzato per stabilire connessioni VPN. In IKE Phase 1, i peer VPN utilizzano lo scambio di chiavi DH (Diffie - Hellman) per creare un canale di comunicazione sicuro e autenticato. Nella fase 2 IKE, i peer utilizzano un canale sicuro dalla fase 1 per negoziare parametri per i tunnel IPsec. IBM Cloud VPN for VPC supporta sia IKEv1 (modalità principale) che IKEv2. Consultare Informazioni sulla negoziazione della politica per le combinazioni supportate.

  • IPsec- Suite di protocolli che fornisce comunicazioni sicure tra le periferiche. IBM Cloud VPN for VPC utilizza l'incapsulamento UDP dei pacchetti IPsec Encapsulating Security Protocol (ESP) in modalità tunnel, che offre l'autenticazione e la crittografia dell'intero pacchetto.

  • Modalità- IBM Cloud VPN for VPC offre modalità VPN basate su percorsi statici e su criteri. Con una VPN basata su criteri, il traffico che corrisponde agli intervalli CIDR negoziati passa attraverso la VPN. Per una VPN basata sull'instradamento statico, vengono create interfacce di tunnel virtuali e tutto il traffico instradato verso queste interfacce logiche con instradamenti personalizzati passa attraverso la VPN. Entrambe le opzioni VPN forniscono le stesse funzionalità.

  • PFS (Perfect Forward Secrecy)- PFS garantisce che le chiavi generate da DH non vengano utilizzate di nuovo durante la rinegoziazione IPsec. Se una chiave è compromessa, sono accessibili solo i dati in transito nel corso della durata dell'associazione della sicurezza protetta.

Introduzione ai gateway VPN

Prima di creare una VPN, devi prima creare un VPC e una o più sottoreti per la tua VPN e altre risorse.

Anche se non è richiesto, si consiglia di dedicare una sottorete di almeno 16 IP (prefisso 28 o inferiore) per il tuo gateway VPN. Se decidi di eseguire il provisioning di risorse aggiuntive all'interno della sottorete VPN, assicurati che ci siano sempre almeno 4 IP disponibili per le attività di recupero e manutenzione per l'utilizzo da parte del gateway VPN. In aggiunta ai 4 IP necessari al gateway VPN, fino a 5 IP in una sottorete sono riservati per l'utilizzo della rete interna, quindi assicurati che la sottorete sia abbastanza grande.

Per creare un gateway VPN, attieniti alla seguente procedura generale:

  1. Assicurarsi che siano presenti le ACL di rete per il traffico VPN.

  2. Assicurati che il dispositivo peer supporti l'attraversamento NAT e che sia abilitato sul dispositivo peer. Per ulteriori informazioni, vedi Limitazioni del gateway VPN.

  3. Esamina le considerazioni sulla pianificazione e crea il tuo gateway VPN.

  4. Crea connessioni VPN.

    IBM Cloud VPN for VPC supporta solo una VPN basata su route per zona e per VPC.

  5. Per le VPN statiche, basate sull'instradamento, seleziona o crea una tabella di instradamento per l'instradamento statico, quindi crea instradamenti utilizzando il tipo Connessione VPN.

  6. Connetti a una rete in loco tramite un tunnel VPN.

  7. Verifica che la tua connessione VPN sia disponibile inviando il ping o il traffico dati attraverso il tunnel ai dispositivi che si trovano sulla rete peer.

Architettura

Questo diagramma illustra una configurazione VPN di esempio con più reti in loco. La VPN è configurata su una sottorete all'interno del VPC di un utente, ma può essere condivisa dalle istanze su tutte le sottoreti all'interno della zona. Le politiche IKE e IPsec possono essere utilizzate anche da una o più connessioni VPN.

Esempio di configurazione VPN
Esempio di configurazione VPN

Informazioni sulla negoziazione delle politiche

Per entrambe le fasi della negoziazione IKE, i peer IPsec devono scambiare proposte di parametri di sicurezza che ognuno è configurato per supportare e per concordare una serie di configurazioni. I criteri IKE e IPsec personalizzati consentono agli utenti di IBM Cloud VPN for VPC di configurare i parametri di sicurezza utilizzati durante la negoziazione.

L'utilizzo delle politiche IKE e IPsec per configurare una connessione VPN è facoltativo. Quando non si seleziona un criterio, le proposte predefinite vengono scelte automaticamente attraverso un processo noto come auto-negoziazione.

I principali parametri di sicurezza coinvolti in questo processo di negoziazione sono i seguenti:

  • Fase IKE
  • Algoritmo di crittografia
  • Algoritmo di autenticazione
  • Gruppo Diffie - Hellman (protocollo di scambio chiavi di cifratura)

Poiché IBM Cloud utilizza l'auto-negoziazione IKEv2, il dispositivo on-premises deve anche utilizzare IKEv2. Utilizza una politica IKE personalizzata se il tuo dispositivo in loco non supporta IKEv2.

Negoziazione automatica (fase 1)

È possibile utilizzare le seguenti opzioni di codifica, autenticazione e gruppo Diffie - Hellman in qualsiasi combinazione:

Opzioni di crittografia, autenticazione e gruppo DH per la fase 1 di auto-negoziazione IPsec
Crittografia Autenticazione Gruppo DH
1 aes128 sha256 14-24, 31
2 aes192 sha384 14-24, 31
3 aes256 sha512 14-24, 31

Negoziazione automatica di IPsec (fase 2)

È possibile utilizzare le seguenti opzioni di codifica e autenticazione in qualsiasi combinazione oppure utilizzare le seguenti opzioni di codifica in modalità combinata che richiedono che l'autenticazione sia disabilitata.

Per impostazione predefinita, PFS è disattivato per IBM Cloud VPN for VPC. Alcuni fornitori richiedono l'abilitazione PFS per la fase 2. Controllare le istruzioni del fornitore e utilizzare le politiche personalizzate se PFS è richiesto.

Opzioni di crittografia e autenticazione per l'auto-negoziazione IPsec Fase 2
Crittografia Autenticazione Gruppo DH
1 aes128 sha256 Disabilitato
2 aes192 sha384 Disabilitato
3 aes256 sha512 Disabilitato
Opzioni di crittografia in modalità combinata per IPsec auto-negoziazione Fase 2
Crittografia Autenticazione Gruppo DH
1 aes128gcm16 Disabilitato Disabilitato
2 aes192gcm16 Disabilitato Disabilitato
3 aes256gcm16 Disabilitato Disabilitato

Casi di utilizzo di VPN for VPC

Caso di utilizzo 1: connessione VPN a un singolo dispositivo peer remoto dello stesso tipo associato a una o più reti peer

Sia le VPN basate sull'instradamento che quelle basate sulla politica consentono agli utenti di connettersi a un singolo dispositivo peer remoto associato a una o più reti.

Questo caso d'uso non si applica per connessioni tra una VPN basata su criteri e una VPN basata su instradamento. Per ulteriori informazioni, vedi Limitazioni note.

Caso d'uso VPN singolo peer
Casi d'uso VPN singolo peer

Caso di utilizzo 2: connessioni VPN a più dispositivi peer remoti

Sia le VPN basate sulla politica che quelle basate sull'instradamento consentono agli utenti di connettersi a più dispositivi peer remoti associati a diversi VPC / ambienti utilizzando più connessioni VPN

Caso d'uso VPN di più peer
Casi di utilizzo VPN di più peer

Caso d'uso 3: configurazione avanzata della VPN utilizzando un FQDN

Il seguente caso di utilizzo illustra un cliente che ha un VPC in IBM Cloud e desidera connettere il proprio sito in loco con un singolo gateway VPN. Il gateway VPN in loco è dietro un dispositivo NAT e non ha un indirizzo IP pubblico. L'identità IKE locale del gateway VPN in loco è l'indirizzo IP privato di cui è proprietario. Un FQDN è associato all'indirizzo IP pubblico della periferica NAT.

Configurazione avanzata VPN con FQDN
Configurazione avanzata VPN con FQDN

Caso d'uso 4: Distribuzione del traffico per una VPN basata sulle rotte

Una VPN basata su route ha 2 tunnel attivi nel backend. Quando entrambi i tunnel VPN sono attivi, viene utilizzato solo un tunnel per instradare il traffico VPN sul tunnel.

La VPN utilizza il tunnel con l'IP pubblico piccolo come percorso di uscita primario. Quando il percorso di uscita primario è disattivato, il traffico scorre attraverso il percorso secondario. Il motivo per cui si utilizza un solo tunnel per instradare il traffico è quello di evitare il problema dell'instradamento asimmetrico. Il diagramma seguente illustra la configurazione predefinita. Quando si crea una rotta con destinazione 10.1.0.0/24 e l'hop successivo è la connessione VPN, se sia tunnel 1 che tunnel 2 sono attivi, viene restituito l'IP privato 10.254.0.2 dell'appliance VPN per la creazione della rotta.

Il filtraggio dello stato del protocollo su un'interfaccia di rete virtuale offre opzioni per risolvere il problema del routing asimmetrico. Per ulteriori informazioni, vedere Modalità di filtraggio dello stato del protocollo.

Distributed traffic disabled:
Distributed traffic feature is disabled

Quando si creano connessioni per una VPN basata su route, è ora possibile abilitare la distribuzione del traffico tra le Up gallerie della connessione del gateway VPN quando l'hop successivo di una route VPC è la connessione VPN. Per realizzare questa modalità di ridondanza attiva/attiva, è necessario attivare la funzione "distribuisci traffico" quando si creano o si aggiungono connessioni a un gateway VPN.

Come mostrato nel diagramma seguente, il traffico in uscita viene instradato verso i 2 tunnel in modo dinamico. Quando i tunnel sono Up, gli indirizzi IP privati 10.254.0.2 e 10.254.0.3 vengono restituiti e il servizio di rete VPC crea 2 percorsi. Poiché queste rotte hanno la stessa priorità, il traffico scorre verso tunnel 1 e tunnel 2 in modo dinamico.

Traffico distribuito abilitato:
VPN attivo-attivo*La funzione di traffico distribuito è

Per utilizzare questa funzione, il dispositivo on-premise deve supportare il routing asimmetrico per ottenere prestazioni di rete più elevate. Inoltre, tenete presente che non tutti i gateway VPN on-premise supportano questo caso d'uso. Ad esempio, se il traffico VPN in entrata e in uscita proviene da tunnel diversi, il traffico potrebbe essere bloccato da dispositivi VPN o firewall in sede.