Quali tipi di connessioni VPN supporta IBM Cloud per le VPC?

IBM Cloud supporta i seguenti tipi di VPN per VPC:

• VPN da sito a sito: utilizzata per la connettività da rete a rete.
• VPN client-to-site: utilizzata per l'accesso remoto sicuro di singoli utenti.

Che cos'è IBM Cloud VPN per VPC (site-to-site)?

IBM Cloud VPN per VPC fornisce una connettività sicura e crittografata tra il vostro IBM Cloud Virtual Private Cloud (VPC) e altre reti private, come gli ambienti on-premise. Utilizza i tunnel IPsec su Internet per proteggere i dati in transito. Per saperne di più, vedere gateway VPN sito-sito e IBM Cloud VPN per la pagina del prodotto VPC.

Qual è la differenza tra VPN for VPC, Transit Gateway e Direct Link?

La tabella seguente fornisce le differenze tra VPN for VPC, Transit Gateway e Direct Link:

Perché utilizzare una VPN site-to-site piuttosto che una VPN client-to-site?

Utilizzate una VPN site-to-site per proteggere il trasferimento dei dati tra il vostro IBM Cloud VPC e altre reti private, supportando le architetture cloud ibride e la comunicazione tra reti. Utilizzate una VPN client-to-site quando singoli utenti necessitano di un accesso sicuro e crittografato da postazioni remote, ideale per scenari di lavoro a distanza o per appaltatori terzi.

Quali tipi di VPN site-to-site supporta IBM Cloud VPC?

IBM Cloud VPC supporta i seguenti tipi di VPN da sito a sito:

• VPN basata su criteri: Indirizza il traffico in base a criteri IP definiti, funziona in modalità attiva-standby, ideale per le reti statiche. Ulteriori informazioni.
• VPN basata sulle rotte: utilizza interfacce tunnel virtuali e routing dinamico (BGP), supporta la ridondanza attiva-attiva, ideale per architetture complesse e scalabili. Ulteriori informazioni.

Quali sono i casi d'uso tipici delle VPN site-to-site IBM Cloud?

IBM Cloud site-to-site VPN for VPC contribuisce all'estensione del cloud ibrido, alla connettività di backup e alla comunicazione VPC interregionale. Vedere i casi d'uso delle VPN site-to-site.

VPN for VPC può servire come connettività di backup?

Sì, VPN for VPC è comunemente usato come backup di Direct Link o come connettività secondaria accanto a Transit Gateway. Vedere Disponibilità elevata.

In che modo IBM Cloud site-to-site VPN protegge i miei dati?

VPN for VPC utilizza algoritmi di IPsec/IKEv2 algoritmi di crittografia avanzati per garantire la riservatezza e l'integrità dei dati in transito. Per saperne di più sulla negoziazione delle politiche.

La VPN influisce sulla velocità della mia rete?

La crittografia VPN aggiunge un overhead minimo. IBM Cloud ottimizza la VPN per ottenere prestazioni affidabili, ma la velocità effettiva dipende dalle condizioni e dalla configurazione della rete.

Come si risolvono i problemi di connessione a IBM Cloud VPN?

Per risolvere i problemi di connessione a IBM Cloud VPN, controllare lo stato del tunnel del dashboard VPN, convalidare i percorsi, rivedere l'accesso e le regole del firewall. Per ulteriori informazioni, vedere Risoluzione dei problemi da sito a sito. Per la risoluzione dei problemi relativi agli algoritmi negoziati, proposti e ricevuti nei criteri IKE e IPsec, vedere Come si controllano i registri IPsec?

Ci sono notifiche per l'indisponibilità del servizio VPN?

Per conoscere l'indisponibilità del servizio VPN, utilizzare il processo di notifica standard di IBM Cloud per gli eventi di manutenzione. Vedere la pagina IBM Cloud Status.

Qual è il punto di partenza per impostare una VPN site-to-site per la mia VPC?

