Route statiche

Questa pagina fornisce una panoramica del funzionamento delle route statiche in Google Cloud.

Per una panoramica generale delle route in Google Cloud, consulta la Panoramica delle route.

Considerazioni per la creazione di route statiche

Puoi creare route statiche in due modi:

Puoi scambiare route statiche con una rete VPC in peering come descritto nella sezione Opzioni per lo scambio di route statiche personalizzate della documentazione sul peering di reti VPC.

Parametri di route

Le route statiche supportano i seguenti attributi:

  • Nome e Descrizione. Questi campi identificano il percorso. Il nome è obbligatorio, ma la descrizione è facoltativa. Ogni route nel progetto deve avere un nome univoco.

  • Rete. Ogni route deve essere associata a esattamente una rete VPC.

  • Hop successivo. L'hop successivo identifica la risorsa di rete a cui vengono inviati i pacchetti. Tutti i tipi di hop successivi supportano le destinazioni IPv4 e alcuni tipi di hop successivi supportano le destinazioni IPv6. Per ulteriori informazioni, consulta Passaggi successivi e funzionalità.

  • Intervallo di destinazione. L'intervallo di destinazione è una singola notazione CIDR IPv4 o IPv6.

    Le destinazioni per le route statiche devono rispettare le regole descritte in Interazioni con le route statiche e Interazioni tra route statiche e subnet. La destinazione più ampia possibile per una route statica IPv4 è 0.0.0.0/0. La destinazione più ampia possibile per una route statica IPv6 è ::/0.

  • Priorità. I numeri più bassi indicano priorità più elevate. La priorità più alta possibile è 0 e la priorità più bassa possibile è 65,535.

  • Tag di rete. Puoi applicare una route statica solo a determinate istanze VM nella rete VPC, identificate da un tag di rete. Se non specifichi un tag di rete, Google Cloud applica la route statica a tutte le istanze della rete. Le route statiche con tag non vengono mai scambiate quando si utilizza il peering di rete VPC.

Hop successivi e funzionalità

La seguente tabella riassume il supporto delle funzionalità delle route statiche in base al tipo di hop successivo:

Tipo di hop successivo IPv4 IPv6 ECMP1
Gateway hop successivo (next-hop-gateway)
Specifica un gateway internet predefinito per definire un percorso agli indirizzi IP esterni.
Istanzia hop successivo per nome e zona (next-hop-instance)
Invia pacchetti a una VM hop successivo identificata per nome e zona e nello stesso progetto della route. Per ulteriori informazioni, consulta Considerazioni per le istanze di hop successivo.
Istanzia hop successivo per indirizzo (next-hop-address)
Invia i pacchetti a una VM hop successivo identificata dall'indirizzo IPv4 interno primario o da un indirizzo IPv6 interno o esterno della sua interfaccia di rete. Per maggiori informazioni, consulta Considerazioni per le istanze di hop successivo.		 (Anteprima)
Bilanciatore del carico di rete passthrough interno dell'hop successivo in base al nome regola di forwarding (next-hop-ilb) e alla regione (next-hop-ilb-region)
Invia pacchetti ai backend di un bilanciatore del carico di rete passthrough interno identificato dal nome, dalla regione e, facoltativamente, dal progetto della regola di inoltro. Per maggiori informazioni, consulta Considerazioni per gli hop successivi dei bilanciatori del carico di rete passthrough interni.		 (Anteprima)
Bilanciatore del carico di rete passthrough interno per hop successivo (next-hop-ilb)
Invia pacchetti ai backend di un bilanciatore del carico di rete passthrough interno identificato dall'indirizzo IP della regola di forwarding del bilanciatore del carico. Per ulteriori informazioni, consulta Considerazioni per gli hop successivi del bilanciatore del carico di rete passthrough interno. 		(Anteprima)
Tunnel VPN classica dell'hop successivo (next-hop-vpn-tunnel)
Invia pacchetti a un tunnel VPN classica dell'hop successivo utilizzando il routing basato su criteri o la VPN basata su route. Per ulteriori informazioni, consulta Considerazioni per i prossimi hop del tunnel VPN classica.
1ECMP (Equal-cost multipath) indica che due o più route statici possono condividere lo stesso intervallo di destinazione e la stessa priorità. Anche se puoi creare due o più route statiche in una rete VPC con la stessa destinazione, la stessa priorità e lo stesso hop successivo del gateway internet predefinito, l'effetto è lo stesso di avere una singola route statica che utilizza lo stesso hop successivo del gateway internet predefinito per quella destinazione e priorità.

Progetto e rete dell'hop successivo

