Problemi noti per i gateway VPN

I problemi noti sono bug identificati o comportamenti inaspettati che non sono stati risolti prima del rilascio, ma non erano abbastanza critici da ritardarlo. Questi problemi vengono comunicati all'utente, spesso con delle soluzioni, e sono prioritari per la risoluzione a breve termine da parte del team di sviluppo.

I problemi noti per i gateway VPN site-to-site sono i seguenti:

• Un gateway VPN per VPC accetta solo pacchetti VPN con incapsulamento UDP di pacchetti IPsec ESP. I pacchetti ESP(Encapsulating Security Payload) non sono accettati. Assicurati che la funzione NAT-T sia abilitata sul tuo dispositivo VPN in loco. Inoltre, assicurarsi che le porte UDP 500 e 4500 siano consentite sia per la VPC NACL IBM che per le reti peer.

  NAT-T consente al traffico VPN di passare attraverso i dispositivi NAT incapsulando i pacchetti IPsec in UDP. Senza NAT-T, i pacchetti IPsec potrebbero essere eliminati dai dispositivi NAT perché non sono in grado di gestire correttamente il traffico ESP. Per ottenere una connettività VPN affidabile attraverso i dispositivi NAT, è necessario abilitare NAT-T sul dispositivo on-premises.

• Quando più reti, sottoreti o entrambe sono associate a un gateway VPN IBM Cloud o a un dispositivo in loco, evita di combinare VPN basate sulla politica e sulla rotta. Le VPN basate sulla politica creano un tunnel per ogni intervallo di reti di destinazione. Tuttavia, le VPN basate sull'instradamento instradano tutto a un dispositivo peer attraverso un singolo tunnel. Pertanto, quando sono configurati più intervalli di rete, è possibile stabilire solo un singolo tunnel associato a un singolo intervallo di rete. La combinazione di sottoreti contigue in un unico superset CIDR è un valido workaround.

• Le sottoreti peer di una connessione gateway VPN non possono sovrapporsi.

• Transit Gateway il filtraggio dei prefissi non è attualmente supportato per i gateway VPN.

• Quando si collega una VPN basata su criteri con un peer basato su route (o una VPN statica basata su route con un peer basato su criteri), utilizzare un solo intervallo di rete per entrambi i lati. Una VPN basata su criteri utilizza un tunnel per ogni rete associata, mentre una VPN basata su percorsi richiede un solo tunnel. Le connessioni tra diversi tipi di VPN associate a più intervalli di rete su entrambi i lati potrebbero funzionare solo per un intervallo di rete.

  

  Se possibile, combina le sottoreti contigue in un singolo intervallo di rete in una configurazione VPN. Ad esempio, le sottoreti 192.168.0.0/24 e 192.168.1.0/24 possono essere definite come 192.168.0.0/23 in un VPN o in una configurazione di instradamento.

• Un gateway VPN basato sulla politica IBM Cloud risiede nella zona associata alla sottorete che selezioni durante il provisioning. Il gateway VPN serve solo istanze di server virtuali nella stessa zona della VPC. Pertanto, le istanze in altre zone non possono utilizzare il gateway VPN per comunicare con una rete privata in loco. Per la tolleranza di errore di zona, distribuisci un gateway VPN per ogni zona.

• Un gateway VPN basato sulla rotta IBM Cloud risiede nella zona associata alla sottorete che selezioni durante il provisioning. Si consiglia che un gateway VPN serva solo le istanze del server virtuale nella stessa zona del VPC. Aggiungendo rotte di uscita personalizzate alla tabella di routing per indirizzare il traffico, le istanze in altre zone possono utilizzare il gateway VPN basato su rotte per comunicare con una rete privata in sede; tuttavia, questa configurazione non è consigliata. Per la tolleranza di errore di zona, distribuisci un gateway VPN per ogni zona.

• Quando si configurano e ottimizzano le connessioni VPN IPsec site - to - site, è possibile che si verifichino problemi di prestazioni di rete, uno dei quali è correlato al bloccaggio MTU (Maximum Transmission Unit) e MSS (Maximum Segment Size). Per ulteriori informazioni, consultare IBM site - to - site VPN Maximum Transmission Unit(MTU)clamping.

• Quando una rotta utilizza una connessione gateway VPN come hop successivo, deve essere presente in una tabella di routing in uscita associata alle sottoreti VPC. Inoltre, quando il gateway VPN inoltra il traffico nel tunnel VPN, controlla se l'IP di origine del traffico si trova all'interno della sottorete collegata alla tabella di routing. Se l'IP di origine si trova al di fuori di tale sottorete, il traffico non viene né crittografato né inviato attraverso il tunnel VPN al gateway peer. Ad esempio, se il gateway VPN riceve traffico instradato attraverso la tabella di routing in ingresso, il traffico non viene inoltrato nel tunnel VPN perché l'IP di origine è al di fuori della sottorete collegata alla tabella di routing.

  La creazione di una rotta in una tabella di routing in ingresso con una connessione gateway VPN come hop successivo non è supportata.

• L'impostazione delle identità IKE locali e peer (indirizzo, FQDN o hostname) è facoltativa quando si crea un gateway VPN. Tuttavia, l'aggiornamento successivo dell'indirizzo o dell'FQDN del peer potrebbe influire sulla connettività VPN:

  • Se non si specificano le identità IKE locali e peer, il gateway utilizza automaticamente i valori predefiniti: l'IP pubblico del gateway VPN viene utilizzato come identità IKE locale e l'IP pubblico del gateway peer viene utilizzato come identità IKE peer. Questa impostazione predefinita consente di mantenere una connessione VPN stabile anche se l'indirizzo del peer cambia.
  • Se si impostano esplicitamente le identità IKE locali e peer, si bloccano valori specifici. In questo caso, l'aggiornamento dell'indirizzo del peer o dell'FQDN richiede l'eliminazione e la ricreazione della connessione VPN per evitare di interrompere la connettività.