Per iniziare a configurare una VPN site-to-site per la VPC, è necessario creare un gateway VPN. Vedere Creazione di un gateway VPN.

Quante connessioni VPN site-to-site posso impostare per IBM Cloud VPC?

Per determinare il numero di connessioni per la VPN da sito a sito, vedere Quote VPN.

Dove posso trovare i dettagli dei prezzi per IBM Cloud site-to-site VPN for VPC?

Per conoscere i dettagli dei prezzi di IBM Cloud site-to-site VPN for VPC, consultare la scheda Prezzi.

Quali sono le best practice di sicurezza da seguire con IBM Cloud VPN?

Utilizzate una crittografia forte, aggiornate regolarmente le configurazioni e applicate controlli di accesso rigorosi.

Quando creo un gateway VPN, posso creare contemporaneamente delle connessioni VPN?

Nella console IBM Cloud è possibile creare contemporaneamente il gateway e la connessione. Se utilizzi l'API o la CLI, le connessioni VPN devono essere create dopo che è stato creato il gateway VPN.

Se si elimina un gateway VPN con connessioni VPN collegate, cosa succede alle connessioni?

Le connessioni VPN vengono eliminate insieme al gateway VPN.

Le politiche IKE o IPsec vengono eliminate se elimino un gateway VPN o una connessione VPN?

No, i criteri IKE e IPsec non vengono eliminati perché possono essere applicati a più connessioni.

Come vengono scelti gli algoritmi di crittografia per IKE e IPsec in una connessione VPN site-to-site?

Quando si selezionano più algoritmi in un criterio IKE o IPsec, la selezione finale dipende da quale parte sceglie l'algoritmo e dall'ordine di valutazione degli algoritmi. Le differenze di ordine possono portare a risultati diversi nella negoziazione.

• Quando IBM Cloud avvia la connessione VPN, invia gli algoritmi nell'ordine configurato e il peer effettua la selezione finale. Ad esempio, se IBM Cloud propone aes128, aes256, e il peer propone aes256, aes128, potrebbero essere selezionati aes128 o aes256 a seconda dell'implementazione del peer.
• Quando IBM Cloud è il risponditore, seleziona il primo algoritmo di corrispondenza in base all'ordine configurato. Ad esempio, se IBM Cloud è configurato con aes128, aes256, e il peer propone aes256, aes128, allora viene selezionato aes128.

Per garantire una selezione coerente degli algoritmi, configurare algoritmi IKE e IPsec identici e mantenere lo stesso ordine di priorità sia sul gateway IBM Cloud VPN che sul gateway peer.

Come si controllano i log IPsec?

Per visualizzare i registri IPsec per gli algoritmi negoziati, proposti e ricevuti, procedere come segue:

1. Innanzitutto, configurare un'istanza di registrazione per l'istanza VPN. Per ulteriori informazioni, vedere Configurazione del servizio di routing dei registri IBM Cloud.
2. Dopo aver impostato l'istanza di registrazione, è possibile accedere ed esaminare le voci di registro IPsec generate dalla VPN. Per informazioni sul formato del registro e sui campi disponibili, vedere Registri per VPN for VPC.

Per il debug delle connessioni, assicurarsi che le proposte ricevute dal peer abbiano almeno un algoritmo corrispondente al criterio IKE e IPsec del lato IBM. Se non esiste un algoritmo di corrispondenza tra la configurazione del peer e quella di IBM Cloud, la connessione non viene stabilita.

Cosa succede a un gateway VPN se si cerca di eliminare la sottorete in cui si trova?

La sottorete non può essere eliminata se sono presenti istanze di server virtuali, compreso il gateway VPN.

Ci sono politiche IKE e IPsec predefinite?

Sì. Quando crei una connessione VPN senza fare riferimento a un ID politica (IKE o IPsec), viene utilizzata la negoziazione automatica.

