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 creare manualmente route statiche utilizzando la consoleGoogle Cloud , gcloud compute routes create o l'API routes.insert.

• Se utilizzi la console Google Cloud per creare un tunnel VPN classica che non utilizza il routing dinamico, Cloud VPN potrebbe creare automaticamente le route statiche corrispondenti. Per ulteriori informazioni, consulta Reti Cloud VPN e routing dei tunnel.

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

Parametri di route

Le route statiche supportano i seguenti attributi:

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

• Rete. Ogni route deve essere associato a una sola rete VPC.

• Hop successivo. L'hop successivo identifica la risorsa di rete a cui vengono inviati i pacchetti. Tutti i tipi di hop successivo supportano le destinazioni IPv4 e alcuni tipi di hop successivo supportano le destinazioni IPv6. Per ulteriori informazioni, consulta Hop 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 di subnet e route statiche. 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ù alte. La priorità più alta possibile è 0, mentre la più bassa è 65,535.

• Tag di rete. Puoi fare in modo che una route statica venga applicata solo a determinate istanze VM nella rete VPC, identificate da un tag di rete:

  • Una route statica senza un tag di rete si applica a tutte le risorse della rete VPC, incluse tutte le istanze VM, i tunnel Cloud VPN, i collegamenti VLAN Cloud Interconnect, gli appliance router e i proxy Envoy nelle subnet solo proxy.

  • Una route statica con un tag di rete si applica solo alle istanze VM che hanno quel tag di rete. Non si applica ad altre risorse.

  • 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à di route statica per tipo di hop successivo:

Progetto e rete dell'hop successivo

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

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

• Progetto: ad eccezione di 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 hop successivi possono trovarsi in progetti di servizio del VPC condiviso.

Considerazioni comuni agli hop successivi del bilanciatore del carico di rete passthrough interno e delle istanze

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

Bilanciatore del carico di rete passthrough interno come hop successivo si riferisce a 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 l'inoltro, abilita l'inoltro IP (can-ip-forward) per ogni VM quando crei la VM. Per le VM create automaticamente nell'ambito di un gruppo di istanze gestite, abilita l'inoltro 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 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 regole firewall che si applicano 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 origini dei pacchetti instradati. La regola implicita per negare tutto il traffico blocca tutti i pacchetti in entrata, quindi devi almeno creare regole firewall personalizzate per consentire il traffico in entrata.
  • Le regole firewall in uscita applicabili alle istanze che eseguono funzioni di routing devono includere gli indirizzi IP delle destinazioni dei pacchetti instradati. La regola di traffico in uscita implicito lo consente, a meno che tu non abbia creato una regola di traffico in uscita specifica per eseguirne l'override.
  • Tieni conto del fatto che la VM di backend o l'istanza di hop successivo esegue la conversione degli indirizzi di rete (NAT) quando crei le regole firewall.

  Per saperne di più, 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. 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 appliance Network Connectivity Router se la rete VPC utilizza il routing dinamico regionale

Considerazioni per le istanze hop successivo

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

  • L'istanza si trova nello stesso progetto della route.
  • 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 di hop successivo e l'istanza sostitutiva 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 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 in un intervallo di subnet 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 VM hop successivo valido. Ad esempio, se crei una route e specifichi l'hop successivo come indirizzo IP proveniente da un intervallo IP alias, la route viene creata. Tuttavia, poiché gli indirizzi IP alias non sono indirizzi IP VM hop successivo validi, la route non viene programmata.

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

  Quando specifichi un'istanza di hop successivo in base all'indirizzo IP, i pacchetti vengono indirizzati 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 nello stesso progetto della route (un progetto autonomo o un progetto host VPC condiviso) oppure in un progetto di servizio VPC condiviso. Quando specifichi una VM di hop successivo in base al nome dell'istanza e alla zona, la VM di hop successivo deve trovarsi nello stesso progetto della route e della rete VPC (un progetto autonomo o un progetto host VPC condiviso).

• Costi e latenza tra regioni: quando utilizzi una VM come hop successivo, l'hop successivo 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 considera la distanza regionale per le route che utilizzano un'istanza come hop successivo, quindi è possibile creare una route che invia il traffico a una VM di hop successivo in una regione diversa. L'invio di pacchetti da una regione all'altra comporta costi di trasferimento di dati in uscita e introduce latenza di rete.

• Nessun controllo di integrità, nessuna convalida della configurazione: Google Cloud non verifica 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 mediante la configurazione del sistema operativo guest dell'istanza non causa l'ignoramento dell'istanza dell'hop successivo da parte diGoogle Cloud .

