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 rete VPC. Ogni route personalizzata con una Cloud VPN dell'hop successivo il tunnel definisce un percorso in uscita per i pacchetti che escono dal VPC rete:

  • 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 gli annunci dinamici 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. Lo strumento dinamico modalità di routing La rete VPC controlla l'insieme di route Importazioni ed esportazioni del router Cloud.

  • Un tunnel VPN classica basato su criteri o route utilizza di routing. Se usi la console Google Cloud per creare uno di questi tunnel, Google Cloud crea automaticamente più route in base agli intervalli IP remoti specificato nella configurazione di Cloud VPN. Se utilizzi Google Cloud CLI per creare uno di questi tunnel, devi creare manualmente le route statiche che usano il tunnel come hop successivo.

Scenari di esempio

Google Cloud segue una strategia applicability and Order quando si seleziona l'hop successivo a cui deve essere inviato un pacchetto. I seguenti esempi dimostrare le interazioni comuni tra route e Cloud VPN.

Interazione con 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 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 da gateway VPN ad alta disponibilità che configurato con un tipo di stack doppio di IPv4 e IPv6.

Rete VPC Routing del tunnel Cloud VPN
Intervallo IP della subnet Google Cloud Statica (basata su criteri e 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 consente di creare una route statica la cui destinazione è 10.2.0.0/16 e il cui hop successivo è una 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
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 è una tunnel Cloud VPN. Il router Cloud associato al tunnel ignora qualsiasi annuncio pubblicizzato percorsi le cui destinazioni corrispondono o rientrano in 10.0.0.0/8, tra cui 10.2.0.0/16. Traffico destinato a 10.0.0.0/8 rimane nella 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 annuncio pubblicizzato percorsi le cui destinazioni corrispondono o rientrano in fd20:a:b::/48, tra cui fd20:a:b:c::/64. 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 Cloud VPN di 10.2.0.0/16 destinazione e hop successivo tunnel; Tuttavia, il traffico verso gli indirizzi IP in 10.2.99.0/24 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 periodo di tempo in cui necessario per rilevare la rottura varia a seconda che Rilevamento dell'inoltro bidirezionale (BFD) sia abilitato. Se Il protocollo BFD è abilitato. Il rilevamento si verifica quando scade il timer di holddown 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 il tunnel Cloud VPN come un successivo valido che 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. L'hop successivo per un altro un percorso, con una destinazione più specifica o con una priorità più alta, .

I seguenti scenari mostrano i comportamenti previsti:

  • Se disponi di più route statiche per la stessa destinazione, avere un tunnel Cloud VPN per l'hop successivo diverso, Google Cloud prende in considerazione solo i tunnel che hanno stabilito SA IKE (fase 1). Tunnel che non hanno SA IKE valide, non vengono prese in considerazione prima di considerare la priorità delle route.

    Ad esempio, supponiamo che tu abbia tre route per la destinazione 192.168.168.0/24: una con priorità 10 la cui dell'hop successivo, il tunnel Cloud VPN è inattivo, un secondo con priorità 20 la cui il tunnel dell'hop successivo è attivo e un terzo con priorità 30, il cui tunnel dell'hop successivo è anche in alto. 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 considera e lo usi come hop successivo valido.

  • 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 un percorso per 192.168.0.0/16 il cui hop successivo è un tunnel Cloud VPN operativo, il traffico verso 192.168.168.0/24 è diminuito. 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 corso potrebbero essere abbandonati e richiedere da ritrasmettere.

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, quindi l'hash è calcolati in base a due informazioni: gli indirizzi di origine e di destinazione (un hash a due tuple).

Passaggi successivi