Perché devo scegliere una sottorete durante il provisioning del gateway VPN?

È necessario scegliere una sottorete quando si effettua il provisioning di un gateway VPN in IBM Cloud perché il gateway viene distribuito all'interno di una sottorete VPC per stabilire la connettività. Una VPN basata su route può supportare la connettività in tutte le zone, ma il gateway stesso richiede quattro indirizzi IP privati disponibili nella sottorete scelta per garantire un'elevata disponibilità e la manutenzione automatica. È preferibile utilizzare una sottorete dedicata di dimensione 16 per il gateway VPN, dove la lunghezza del prefisso della sottorete è inferiore o uguale a 28.

Cosa devo fare se sto utilizzando gli ACL sulle sottoreti utilizzate per distribuire il gateway VPN?

Assicurarsi che siano presenti regole ACL per consentire il traffico di gestione e il traffico del tunnel VPN. Per ulteriori informazioni, vedere Configurazione delle ACL di rete per l'uso con la VPN.

Cosa fare se si utilizzano le ACL sulle sottoreti che devono comunicare con una rete privata on-premises?

Assicuratevi che siano presenti regole ACL per consentire il traffico tra le istanze del server virtuale nella VPC e la rete privata on-premises. Per ulteriori informazioni, vedere Configurazione delle ACL per l'uso con la VPN.

VPN for VPC supporta configurazioni ad alta disponibilità?

Sì, VPN for VPC supporta l'alta disponibilità in una configurazione Active - Standby per le VPN basate sulla politica e la configurazione Active - Active per una VPN statica, basata sull'instradamento.

Si prevede di supportare VPN SSL?

No, è supportato solo da-sito-a-sito IPsec.

Ci sono delle limitazioni alla velocità effettiva per il VPNaaS da-sito-a-sito?

Sì, il throughput dipende da vari fattori come la modalità VPN, la distribuzione del traffico, le impostazioni crittografiche, la capacità di calcolo, le condizioni di rete e la capacità del dispositivo peer. In condizioni ottimali, una VPN basata su route distribuita in modalità attiva-attiva con l'opzione di distribuzione del traffico abilitata, può supportare un throughput aggregato fino a ~2 Gbps su entrambi i tunnel (in base ai test di benchmark interni di IBM, non è un limite garantito nel vostro ambiente). Per ulteriori informazioni sul throughput della VPN, vedere Miglioramento del throughput e delle prestazioni della VPN site-to-site.

L'autenticazione Pre-Shared Key (PSK) e l'autenticazione IKE basata su certificato sono supportate per VPNaaS?

È supportata solo l'autenticazione PSK.

Puoi utilizzare VPN for VPC come gateway VPN per la tua infrastruttura classica IBM Cloud ?

Sì. Il metodo consigliato per connettere la rete classica a una VPC è quello di utilizzare un IBM Cloud Transit Gateway. Vedere Impostazione dell'accesso all'infrastruttura classica.

Che cos'è una collisione di rekey tra VPN site-to-site?

Una collisione di rekey si verifica quando entrambi i peer VPN tentano di avviare un rekey allo stesso tempo, il che può portare a trattative conflittuali, instabilità del tunnel o caduta delle connessioni. Questo problema è comunemente osservato in IKEv1 perché entrambe le parti devono utilizzare chiavi di durata corrispondente e il protocollo non dispone di meccanismi di gestione delle collisioni, il che lo rende inaffidabile. IKEv1 è anch'esso vecchio e dovrebbe essere evitato se possibile. Tuttavia, IKEv2 supporta i tempi di vita delle chiavi asimmetriche per gestire con garbo i tentativi simultanei di ricancellazione. Se si usa IKEv1, la collisione tra chiavi cancella l'associazione di sicurezza (SA) IKE/IPsec. Per ricreare l'SA IKE/IPsec, imposta lo stato di amministrazione della connessione su down e quindi nuovamente su up. Per ridurre al minimo le collisioni tra le chiavi e mantenere stabili le prestazioni, utilizzare IKEv2.

