Considerazioni sulla pianificazione per i gateway VPN

Prima di creare un gateway VPN, esaminare le considerazioni di pianificazione, i requisiti di configurazione e le altre linee guida applicabili.

Considerazioni generali

Prima di creare un gateway VPN, è necessario esaminare le seguenti considerazioni generali:

  • Assicurati di avere spazio sufficiente nella sottorete per il gateway. Per garantire che le funzioni di gestione VPN e di failover possano funzionare correttamente, crea il gateway VPN in una sottorete senza altre risorse VPC. Questo processo garantisce la disponibilità di un numero sufficiente di indirizzi IP privati per il gateway. Un gateway VPN ha bisogno di quattro indirizzi IP privati per gestire l'alta disponibilità e gli aggiornamenti continui. Poiché in una sottorete sono riservati al massimo cinque indirizzi IP privati, la dimensione minima della sottorete che può essere utilizzata per ospitare un gateway VPN è /28 (16 indirizzi IP o netmask 255.255.255.240).
  • Per impostazione predefinita, PFS (Perfect Forward Secrecy) è 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 si richiede PFS.
  • Il gateway IBM VPN utilizza il suo indirizzo IP pubblico come identità locale IKE e designa l'indirizzo IP pubblico del peer come identità peer IKE per impostazione predefinita. È possibile specificare le identità IKE locali e peer per sovrascrivere questo funzionamento predefinito quando si crea una connessione VPN. Se il gateway VPN peer si trova dietro un firewall NAT e l'indirizzo IP pubblico del peer non è associato all'interfaccia del gateway VPN peer, è possibile regolare la configurazione del gateway VPN peer. Questa configurazione garantisce che l'indirizzo IP pubblico del peer sia usato come identità IKE. Puoi anche specificare l'identità IKE del peer quando crei una connessione VPN per utilizzare l'identità IKE reale del tuo gateway VPN del peer.
  • Se il gateway VPN peer si trova dietro un dispositivo NAT e non ha un IP pubblico, è possibile associare un FQDN all'indirizzo IP NAT. È quindi possibile utilizzare questo FQDN al posto di un indirizzo IP quando si crea una connessione VPN. In questo modo, l'identità IKE peer predefinita è l'FQDN. È possibile specificare l'identità IKE del peer per sovrascrivere questo valore predefinito quando si crea la connessione VPN, se il valore predefinito non corrisponde all'identità IKE effettiva del gateway VPN peer.
  • È possibile selezionare una modalità di instaurazione (bidirezionale o solo peer) quando si crea una connessione VPN. Tieni presente che se il tuo gateway VPN peer non ha un indirizzo IP pubblico durante la creazione di una connessione VPN, devi impostare il gateway VPN sulla modalità Solo peer. In questo caso, il gateway VPN peer è responsabile del ripristino della connessione in caso di interruzione.
  • Dopo aver effettuato il provisioning di una connessione VPN, non è possibile modificare il tipo di indirizzo del gateway peer da indirizzo IP a FQDN o da FQDN a indirizzo IP.
  • IBM Cloud VPC supporta la risoluzione FQDN attraverso i DNS Services. Se la VPC in cui risiede il gateway VPN si trova nella rete consentita di un'istanza DNS privata, i record DNS aggiunti in questo DNS privato sono risolvibili nel gateway VPN.

Considerazioni sui gateway VPN basati su criteri

Prima di creare un gateway VPN basato su criteri, esaminare le seguenti considerazioni:

  • Il gateway VPN basato su criteri viene creato nella zona associata alla sottorete selezionata. Il gateway VPN può connettersi alle istanze del server virtuale solo in questa zona. Di conseguenza, le istanze in altre aree non possono utilizzare questo gateway VPN per comunicare con l'altra rete. Per la tolleranza di errore di zona, distribuisci un gateway VPN per ogni zona.
  • Per i gateway VPN basati su criteri, i percorsi non vengono rilevati automaticamente. La tabella di routing deve essere configurata per accettare percorsi dal gateway VPN e i percorsi propagati sono limitati ai prefissi CIDR definiti nella politica VPN. Vedi Percorsi pubblicitari.

Considerazioni sui gateway VPN basati sulle rotte

Prima di creare un gateway VPN basato sulle rotte, è necessario esaminare le seguenti considerazioni:

