Ordine delle route

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

Per informazioni di base sulle route Google Cloud, tra cui l'applicabilità delle route e i parametri di ordine e route statici, consulta la panoramica delle route 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 VPN Cloud per l'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 routing dinamico o un tunnel VPN ad alta disponibilità. La Il router Cloud riceve annunci BGP da e invia messaggi BGP a un gateway VPN peer. Il router Cloud crea e rimuove automaticamente route nel tuo VPC ovvero le route con destinazioni in una rete peer. Inoltre, annuncia route a una rete peer, ovvero route all'IP di subnet nella tua rete VPC o per destinazioni che da te specificato nella configurazione di un router Cloud. La modalità di routing dinamico della rete VPC controlla l'insieme di route che Cloud Router importa ed esporta.

  • Un tunnel VPN classica basato su criteri o route utilizza di routing. 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 dimostrare le interazioni comuni tra route e Cloud VPN.

Interazione con le route di subnet

La tabella seguente mostra come interagiscono le route subnet e le route personalizzate. Ogni riga rappresenta un possibile intervallo IP di una subnet in un VPC in ogni rete. 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/16
Come 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 qualsiasi annuncio pubblicizzato percorsi con una destinazione di 10.2.0.0/16. Traffico destinato a 10.2.0.0/16 rimane nella rete VPC.
fd20:a:b:c::/64
Come l'intervallo IP on-premise		 La VPN classica non supporta IPv6. Il router Cloud associato al tunnel ignora qualsiasi annuncio pubblicizzato percorsi con una destinazione di fd20:a:b:c::/64. Traffico destinato a fd20:a:b:c::/64 rimane nella rete VPC.
10.0.0.0/8
Maggiore 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 è una tunnel Cloud VPN. Il Cloud Router 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. Traffico destinato a 10.0.0.0/8 rimane nella rete VPC.
fd20:a:b::/48
Maggiore dell'intervallo IP on-premise
(subnet mask più piccola)		 La VPN classica non supporta IPv6. Il router Cloud associato al tunnel ignora qualsiasi annuncio pubblicizzato percorsi 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 rete VPC.
10.2.99.0/24
Intervallo IP più ristretto rispetto all'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 un annuncio percorso con destinazione 10.2.0.0/16; ma il traffico verso Gli indirizzi IP in 10.2.99.0/24 rimangono all'interno di rete VPC.
fd20:a:b:c::/80
Intervallo IP più ristretto rispetto all'intervallo IP on-premise
(Subnet mask più lunga)		 La VPN classica non supporta IPv6. Il router Cloud associato al tunnel accetta un annuncio percorso con destinazione fd20:a:b:c::/64; ma il traffico verso Gli indirizzi IP in fd20:a:b:c::/80 rimangono all'interno di rete VPC.

Quando i tunnel sono disattivati

Routing dinamico (BGP)

Quando un tunnel VPN classica che utilizza il routing dinamico o un Il tunnel VPN ad alta disponibilità si arresta, il router Cloud e la sua gestione 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. Altrimenti, il rilevamento avviene in meno di 60 secondi. Le route apprese possono essere riaggiunto 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 hop successivo valido se non ha stabilito un'associazione di sicurezza IKE (SA). Se Il tunnel Cloud VPN ha stabilito un'istanza IKE SA, Google Cloud lo considera operativo. Un tunnel Cloud VPN operativo passa il traffico solo se viene selezionato come hop successivo in base alla ordine di routing. Potrebbe essere utilizzato l'hop successivo di un'altra route con una destinazione più specifica o con una priorità più elevata.

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à 10 il cui tunnel VPN Cloud di hop successivo è inattivo, una seconda con priorità 20 il cui tunnel di hop successivo è attivo e una terza con priorità 30 il 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 eliminato se tutti i tunnel Cloud VPN vengono utilizzati come hop successivi per le route statiche con la stessa destinazione non sono attive. Il traffico è diminuito anche se è presente una route statica per una destinazione più ampia con un per il tunnel dell'hop successivo operativo.

    Ad esempio, supponiamo che tu abbia una route statica 192.168.168.0/24 di cui Cloud VPN con hop successivo il tunnel 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 ignorato. Il motivo è che Google Cloud seleziona sempre i percorsi con le destinazioni più specifiche.

Quando il traffico passa da un tunnel Cloud VPN dell'hop successivo a un altro, dovresti comunque aspettarti la perdita di pacchetti. I pacchetti in transito potrebbero essere persi e dover essere nuovamente trasmessi.

ECMP sui tunnel

Sia per il routing dinamico che per quello statico, se esiste più di una route personalizzata la stessa destinazione e che ha la stessa priorità e uno attivo (IKE SA stabilito) nel tunnel dell'hop successivo, Google Cloud utilizza multipath a costo uguale (ECMP) per la distribuzione dei pacchetti tra i tunnel.

Questo metodo di bilanciamento si basa su un hash, quindi tutti i pacchetti dello stesso flusso utilizzano nello stesso tunnel, purché sia attivo.

Per testare il comportamento dell'ECMP, utilizza iperf3 di inviare più flussi TCP simultanei, idealmente da più di macchine virtuali (VM) Google Cloud, attraverso tunnel Cloud VPN. Per verificare il comportamento dell'ECMP, procedi nel seguente modo: Non utilizzare ICMP (ping) per eseguire test. Un test ping di 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 hai un'origine 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