Ordine delle route

Questa pagina descrive il funzionamento delle route personalizzate con hop successivi dei tunnel Cloud VPN in Google Cloud.

Per informazioni di base sulle route, inclusi l'applicabilità e l'ordine delle route e i parametri delle route statiche, consulta la panoramica delle route di Virtual Private Cloud (VPC). Google Cloud

Tipi di route

Un tunnel Cloud VPN può essere un hop successivo per una route personalizzata nella tua rete VPC. Ogni route personalizzata con un tunnel Cloud VPN come hop successivo definisce un percorso di uscita per i pacchetti che escono dalla 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 tua rete VPC, ovvero le route con destinazioni in una rete peer. Inoltre, annuncia le route a una rete peer, ovvero le route agli intervalli IP delle subnet nella tua rete VPC o alle destinazioni personalizzate che specifichi in una configurazione 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 statiche 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 ordine e un'applicabilità ben definiti quando seleziona l'hop successivo a cui deve essere inviato un pacchetto. Gli esempi seguenti mostrano le interazioni comuni tra le route e Cloud VPN.

Interazione con le route di subnet

La seguente tabella mostra l'interazione tra 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 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/16
Uguale all'intervallo IP on-premise		 Google Cloud non 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 tua rete VPC.
fd20:a:b:c::/64
Uguale all'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 tua rete VPC.
10.0.0.0/8
Più ampio dell'intervallo IP on-premise
(subnet mask più piccola)		 Google Cloud non 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 qualsiasi route pubblicizzato 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 tua rete VPC.
fd20:a:b::/48
Più ampio dell'intervallo IP on-premise
(subnet mask più piccola)		 La VPN classica non supporta IPv6. Il router cloud associato al tunnel ignora qualsiasi route pubblicizzato 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 tua rete VPC.
10.2.99.0/24
Più ristretto 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 dell'hop successivo; tuttavia, il traffico verso gli indirizzi IP in 10.2.99.0/24 rimane all'interno della tua rete VPC. Il router Cloud associato al tunnel accetta una route annunciata la cui destinazione è 10.2.0.0/16; tuttavia, il traffico verso gli indirizzi IP in 10.2.99.0/24 rimane all'interno della tua rete VPC.
fd20:a:b:c::/80
Più ristretto 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 verso gli indirizzi IP in fd20:a:b:c::/80 rimane all'interno della tua rete VPC.

Quando i tunnel non sono attivi

Le sezioni seguenti descrivono il comportamento di Cloud VPN quando i tunnel non sono attivi, sia per il routing dinamico che per quello statico.

Routing dinamico (BGP)

Quando un tunnel VPN classica che utilizza il routing dinamico o un tunnel VPN ad alta disponibilità non è più disponibile, router Cloud che lo gestisce rimuove automaticamente le route apprese. Il tempo necessario per rilevare l'interruzione varia in base all'intervallo keepalive e al timer di attesa BGP configurati. Le route apprese possono essere riaggiunte quando il tunnel viene ristabilito.

Questo processo è completamente automatico, ma può comunque comportare una perdita di pacchetti durante il tempo necessario alrouter Cloudr per rimuovere le route interessate.

Routing statico

Google Cloud non considera mai un tunnel Cloud VPN come hop successivo valido che non ha stabilito un'associazione di sicurezza (SA) IKE. Se un tunnel Cloud VPN ha stabilito una SA IKE, Google Cloud la considera operativa. Un tunnel Cloud VPN operativo trasmette il traffico solo se è selezionato come hop successivo in base all'ordine di routing. Potrebbe essere utilizzato l'hop successivo per 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, ognuna con un tunnel Cloud VPN di hop successivo diverso, Google Cloud vengono presi in considerazione solo i tunnel che hanno stabilito SA IKE (fase 1). I tunnel non attivi, ovvero quelli che non hanno SA IKE valide, vengono ignorati prima di considerare la priorità della route.

    Ad esempio, supponiamo di avere tre route statiche per la destinazione 192.168.168.0/24: una con priorità 10 il cui tunnel Cloud VPN dell'hop successivo è inattivo, una seconda con priorità 20 il cui tunnel dell'hop successivo è attivo e una terza con priorità 30 il cui tunnel dell'hop successivo è anch'esso 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 ristabilito, Google Cloud lo considera un hop successivo valido e utilizza quella route.

  • Il traffico viene eliminato se tutti i tunnel Cloud VPN che fungono da hop successivi per le route statiche con la stessa destinazione sono inattivi. Il traffico viene eliminato anche se esiste una route statica per una destinazione più ampia con un tunnel hop successivo operativo.

    Ad esempio, supponiamo di avere una route statica per 192.168.168.0/24 il cui tunnel Cloud VPN dell'hop successivo non è attivo (nessuna SA IKE valida). Anche se hai una route per 192.168.0.0/16 il cui hop successivo è un tunnel Cloud VPN operativo, il traffico verso 192.168.168.0/24 viene eliminato. Questo perché Google Cloud seleziona 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 volo potrebbero essere eliminati e devono essere ritrasmessi.

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 hop successivo attivo (SA IKE stabilito), Google Cloud utilizza il routing ECMP (Equal-cost multipath) per distribuire i pacchetti tra i tunnel.

Questo metodo di bilanciamento si basa su un hash, quindi tutti i pacchetti dello stesso flusso utilizzano lo stesso tunnel finché è attivo.

Per testare il comportamento ECMP, utilizza iperf3 per inviare più stream TCP simultanei, idealmente da più istanze di macchine virtuali (VM)Google Cloud , tramite 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 il traffico in uscita basato su ECMP tramite i tunnel Cloud VPN perché viene selezionato un solo tunnel quando hai un'origine e una destinazione fisse. ICMP non ha il concetto di porte ed è un protocollo fisso, quindi l'hash viene calcolato solo da due informazioni: gli indirizzi di origine e di destinazione (un hash a due tuple).

Passaggi successivi