Un hop successivo della route statica è associato sia a una rete VPC sia a un progetto:

  • Rete: tranne che per quanto indicato nella tabella seguente, la rete VPC dell'hop successivo deve corrispondere alla rete VPC della route.

  • Progetto: tranne che per quanto indicato nella tabella seguente, l'hop successivo deve trovarsi nel progetto che contiene la rete VPC dell'hop successivo (un progetto autonomo o un progetto host con VPC condiviso). Alcuni passaggi successivi possono trovarsi in progetti di servizio VPC condiviso.

Tipo di hop successivo Può trovarsi in una rete VPC in peering Può trovarsi in un progetto di servizio VPC condiviso
Gateway hop successivo (next-hop-gateway)
Istanza hop successivo per nome (next-hop-instance)
Istanza hop successivo per indirizzo (next-hop-address)
Bilanciatore del carico di rete passthrough interno di hop successivo in base al nome regola di forwarding e alla regione (next-hop-ilb)
Bilanciatore del carico di rete passthrough interno per hop successivo in base all'indirizzo (next-hop-ilb)
Tunnel VPN classica hop successivo (next-hop-vpn-tunnel)

Considerazioni comuni per gli hop successivi dell'istanza e del bilanciatore del carico di rete passthrough interno

Il routing basato su istanze si riferisce a una route statica con un hop successivo che è un'istanza VM (next-hop-instance o next-hop-address).

Per Bilanciatore del carico di rete passthrough interno come hop successivo si intende una route statica con un hop successivo che è un bilanciatore del carico di rete passthrough interno (next-hop-ilb).

Quando configuri il routing basato su istanze o un bilanciatore del carico di rete passthrough interno come hop successivo, tieni presente le seguenti linee guida:

  • Devi configurare le VM di backend o l'istanza di hop successivo per inoltrare i pacchetti da qualsiasi indirizzo IP di origine. Per configurare il forwarding, abilita l'IP forwarding (can-ip-forward) su base VM quando crei la VM. Per le VM create automaticamente come parte di un gruppo di istanze gestite, abilita il forwarding IP nel modello di istanza utilizzato dal gruppo di istanze. Devi apportare questa modifica alla configurazione in aggiunta a qualsiasi configurazione del sistema operativo necessaria per instradare i pacchetti.

  • Il software in esecuzione sulla VM di backend o sull'istanza di hop successivo deve essere configurato in modo appropriato. Ad esempio, le VM di appliance di terze parti che fungono da router o firewall devono essere configurate in base alle istruzioni del produttore.

  • Le VM di backend o l'istanza di hop successivo devono avere regole firewall appropriate. Devi configurare le regole firewall da applicare ai pacchetti instradati. Tieni presente che:

    • Le regole firewall in entrata applicabili alle istanze che eseguono funzioni di routing devono includere gli indirizzi IP delle sorgenti dei pacchetti di routing. La regola di immissione di rifiuto implicita blocca tutti i pacchetti in entrata, pertanto devi almeno creare regole firewall di immissione consentite personalizzate.
    • Le regole firewall in uscita applicabili alle istanze che eseguono funzioni di routing devono includere gli indirizzi IP delle destinazioni dei pacchetti di routing. La regola di traffico in uscita consentita implicita lo consente, a meno che non sia stata creata una regola di divieto di traffico in uscita specifica per sostituirla.
    • Tieni conto se la VM di backend o l'istanza Next Hop esegue la Network Address Translation (NAT) quando crei le regole del firewall.

    Per ulteriori informazioni, consulta Regole firewall implicite.

  • La regione di origine di un pacchetto inviato da una VM di backend o da un'istanza di hop successivo è la regione in cui si trova la VM di backend o l'istanza di hop successivo. Ad esempio, i pacchetti elaborati dalle VM di backend o dalle istanze di hop successivo in us-west1 possono essere inviati a destinazioni accessibili solo in us-west1, anche se la VM di backend o l'istanza di hop successivo ha ricevuto originariamente il pacchetto da una risorsa in una regione diversa da us-west1. Ecco alcuni esempi di risorse accessibili solo nella stessa regione di una VM che invia un pacchetto:

    • Bilanciatori del carico di rete passthrough interni, bilanciatori del carico delle applicazioni interni e bilanciatori del carico di rete proxy interni regionali con accesso globale disattivato
    • Tunnel Cloud VPN, collegamenti VLAN Cloud Interconnect e VM dell'appliance router di connettività di rete se la rete VPC utilizza il routing dinamico a livello di area geografica