Considerazioni sulle connessioni VPN basate su percorsi statici

Prima di creare una connessione VPN basata su una rotta statica, è necessario esaminare le seguenti considerazioni:

  • Se si intende impostare una rotta predefinita (0.0.0.0/0) in una tabella di routing VPC per far passare il traffico in uscita dalle risorse VPC attraverso un gateway VPN, creare il gateway VPN in una sottorete diversa da quella associata alla tabella di routing. In caso contrario, questo percorso predefinito provoca un conflitto di routing per il gateway VPN e può interrompere la connessione VPN.
  • IBM Cloud VPN for VPC supporta solo una VPN basata su route per zona e per VPC.

Considerazioni sulle connessioni VPN basate su percorsi dinamici

Prima di creare una connessione VPN basata su percorsi dinamici, è necessario esaminare le seguenti considerazioni:

  • Per abilitare il routing dinamico tra il gateway VPN e i dispositivi on-premises, è necessario creare un gateway di transito e collegarlo al gateway VPN. In questa configurazione, il gateway di transito gestisce e distribuisce automaticamente il traffico tra i dispositivi. Vedere Considerazioni sulla connessione del gateway VPN con Transit Gateway. Tenete presente che il routing statico non supporta questo tipo di collegamento.
  • È possibile creare connessioni VPN dinamiche in qualsiasi momento, anche prima che il gateway VPN sia collegato al gateway di transito. Tuttavia, il traffico scorre solo quando il gateway VPN è collegato al gateway di transito.
  • Per le VPN dinamiche basate sulle rotte è necessario un valore ASN locale e peer. L'ASN locale identifica la rete locale per il peering BGP, mentre l'ASN del peer identifica la rete peer remota con cui la VPN scambia le rotte. Se non si specifica il valore ASN locale, il gateway VPN viene creato con l'ASN predefinito di 64520.
  • Alcuni valori ASN sono limitati quando si crea un gateway VPN e non possono essere utilizzati come ASN locali o peer, tra cui 0, 13884, 36351, 64512, 64513, 65100, 65200–‍65234, 65402‍–‍65433, 65500, o 4201065000‍–‍4201065999. Questi valori sono riservati o fanno parte di intervalli ASN privati e possono causare conflitti di routing.
  • Quando si collega un gateway di transito a una VPN, non è possibile modificare il valore ASN finché non si rimuove la connessione al servizio.
  • Più gateway VPN possono collegarsi allo stesso gateway di transito, ma ogni gateway VPN può collegarsi a un solo gateway di transito.
  • Se si intende utilizzare un CIDR non RFC 1918 per la connessione al gateway di transito che non rientra negli intervalli IP privati standard (10.0.0.0/8, 172.16.0.0/12, o 192.168.0.0/16), è necessario aggiungere una rotta delegate-VPC nella tabella di routing in uscita della VPC. Questa rotta deve puntare al CIDR scelto e deve essere associata alla sottorete VPN nella stessa zona. Vedere Considerazioni sulla connessione del gateway VPN per il gateway di transito.
  • Ogni IBM VPN supporta 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, 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. Per ulteriori informazioni, vedere Quante rotte supporta VPN for VPC per peer VPN per una connessione dinamica basata su rotte?

IBM Power Virtual Servers automatizzare la distribuzione del vostro spazio di lavoro

È disponibile un progetto di automazione VPN site - to - site che fornisce un modulo Terraform per creare un gateway VPN site - to - site. Consente inoltre una connessione sicura via Internet dalla rete locale on-premises alle risorse private di uno spazio di lavoro Power Virtual Server. Questo modulo Terraform Infrastructure as Code ( IaC ) crea un gateway e una connessione VPN basata su criteri con criteri locali e peer. Per impostazione predefinita, vengono creati gli spazi di lavoro Transit Gateway e IBM Power Virtual Server, ma è possibile ignorare l'impostazione predefinita specificando quelli esistenti.

Il repository GitHub per questo progetto di automazione si trova nella cartella IBM / power-vpn-gateway repository GitHub. Il file README del progetto crea un gateway VPN e lo collega a uno spazio di lavoro Power Virtual Server nuovo o esistente, fornendo un accesso sicuro all'infrastruttura IBM Cloud Power.