Come posso inviare tutto il traffico dal lato VPC al lato installato in loco in una VPN basata su una politica?

Per inviare tutto il traffico dal lato VPC al lato on-premises, impostare i CIDR dei peer su 0.0.0.0/0 quando si crea una connessione.

Quando una connessione viene creata con successo, il servizio VPN aggiunge un CIDR 0.0.0.0/0 attraverso la rotta <VPN gateway private IP> nella tabella di routing predefinita della VPC. Tuttavia, questo nuovo instradamento può causare dei problemi di instradamento, come ad esempio i server virtuali in diverse sottoreti che non sono in grado di comunicare tra loro e i gateway VPN che non comunicano con i gateway VPN in loco.

Per risolvere i problemi di instradamento, vedere Perché i miei gateway VPN o le istanze del server virtuale non comunicano?

Qual è la differenza tra i tipi di connessione VPN basati su percorsi statici e dinamici?

La connessione di routing statico non utilizza BGP per l'annuncio delle rotte e non può pubblicizzare le rotte verso Transit Gateway o la rete locale. Per questa connessione, tutte le rotte devono essere create e gestite manualmente, mentre per la connessione dinamica non è necessaria alcuna configurazione manuale dopo il provisioning iniziale e il collegamento.

Il routing dinamico è supportato quando si crea un gateway VPN basato su percorsi?

Sì, la connessione VPN dinamica è supportata da un gateway VPN basato su route. Vedere Creazione di un gateway VPN per creare una VPN basata su percorsi e selezionare dinamico per il tipo di connessione.

È necessario allegare un Transit Gateway perché la connessione di routing dinamico funzioni?

Sì, è necessario collegare un Transit Gateway affinché la connessione di routing dinamico funzioni correttamente. Senza Transit Gateway, la comunicazione tra il gateway VPN e la rete locale non funziona, anche se la connessione IPsec è stabilita.

Perché è necessario un Transit Gateway per la connessione dinamica basata su route?

Un Transit Gateway è essenziale per il routing dinamico, perché funge da hub centrale per tutte le connessioni all'interno della rete. Il sito Transit Gateway gestisce il routing per tutti gli spokes, comprese le connessioni VPN. Senza Transit Gateway, i raggi non sarebbero in grado di comunicare tra loro, in quanto si affidano all'hub Transit Gateway per facilitare e instradare il traffico tra di loro.

Posso collegare la mia VPN a più Transit Gateway in una connessione VPN basata su percorsi dinamici?

No, ogni gateway VPN può essere collegato a un solo sito Transit Gateway.

È possibile collegare un sito Transit Gateway esistente alla VPN basata su route per il routing dinamico?

Sì, è possibile collegare un sito Transit Gateway esistente alla VPN basata su route per il routing dinamico. Non è necessario creare un nuovo sito Transit Gateway.

Cos'è l'ASN e perché mi serve per il routing dinamico?

Un Autonomous System Number (ASN) è un identificatore unico utilizzato nel Border Gateway Protocol (BGP) per rappresentare un Autonomous System (AS). Funziona in modo simile a un indirizzo IP pubblico in una connessione IPsec e serve come attributo chiave per identificare i dispositivi all'interno di una rete. Ogni dispositivo della rete è assegnato a un ASN specifico e, senza un ASN valido, un gateway VPN non può stabilire con successo una sessione BGP con altri dispositivi della rete.

Qual è l'uso dei CIDR pubblicizzati?

I CIDR pubblicizzati sono intervalli di indirizzi IP statici raggiungibili dalla VPN e pubblicizzati alla rete locale. Questi CIDR sono utili per gli endpoint privati che non possono essere collegati direttamente a un sito Transit Gateway, come ad esempio gli endpoint Secrets Manager o Cloud Object Storage. Pubblicizzando questi CIDR da IBM VPN alla rete on-premises, qualsiasi risorsa all'interno dell'ambiente on-premises può connettersi a questi endpoint.