• 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à, in cui ogni route dell'insieme fa riferimento a una VM di hop successivo univoca.

  Se utilizzi due o più VM con più interfacce per connettere le reti VPC e richiedi che la stessa VM elabori i pacchetti per una determinata connessione in entrambe le direzioni, devi utilizzare l'hashing simmetrico, che è supportato solo dai bilanciatori del carico di rete pass-through interni di hop successivo. Per saperne di più, consulta la sezione Hashing simmetrico.

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

  • Hai le seguenti route e stati delle VM:

    • route-a, destinazione 192.168.168.0/24, priorità 10, VM hop successivo vm-a è arrestata
    • route-b, destinazione 192.168.168.0/24, priorità 20, VM hop successivo vm-b è in esecuzione
    • route-c, destinazione 192.168.168.0/24, priorità 30, VM hop successivo vm-c è 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. Ciò accade perché il passaggio ignora route statiche e dinamiche con hop successivi inutilizzabili precede il passaggio ignora route a bassa priorità nell'Google Cloud ordine di routing.

  • Hai le seguenti route e stati delle VM:

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

    In questo esempio, i pacchetti le cui destinazioni rientrano in 192.168.168.0/24 vengono eliminati perché le VM di 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 192.168.0.0/16 più ampia (route-z) con una VM di hop successivo in esecuzione. Ciò accade perché il passaggio relativo alla destinazione più specifica precede il passaggio relativo all'ignorare le route statiche e dinamiche con hop successivi inutilizzabili nell'Google Cloud ordine di routing.

Considerazioni sugli hop successivi del bilanciatore del carico di rete passthrough interno

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

• Metodi di specifica e rete e progetto della regola di forwarding. Puoi specificare una regola di forwarding del next hop utilizzando uno dei tre metodi seguenti. Il metodo di specifica che utilizzi determina se la rete della regola di forwarding deve corrispondere alla rete della route e in quale progetto può trovarsi la regola di forwarding.

  Scegli uno dei seguenti metodi e assicurati che la versione IP della regola di forwardingo 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 forwarding del next hop per nome e regione, la rete della 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 alla risorsa della regola di forwarding: 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 forwarding e FORWARDING_RULE_NAME è il nome della regola di forwarding. Quando specifichi una regola di forwarding dell'hop successivo in base al relativo link risorsa, la rete della regola di forwarding deve corrispondere alla rete VPC della route. La regola di forwarding può trovarsi nel 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.

  • Per indirizzo IP di una regola di forwarding: quando specifichi una regola di forwarding di hop successivo in base al relativo indirizzo IPv4 o IPv6, la rete della regola di forwarding può essere sia la rete VPC della route sia una rete VPC in peering. La regola di forwarding può trovarsi nel 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 next hop del bilanciatore del carico di rete passthrough interno vengono programmate in tutte le regioni. L'utilizzabilità dell'hop successivo dipende dall'impostazione 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 disabilitato, 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 sono ancora attive. 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 forwarding che utilizzano un indirizzo IP interno comune (--purpose=SHARED_LOADBALANCER_VIP) non sono supportate. I bilanciatori del carico di rete passthrough interni dell'hop successivo e le regole di forwarding del bilanciatore del carico di rete passthrough interno con un indirizzo IP comune sono funzionalità reciprocamente 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 univoco a un solo servizio di backend (un bilanciatore del carico). È possibile che le regole di forwarding che utilizzano un indirizzo IP interno comune facciano riferimento a servizi di backend diversi (bilanciatori del carico di rete passthrough interni diversi).

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

  

• Più route con le stesse destinazioni, priorità e bilanciatori del carico di rete passthrough interni dell'hop successivo. Senza un tag di rete, Google Cloud non ti 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 sugli hop successivi del tunnel VPN classica

• Costi e latenza da regione a regione: Google Cloud non considera la distanza regionale per le route che utilizzano un tunnel VPN classica con hop successivo. L'invio di traffico a un tunnel VPN classica di hop successivo in un'altra regione aggiunge costi di trasferimento di dati in uscita e introduce latenza di rete. Come best practice, utilizza un tunnel VPN ad alta disponibilità con routing dinamico perché questa configurazione tiene conto della 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 la sezione Quando i tunnel non sono attivi nella documentazione della VPN classica.

Considerazioni per Network Connectivity Center

• Puoi creare route statiche dagli spoke VPC ai bilanciatori del carico di rete passthrough interni accessibili tramite l'hub Network Connectivity Center.
• A queste route statiche di Network Connectivity Center si applicano limitazioni aggiuntive. Per ulteriori informazioni, consulta la panoramica delle route statiche.

Passaggi successivi

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