Considerazioni per le istanze hop successivo

  • Hop successivo per nome e zona dell'istanza (next-hop-instance): quando crei una route statica con un'istanza hop successivo specificata per nome e zona dell'istanza, Google Cloud richiede che un'istanza con quel nome esista nella zona specificata e soddisfi i seguenti requisiti:

    • L'istanza si trova nello stesso progetto del percorso.
    • L'istanza ha un'interfaccia di rete (NIC) nella rete VPC della route (non una rete VPC in peering).

    Finché la route statica esiste, si applica quanto segue:

    • Google Cloud aggiorna automaticamente la programmazione per l'hop successivo in uno dei seguenti casi:

      • L'indirizzo IPv4 interno principale dell'istanza dell'hop successivo cambia oppure
      • Sostituisci l'istanza dell'hop successivo e l'istanza di sostituzione ha lo stesso nome, si trova nella stessa zona e nello stesso progetto e ha un'interfaccia di rete nella rete VPC della route.

    • Google Cloud non aggiorna la programmazione per l'hop successivo nei seguenti casi:

      • Quando l'istanza viene eliminata.
      • L'intervallo di indirizzi IPv6 assegnato alla NIC dell'istanza cambia.
      • Quando l'indirizzo IPv4 o IPv6 dell'istanza non è assegnato.

  • Indirizzo IP dell'istanza hop successivo (next-hop-address): gli indirizzi IP VM hop successivo validi sono i seguenti:

    • L'indirizzo IPv4 interno principale di un'interfaccia di rete della VM.
    • Qualsiasi indirizzo IPv6 interno o esterno nell'intervallo di indirizzi IPv6 /96 assegnato a un'interfaccia di rete VM.

    Quando crei una route statica con un'istanza di hop successivo specificata da un indirizzo IP, Google Cloud accetta qualsiasi indirizzo IP assegnato alla VM che rientri nell'intervallo di una subnet nella stessa rete VPC della route. Tuttavia, Google Cloud programma la route solo se l'indirizzo dell'hop successivo è un indirizzo IP della VM hop successivo valido. Ad esempio, se crei una route e specifichi l'hop successivo come indirizzo IP proveniente da un intervallo IP di alias, la route viene creata. Tuttavia, poiché gli indirizzi IP degli alias non sono indirizzi IP validi delle VM dell'hop successivo, la route non è programmata.

    Google Cloud aggiorna automaticamente la programmazione per l'hop successivo se l'indirizzo IP dell'hop successivo viene spostato in un'altra VM e se l'indirizzo IP rimane un indirizzo IP VM dell'hop successivo valido.

    Quando specifichi un'istanza di hop successivo in base all'indirizzo IP, i pacchetti vengono instradati all'interfaccia di rete dell'istanza, non all'indirizzo IP specifico.

  • Istanze di hop successivo nei progetti di servizio VPC condiviso: quando specifichi una VM di hop successivo in base all'indirizzo IP, la VM può trovarsi o nello stesso progetto della route (un progetto autonomo o un progetto host VPC condiviso) o in un progetto di servizio VPC condiviso. Quando specifichi una VM di hop successivo in base al nome e alla zona dell'istanza, la VM di hop successivo deve trovarsi nello stesso progetto della route e della rete VPC (un progetto autonomo o un progetto host con VPC condiviso).

  • Costi e latenza da una regione all'altra: quando utilizzi una VM come hop successivo, questo si trova in una zona di una regione. La route che utilizza l'hop successivo è disponibile per tutte le istanze nella stessa rete VPC o per selezionare le istanze con un tag di rete corrispondente. Google Cloud non prende in considerazione la distanza regionale per le route che utilizzano un'istanza come hop successivo, pertanto è possibile creare una route che invii il traffico a una VM hop successivo in un'altra regione. L'invio di pacchetti da una regione all'altra aggiunge costi di trasferimento di dati in uscita e introduce latenza di rete.

  • Nessun controllo di integrità, nessuna convalida della configurazione: Google Cloud non controlla mai se un'istanza di hop successivo soddisfa tutti i requisiti descritti nella sezione Considerazioni comuni per le istanze e gli hop successivi del bilanciatore del carico di rete passthrough interno. La disattivazione dell'interfaccia di rete della VM tramite la configurazione del sistema operativo guest dell'istanza non fa sì che Google Cloud ignori l'istanza dell'hop successivo.

  • Nessun hashing simmetrico quando si connettono due reti VPC: Google Cloud non offre l'hashing simmetrico quando si utilizzano due o più VM di hop successivo con più interfacce di rete in una configurazione che soddisfa tutti i seguenti criteri:

    • Le VM hanno un'interfaccia di rete in una rete VPC e un'altra interfaccia in una seconda rete VPC.
    • In ogni rete VPC esiste un insieme di almeno due route statiche personalizzate per la stessa destinazione, che utilizzano la stessa priorità, dove ogni route nell'insieme fa riferimento a una VM hop successivo univoca.

    Se utilizzi due o più VM con più interfacce per connettere reti VPC e richiedi che la stessa VM elabori i pacchetti per una determinata connessione in entrambe le direzioni, hai bisogno di hashing simmetrico, che è supportato solo dai bilanciatori del carico di rete passthrough interni di hop successivo. Per ulteriori informazioni, consulta la sezione Hashing simmetrico.

  • Comportamento quando le istanze vengono interrotte o eliminate: Google Cloud non impedisce di interrompere o eliminare una VM hop successivo della route statica (specificata tramite nome e zona o indirizzo interno). Quando una VM dell'hop successivo non è in esecuzione, il routing dipende dall'esistenza di altre route per la stessa destinazione e dall'eventuale esecuzione degli hop successivi di queste altre route. Per illustrare questo comportamento, prendi in considerazione i seguenti esempi:

    • Sono disponibili le seguenti route e stati VM:

      • route-a, destinazione 192.168.168.0/24, priorità 10, VM vm-a di hop successivo interrotta
      • route-b, destinazione 192.168.168.0/24, priorità 20, VM vm-b di hop successivo in esecuzione
      • route-c, destinazione 192.168.168.0/24, priorità 30, VM vm-c di hop successivo in esecuzione

      In questo esempio, i pacchetti le cui destinazioni rientrano in 192.168.168.0/24 vengono inviati all'hop successivo vm-b perché l'hop successivo vm-a della priorità più alta route-a non è in esecuzione. Questo accade perché il passaggio "Ignora route statiche e dinamiche con hop successivi inutilizzabili" precede il passaggio "Ignora route a bassa priorità" nell'ordine di routing di Google Cloud.

    • Sono disponibili le seguenti route e stati VM:

      • route-x, destinazione 192.168.168.0/24, priorità 10, VM vm-x di hop successivo interrotta
      • route-y, destinazione 192.168.168.0/24, priorità 20, VM vm-y di hop successivo interrotta
      • route-z, destinazione 192.168.0.0/16, priorità 0, hop successivo La VM vm-z è in esecuzione

      In questo esempio, i pacchetti le cui destinazioni rientrano in 192.168.168.0/24 vengono ignorati perché le VM hop successivo per le due route 192.168.168.0/24 (route-x e route-y) non sono in esecuzione, anche se esiste una route per la destinazione più ampia 192.168.0.0/16 (route-z) con una VM hop successivo in esecuzione. Questo accade perché il passaggio destinazione più specifica precede il passaggio ignora route statiche e dinamiche con hop successivi inutilizzabili nell'ordine di routing di Google Cloud.