È necessario configurare i percorsi quando si crea una connessione VPN basata su percorsi dinamici?

No, non è necessario configurare manualmente i percorsi quando si crea una connessione VPN basata su percorsi dinamici. Tutti gli spokes collegati a Transit Gateway si connettono automaticamente alla rete locale.

Quanti percorsi supporta VPN for VPC per peer VPN per una connessione dinamica basata su percorsi?

Ogni gateway IBM VPN supporta fino a un massimo di 120 rotte per ogni peer VPN in una configurazione di routing dinamico. Se questo limite viene superato, la sessione BGP per quel peer si chiude automaticamente. Per ripristinare la sessione, è necessario ridurre il numero di rotte pubblicizzate dalla rete peer on-premises a 120 o meno, quindi attivare la connessione in IBM Cloud per ristabilire la sessione BGP. Inoltre, se l'appliance VPN riceve più di 120 rotte attraverso una combinazione di peer, l'appliance inoltra al gateway di transito solo le prime 120 rotte. Ad esempio, se due peer inviano ciascuno 70 rotte all'appliance VPN, solo le prime 120 rotte vengono propagate al gateway di transito. Se sono necessarie più di 120 rotte, è possibile collegare l'appliance VPN a diversi dispositivi on-premises. Tuttavia, tenete presente che questa configurazione non garantisce l'alta disponibilità o il disaster recovery dell'appliance VPN quando è collegata a diversi dispositivi on-premises.

IBM completa le scansioni ASV trimestrali delle applicazioni VPN del piano dati?

La scansione trimestrale del fornitore di scansione approvato (ASV) è un requisito del Payment Card Industry (PCI) Security Standards Council. La scansione ASV delle applicazioni di dati aerei VPN è solo una responsabilità del cliente. IBM non utilizza ASV per eseguire la scansione delle applicazioni del piano dati perché queste scansioni possono avere un impatto negativo sulle funzioni e sulle prestazioni del carico di lavoro del cliente.

Quali metriche mi vengono addebitate se sto utilizzando il gateway VPN per VPC?

Le seguenti metriche vengono raccolte per la fatturazione del gateway VPN su base mensile:

• Ora istanza gateway VPN: quanto tempo la tua istanza gateway VPN è attiva e in esecuzione.
• Ora di connessione VPN: quanto tempo ogni connessione VPN viene stabilita e mantenuta sul gateway VPN.
• Floating IP: il numero di indirizzi IP flottanti attivi utilizzati dall'istanza del gateway VPN.

Quando si utilizza un gateway VPN, viene addebitato anche tutto il traffico Internet pubblico in uscita, fatturato in base alle tariffe dati VPC.

Quando il traffico non viene instradato attraverso un gateway VPN basato su route?

Se è stata configurata una rotta VPC con una connessione VPN come hop successivo, il traffico potrebbe non essere instradato come previsto a causa delle seguenti condizioni:

• I gruppi di sicurezza associati all'istanza VPC non consentono il traffico. Inoltre, le ACL di rete associate alla subnet dell'istanza o al gateway VPN bloccano il traffico. Assicurarsi che i gruppi di sicurezza e le ACL consentano il traffico previsto. Per ulteriori informazioni, vedere Configurazione delle ACL di rete per l'uso con la VPN.
• Se l'IP di origine del traffico non appartiene a una sottorete associata alla tabella di routing contenente il percorso VPN, il gateway VPN interrompe il traffico. Ad esempio, si consideri una tabella di routing VPC associata solo alla sottorete A e che include una rotta il cui hop successivo è una connessione VPN. Se il traffico raggiunge il gateway VPN ma proviene da un indirizzo IP al di fuori della sottorete A o di qualsiasi altra sottorete collegata alla tabella di routing, il gateway non inoltra il traffico.