Ordine delle route

Questa pagina descrive come funzionano le route personalizzate con gli hop successivi dei tunnel Cloud VPN in Google Cloud.

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

Tipi di percorso

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 dell'hop successivo definisce un percorso in 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 gli annunci BGP e invia i messaggi BGP a un gateway VPN peer. Il router Cloud crea e rimuove automaticamente le route dinamiche personalizzate nella rete VPC, ovvero le route con destinazioni in una rete peer. Pubblicizza inoltre le route a una rete peer, cioè le route verso gli intervalli IP delle subnet nella tua rete VPC o verso destinazioni personalizzate specificate da te in una configurazione di router Cloud. La modalità di routing dinamico della rete VPC controlla l'insieme di route che il router Cloud importa ed esporta.

  • Un tunnel VPN classica basato su criteri o route utilizza il routing statico. Se utilizzi la console Google Cloud per creare uno di questi tunnel, Google Cloud crea automaticamente route statiche personalizzate in base agli intervalli IP remoti che hai specificato nella configurazione 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 applicabilità e ordine ben definiti quando si seleziona l'hop successivo a cui inviare un pacchetto. Gli esempi seguenti mostrano interazioni comuni tra route e Cloud VPN.

Interazione con le route di subnet

La tabella seguente mostra l'interazione delle route di subnet e 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 a 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
Lo stesso dell'intervallo IP on-premise		 Google Cloud non consente di creare una route statica personalizzata la cui destinazione è 10.2.0.0/16 e il cui hop successivo è un tunnel Cloud VPN. Il router Cloud associato al tunnel ignora eventuali route annunciate con una 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
Lo stesso dell'intervallo IP on-premise		 La VPN classica non supporta IPv6. Il router Cloud associato al tunnel ignora eventuali route annunciate con una 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
Intervallo IP più ampio rispetto a quello on-premise
(subnet mask più piccola)		 Google Cloud non consente di creare una route statica personalizzata 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 pubblicizzata le cui destinazioni corrispondono o rientrano in 10.0.0.0/8, tra cui 10.2.0.0/16. Il traffico destinato a 10.0.0.0/8 rimane nella tua rete VPC.
fd20:a:b::/48
Intervallo IP più ampio rispetto a quello on-premise
(subnet mask più piccola)		 La VPN classica non supporta IPv6. Il router Cloud associato al tunnel ignora qualsiasi route pubblicizzata le cui destinazioni corrispondono o rientrano in fd20:a:b::/48, tra cui fd20:a:b:c::/64. Il traffico destinato a fd20:a:b::/48 rimane nella tua rete VPC.
10.2.99.0/24
Intervallo IP più ristretto rispetto a quello on-premise
(subnet mask più lunga)		 Google Cloud consente di creare una route statica personalizzata 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 rete VPC. Il router Cloud associato al tunnel accetta una route pubblicizzata 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
Intervallo IP più ristretto rispetto a quello on-premise
(subnet mask più lunga)		 La VPN classica non supporta IPv6. Il router Cloud associato al tunnel accetta una route pubblicizzata 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 sono inattivi

Routing dinamico (BGP)

Quando un tunnel VPN classica che utilizza il routing dinamico o un tunnel VPN ad alta disponibilità non funziona, il router Cloud che lo gestisce rimuove automaticamente le route apprese. Il tempo necessario per rilevare l'interruzione varia a seconda dell'abilitazione o meno del Bidirectional Forwarding Detection (BFD). Se il protocollo BFD è abilitato, il rilevamento viene eseguito alla scadenza del timer di holddown di BGP. In caso contrario, il rilevamento avviene in meno di 60 secondi. Le route apprese possono essere riaggiunti quando il tunnel viene ristabilito.

Questo processo è completamente automatico, ma può comunque causare la 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 un hop successivo valido che non ha stabilito un'associazione di sicurezza IKE (SA). Se un tunnel Cloud VPN ha stabilito un SA IKE, Google Cloud lo considera operativo. Un tunnel Cloud VPN operativo passa il traffico solo se viene 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 disponi di più route statiche personalizzate per la stessa destinazione, ognuna delle quali ha un tunnel Cloud VPN dell'hop successivo diverso, Google Cloud prende in considerazione solo i tunnel che hanno stabilito SA IKE (fase 1). I tunnel inattivi, ossia che non hanno SA IKE valide, vengono ignorati prima di prendere in considerazione la priorità delle route.

    Ad esempio, supponi di avere tre route statiche personalizzate per la destinazione 192.168.168.0/24: una con priorità 10 il cui tunnel Cloud VPN nell'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 è attivo. Google Cloud invia il traffico al secondo hop successivo, anche se la sua route ha una priorità inferiore rispetto a quella il cui hop successivo non è attivo. Se il primo tunnel viene ristabilito, Google Cloud lo considera un hop successivo valido e al suo posto utilizza quella route.

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

    Ad esempio, supponi di avere una route statica personalizzata per 192.168.168.0/24 il cui tunnel Cloud VPN 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 di hop successivo a un altro, dovresti comunque aspettarti una perdita di pacchetti. I pacchetti in transito potrebbero andare persi e devono essere ritrasmessi.

ECMP sui tunnel

Per il routing sia dinamico che statico, se esiste più di una route personalizzata per la stessa destinazione e ha la stessa priorità e un tunnel dell'hop successivo attivo (stabilito da IKE SA), Google Cloud utilizza il routing ECMP (a parità di costo) 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é questo è attivo.

Per testare il comportamento di ECMP, utilizza iperf3 per inviare più flussi TCP simultanei, idealmente da più istanze di macchine virtuali (VM) Google Cloud, attraverso i tunnel Cloud VPN. Se devi convalidare il comportamento ECMP, non utilizzare il protocollo ICMP (ping) per eseguire i test. Un test ping da un'istanza VM non è sufficiente per testare il traffico in uscita basato su ECMP attraverso i tunnel Cloud VPN, perché viene selezionato un solo tunnel se un'origine e una destinazione sono fisse. ICMP non hanno il concetto di porte ed è un protocollo fisso, quindi l'hash viene calcolato solo a partire da due informazioni: l'indirizzo di origine e l'indirizzo di destinazione (un hash a due tuple).

Passaggi successivi