Considerazioni per gli hop successivi del bilanciatore del carico di rete passthrough interno

  • Regole di inoltro supportate. Google Cloud supporta solo le regole di forwarding del bilanciatore del carico di rete passthrough interno per l'hop successivo. Google Cloud non supporta le regole di forwarding di primo hop utilizzate da altri bilanciatori del carico, il forwarding del protocollo o come endpoint Private Service Connect.

  • Metodi di specifica e rete e progetto regola di forwarding Puoi specificare una regola di forwarding al successivo hop utilizzando uno dei tre metodi che seguono. Il metodo di specifica utilizzato determina se la rete della regola di inoltro deve corrispondere alla rete del percorso e in quale progetto può trovarsi la regola di forwarding.

    Scegli uno dei seguenti metodi e assicurati che la versione IP della regola di forwarding corrisponda alla versione IP della route statica che crei:

    • Per nome della regola di forwarding (--next-hop-ilb) e regione (--next-hop-ilb-region): quando specifichi una regola di inoltro del salto successivo per nome e regione, la rete della regola di regola di forwarding deve corrispondere alla rete VPC della route. La regola di forwarding deve trovarsi nello stesso progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host VPC condiviso).

    • Per link regola di forwarding inoltro: il link alla risorsa di una regola di forwarding utilizza il formato/projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, dove PROJECT_ID è l'ID progetto del progetto che contiene la regola di forwarding,REGION è la regione della regola di inoltro eFORWARDING_RULE_NAME è il nome della regola di inoltro. Quando specifichi una regola di forwarding dell'hop successivo tramite il relativo link alla risorsa, la rete della regola di forwarding deve corrispondere alla rete VPC della route. La regola di forwarding può trovarsi in un progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host VPC condiviso) o in un progetto di servizio VPC condiviso.

    • In base all'indirizzo IP di una regola di forwarding inoltro: quando specifichi una regola di inoltro dell'hop successivo in base al relativo indirizzo IPv4 o IPv6 (Anteprima), la rete della regola di inoltro può essere la rete VPC della route o una rete VPC in peering. La regola di forwarding può trovarsi in un progetto che contiene la rete della regola di forwarding (un progetto autonomo o un progetto host VPC condiviso) o in un progetto di servizio VPC condiviso.

  • Effetto dell'accesso globale. Le route statiche personalizzate che utilizzano i hop successivi del bilanciatore del carico di rete passthrough interno sono programmate in tutte le regioni. La possibilità di utilizzare l'hop successivo dipende dall'impostazione di accesso globale del bilanciatore del carico. Con l'accesso globale abilitato, l'hop successivo del bilanciatore del carico è accessibile in tutte le regioni della rete VPC. Con l'accesso globale disattivato, l'hop successivo del bilanciatore del carico è accessibile solo nella stessa regione del bilanciatore del carico. Con l'accesso globale disattivato, i pacchetti inviati da un'altra regione a una route che utilizza un hop successivo del bilanciatore del carico di rete passthrough interno vengono eliminati.

  • Quando tutti i backend sono in stato non integro. Quando tutti i backend di un bilanciatore del carico di rete passthrough interno non superano i controlli di integrità, le route che utilizzano l'hop successivo del bilanciatore del carico rimangono in vigore. I pacchetti elaborati dalla route vengono inviati a uno dei backend del bilanciatore del carico dell'hop successivo in base alla distribuzione del traffico.

  • Le regole di inoltro che utilizzano un indirizzo IP interno comune (--purpose=SHARED_LOADBALANCER_VIP) non sono supportate. I bilanciatori del carico di rete passthrough interni per l'hop successivo e le regole di inoltro dei bilanciatori del carico di rete passthrough interni con un indirizzo IP comune sono funzionalità mutuamente esclusive. Un bilanciatore del carico di rete passthrough interno dell'hop successivo deve utilizzare un indirizzo IP univoco per la regola di forwarding del bilanciatore del carico in modo che venga fatto riferimento in modo inequivocabile a un solo servizio di backend (un bilanciatore del carico). È possibile che le regole di inoltro che utilizzano un indirizzo IP interno comune fanno riferimento a servizi di backend diversi (diversi bilanciatori del carico di rete passthrough interni).

  • Più route con le stesse destinazioni e priorità, ma bilanciatori del carico di rete passthrough interni di hop successivo diversi. Google Cloud non distribuisce mai il traffico tra due o più bilanciatori del carico di rete passthrough interni di hop successivo utilizzando ECMP. Al contrario, Google Cloud seleziona un solo bilanciatore del carico di rete passthrough interno di hop successivo utilizzando un algoritmo interno deterministico. Per evitare questa ambiguità, puoi utilizzare tag di rete univoci per ogni percorso.

    Google Cloud seleziona un singolo hop successivo quando le route statiche con hop successivi del bilanciatore del carico di rete passthrough interno diversi hanno la stessa priorità e destinazione.

  • Più route con le stesse destinazioni, priorità e bilanciatori del carico di rete passthrough interni come hop successivo. Senza un tag di rete, Google Cloud non consente di creare più route statiche con la stessa combinazione di destinazione, priorità e hop successivo del bilanciatore del carico di rete passthrough interno. Con i tag di rete, puoi creare più route statiche con la stessa combinazione di destinazione, priorità e hop successivo del bilanciatore del carico di rete passthrough interno.

Considerazioni per gli hop successivi del tunnel VPN classica

  • Costi e latenza tra regioni: Google Cloud non prende in considerazione la distanza regionale per le route che utilizzano un tunnel VPN classica di hop successivo. L'invio di traffico a un tunnel VPN classica di hop successivo in un'altra regione comporta costi di trasferimento di dati in uscita e introduce latenza di rete. Come best practice, ti consigliamo di utilizzare un tunnel VPN ad alta disponibilità con routing dinamico, in quanto questa configurazione prende in considerazione la distanza regionale.

  • Comportamento quando i tunnel VPN classica non sono in esecuzione: le route statiche personalizzate i cui hop successivi sono tunnel VPN classica non vengono rimosse automaticamente quando i tunnel VPN classica non sono in esecuzione. Per informazioni dettagliate su cosa succede quando i tunnel non sono in esecuzione, consulta Quando i tunnel sono inattivi nella documentazione della VPN classica.

Passaggi successivi

  • Per creare e gestire le route, vedi Utilizzare le route.
  • Per una panoramica generale delle route di Google Cloud, consulta Route.