Questa pagina descrive il funzionamento delle route personalizzate con gli hop successivi dei tunnel Cloud VPN in Google Cloud.
Per informazioni di base sulle route di Google Cloud, inclusa l'applicabilità e l'ordine delle route e i parametri delle route statiche, consulta la panoramica delle route di Virtual Private Cloud (VPC).
Tipi di route
Un tunnel Cloud VPN può essere un hop successivo per una route personalizzata nella rete VPC. Ogni route personalizzata con un tunnel Cloud VPN come hop successivo definisce un percorso di uscita per i pacchetti che lasciano la rete VPC:
Un router Cloud gestisce sempre un tunnel VPN classica che utilizza il routing dinamico o un tunnel VPN ad alta disponibilità. Il router Cloud riceve annunci BGP e invia messaggi BGP a un gateway VPN peer. Router Cloud crea e rimuove automaticamente le route dinamiche nella rete VPC, ovvero le route con destinazioni in una rete peer. Inoltre, annunci route a una rete peer, ovvero route agli intervalli IP delle subnet nella tua rete VPC o a destinazioni personalizzate da te specificate in una configurazione del router Cloud. La modalità di routing dinamico della rete VPC controlla l'insieme di route che router Cloud importa ed esporta.
Un tunnel VPN classica basato su criteri o su route utilizza il routing statico. Se utilizzi la console Google Cloud per creare uno di questi tunnel, Google Cloud crea automaticamente route statici in base agli intervalli IP remoti specificati nella configurazione di Cloud VPN. Se utilizzi Google Cloud CLI per creare uno di questi tunnel, devi creare manualmente le route statiche che utilizzano il tunnel come hop successivo.
Scenari di esempio
Google Cloud segue un'applicabilità e un ordine ben definiti quando seleziona il successivo hop a cui deve essere inviato un pacchetto. I seguenti esempi mostrano le interazioni comuni tra le route e Cloud VPN.
Interazione con le route di subnet
La tabella seguente mostra come interagiscono le route di subnet e le route personalizzate.
Ogni riga rappresenta un possibile intervallo IP di una subnet in una rete VPC. Gli intervalli on-premise sono 10.2.0.0/16 per IPv4 e fd20:a:b:c::/64 per IPv6.
Il traffico IPv6 è supportato solo dai gateway VPN ad alta disponibilità configurati con un tipo di doppio stack di IPv4 e IPv6.
| Rete VPC | Routing del tunnel Cloud VPN | |
|---|---|---|
| Intervallo IP della subnet Google Cloud | Statica (basata su criteri, basata su route) Solo VPN classica |
Dinamico (BGP) VPN classica o VPN ad alta disponibilità |
10.2.0.0/16Come l'intervallo IP on-premise |
Google Cloud non ti consente di creare una route statica
la cui destinazione è 10.2.0.0/16 e il cui hop successivo è un
tunnel Cloud VPN. |
Il router Cloud associato al tunnel ignora tutte le route pubblicizzate con destinazione 10.2.0.0/16. Il traffico destinato a
10.2.0.0/16 rimane nella rete VPC. |
fd20:a:b:c::/64Come l'intervallo IP on-premise |
La VPN classica non supporta IPv6. | Il router Cloud associato al tunnel ignora tutte le route pubblicizzate con destinazione fd20:a:b:c::/64. Il traffico destinato a
fd20:a:b:c::/64 rimane nella rete VPC. |
10.0.0.0/8Maggiore dell'intervallo IP on-premise (subnet mask più piccola) |
Google Cloud non ti consente di creare una route statica
la cui destinazione è 10.2.0.0/16 e il cui hop successivo è un
tunnel Cloud VPN. |
Il router Cloud associato al tunnel ignora tutti i percorsi pubblicizzati
le cui destinazioni corrispondono o rientrano in 10.0.0.0/8,
incluso 10.2.0.0/16. Il traffico destinato a
10.0.0.0/8 rimane nella rete VPC. |
fd20:a:b::/48Maggiore dell'intervallo IP on-premise (subnet mask più piccola) |
La VPN classica non supporta IPv6. | Il router Cloud associato al tunnel ignora tutti i percorsi pubblicizzati
le cui destinazioni corrispondono o rientrano in fd20:a:b::/48,
incluso fd20:a:b:c::/64. Il traffico destinato a
fd20:a:b::/48 rimane nella rete VPC. |
10.2.99.0/24Maggiore dell'intervallo IP on-premise (subnet mask più lunga) |
Google Cloud ti consente di creare una route statica con la destinazione 10.2.0.0/16 e il tunnel Cloud VPN di hop successivo. Tuttavia, il traffico verso gli indirizzi IP in 10.2.99.0/24 rimane all'interno della rete VPC. |
Il router Cloud associato al tunnel accetta una route annunciata la cui destinazione è 10.2.0.0/16. Tuttavia, il traffico indirizzato agli indirizzi IP in 10.2.99.0/24 rimane all'interno della rete VPC. |
fd20:a:b:c::/80Maggiore dell'intervallo IP on-premise (subnet mask più lunga) |
La VPN classica non supporta IPv6. | Il router Cloud associato al tunnel accetta una route annunciata la cui destinazione è fd20:a:b:c::/64. Tuttavia, il traffico indirizzato agli indirizzi IP in fd20:a:b:c::/80 rimane all'interno della rete VPC.
|
Quando i tunnel sono chiusi
Routing dinamico (BGP)
Quando un tunnel VPN classica che utilizza il routing dinamico o un tunnel VPN ad alta disponibilità si arresta in modo anomalo, il router cloud che lo gestisce rimuove automaticamente le route apprese. Il tempo necessario per rilevare l'interruzione varia a seconda che sia attivato o meno il Bidirectional Forwarding Detection (BFD). Se BFD è abilitato, il rilevamento avviene quando scade il timer di blocco BGP. In caso contrario, il rilevamento avviene in meno di 60 secondi. Le route apprese possono essere aggiunte nuovamente quando il tunnel viene ricostituito.
Questo processo è completamente automatico, ma può comunque comportare una certa perdita di pacchetti durante il tempo necessario al router Cloud per rimuovere le route interessate.
Routing statico
Google Cloud non considera mai un tunnel Cloud VPN come hop successivo valido se non ha stabilito un'associazione di sicurezza IKE (SA). Se un tunnel Cloud VPN ha stabilito un'associazione di sicurezza IKE, Google Cloud lo considera operativo. Un tunnel Cloud VPN operativo consente il passaggio del traffico solo se è selezionato come hop successivo in base all'ordine di routing. Potrebbe essere utilizzato l'hop successivo di un'altra route con una destinazione più specifica o con una priorità più alta.
I seguenti scenari mostrano i comportamenti previsti:
Se hai più route statiche per la stessa destinazione, ciascuna con un tunnel Cloud VPN di hop successivo diverso, Google Cloud prende in considerazione solo i tunnel che hanno stabilito SA IKE (fase 1). I tunnel non attivi, ovvero quelli che non dispongono di SA IKE valide, vengono ignorati prima di prendere in considerazione la priorità della route.
Ad esempio, supponiamo che tu abbia tre route statiche per la destinazione
192.168.168.0/24: una con priorità10il cui tunnel Cloud VPN di hop successivo è inattivo, una seconda con priorità20il cui tunnel di hop successivo è attivo e una terza con priorità30il cui tunnel di hop successivo è attivo. Google Cloud invia il traffico al secondo hop successivo, anche se la sua route ha una priorità inferiore rispetto alla route il cui hop successivo è inattivo. Se il primo tunnel viene ricostituito, Google Cloud lo considera un hop successivo valido e utilizza invece quel percorso.Il traffico viene ignorato se tutti i tunnel Cloud VPN che fungono da hop successivi per le route statiche con la stessa destinazione non sono attivi. Il traffico viene ignorato anche se è presente una route statica per una destinazione più ampia con un tunnel di hop successivo operativo.
Ad esempio, supponiamo che tu abbia una route statica per
192.168.168.0/24il cui tunnel Cloud VPN dell'hop successivo sia inattivo (nessuna SA IKE valida). Anche se hai una route per192.168.0.0/16il cui hop successivo è un tunnel Cloud VPN operativo, il traffico verso192.168.168.0/24viene ignorato. Questo accade perché Google Cloud selezione sempre le route con le destinazioni più specifiche.
Quando il traffico passa da un tunnel Cloud VPN dell'hop successivo a un altro, dovresti comunque aspettarti una perdita di pacchetti. I pacchetti in transito potrebbero essere persi e dover essere nuovamente trasmessi.
ECMP sui tunnel
Per il routing dinamico e statico, se esiste più di una route personalizzata per la stessa destinazione e ha la stessa priorità e un tunnel di hop successivo attivo (IKE SA stabilito), Google Cloud utilizza il routing multipath con costo uguale (ECMP) per distribuire i pacchetti tra i tunnel.
Questo metodo di bilanciamento si basa su un hash, pertanto tutti i pacchetti dello stesso flusso utilizzano lo stesso tunnel finché è attivo.
Per testare il comportamento di ECMP, utilizza iperf3 per inviare più stream TCP simultanei, idealmente da più istanze di macchine virtuali (VM) Google Cloud, tramite i tunnel Cloud VPN. Se devi convalidare il comportamento ECMP, non
utilizzare ICMP (ping) per eseguire i test. Un test ping da un'istanza VM non è sufficiente per testare l'uscita basata su ECMP tramite i tunnel Cloud VPN perché viene selezionato un solo tunnel quando hai una sorgente e una destinazione fisse.
ICMP non ha il concetto di porte ed è un protocollo fisso, pertanto l'hash viene calcolato solo da due informazioni: gli indirizzi di origine e di destinazione (un hash a due tuple).
Passaggi successivi
- Per informazioni sui concetti di base di Cloud VPN, consulta la panoramica di Cloud VPN.
- Per aiutarti a risolvere i problemi comuni che potresti riscontrare durante l'utilizzo di Cloud VPN, consulta la sezione Risoluzione dei problemi.