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 Panoramica delle route.

Considerazioni sulla creazione di route statiche

Puoi creare route statiche in due modi:

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

Parametri di route

Le route statiche supportano i seguenti attributi:

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

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

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

  • Intervallo di destinazione. L'intervallo di destinazione è un singolo CIDR IPv4 o IPv6 notazione.

    Le destinazioni delle route statiche devono seguire le regole descritte in Interazioni con route statiche e Subnet e una route statica interazioni. 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à. Numeri più bassi indicano priorità più alte. Il più alto la priorità possibile è 0, mentre 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 nel in ogni rete. Le route statiche con tag non vengono mai scambiate quando si utilizza Peering di rete VPC.

Hop e funzionalità successivi

La tabella seguente riassume il supporto delle funzionalità di 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 che si trova nello stesso progetto della route. Per ulteriori informazioni, consulta Considerazioni per le istanze di hop successivo.
Istanza hop successivo in base all'indirizzo (next-hop-address)
Invia di pacchetti a una VM dell'hop successivo identificata dal provider o un indirizzo IPv6 interno o esterno, della sua interfaccia di rete. Per Per ulteriori informazioni, consulta Considerazioni sull'hop successivo di Compute Engine.		 (anteprima)
Hop successivo del bilanciatore del carico di rete passthrough interno mediante il nome della regola di forwarding (next-hop-ilb) e regione (next-hop-ilb-region)
Invia pacchetti ai backend di un bilanciatore del carico di rete passthrough interno identificato dall'amministratore nome, regione e, facoltativamente, progetto della regola di forwarding. Per maggiori informazioni, consulta Considerazioni per gli hop successivi dei bilanciatori del carico di rete passthrough interni.
Bilanciatore del carico di rete passthrough interno con hop successivo in base all'indirizzo (next-hop-ilb)
Invia pacchetti ai backend di un bilanciatore del carico di rete passthrough interno identificato dall'IP dell'indirizzo IP della regola di forwarding del bilanciatore del carico. Per ulteriori informazioni, vedi Considerazioni sugli hop successivi del bilanciatore del carico di rete passthrough interno.
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, vedi Passaggi successivi per il tunnel VPN classica hop.
1ECMP (Equal-cost multipath) indica che due o più route statici possono condividere lo stesso intervallo di destinazione e la stessa priorità. Anche se può creare due o più route statiche in una rete VPC con lo stesso la stessa priorità e l'hop successivo del gateway internet predefinito, equivale ad avere una singola route statica che utilizza la rete internet predefinita dell'hop successivo del gateway per quella destinazione e priorità.

Progetto hop successivo e rete

Un hop successivo della route statica è associato sia a una rete VPC di 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: ad eccezione di quanto indicato nella tabella seguente, l'hop successivo deve trovarsi nel progetto che contiene il VPC dell'hop successivo (un progetto autonomo o un progetto host del VPC condiviso). Alcuni passaggi successivi possono trovarsi in progetti di servizio VPC condivisi.

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 per hop successivo in base al nome della regola di inoltro 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 dell'hop successivo (next-hop-vpn-tunnel)

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

Il routing basato su istanza si riferisce a una route statica con un hop successivo che è una 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 dell'hop successivo per l'inoltro 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. Questa modifica alla configurazione deve essere apportata in oltre a qualsiasi configurazione del sistema operativo necessaria per l'instradamento dei pacchetti.

  • Il software in esecuzione sulla VM di backend o sull'istanza dell'hop successivo deve essere configurate correttamente. Ad esempio, VM di appliance di terze parti che agiscono i router o i firewall devono essere configurati in base alle istruzioni.

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

    • Regole firewall in entrata applicabili alle istanze che eseguono il routing devono includere gli indirizzi IP delle origini dei pacchetti instradati. La una regola implicita di negazione del traffico in entrata blocca tutti i pacchetti in entrata, quindi devi e creare regole firewall di autorizzazione in entrata 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 Firewall implicito. .

  • 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 VPN Cloud, 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 istanza e zona (next-hop-instance): quando crea una route statica con un'istanza dell'hop successivo specificata dall'istanza nome e zona, Google Cloud richiede che un'istanza con quel nome esiste nella zona specificata e soddisfa quanto segue:

    • 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 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 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 rientra 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 alias non vengono indirizzi IP della VM dell'hop successivo validi, la route non è programmata.

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

    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 condivisa).

  • Costi e latenza tra regione: quando utilizzi una VM come hop successivo, 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, è possibile creare una route che invia traffico a una VM dell'hop successivo regione diversa. 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 a 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 in cui ogni route del set fa riferimento a una VM univoca dell'hop successivo.

    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, devi utilizzare l'hashing simmetrico, 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:

    • Hai le route e gli stati delle VM seguenti:

      • 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, successiva la VM hop 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 route-a con priorità più elevata non è in esecuzione. Questo accade perché non tenere conto delle route statiche e dinamiche e hops, precede ignorare la priorità bassa del percorso di apprendimento nel nell'ordine di routing di Google Cloud.

    • Hai le route e gli stati delle VM seguenti:

      • route-x, destinazione 192.168.168.0/24, priorità 10, successiva la VM hop vm-x è arrestata
      • 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 eliminati perché le VM dell'hop successivo per i due 192.168.168.0/24 (route-x e route-y) non sono in esecuzione, anche se si tratta per la destinazione più ampia 192.168.0.0/16 esiste (route-z) con un in esecuzione su una VM con hop successivo. 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 regole di forwarding dell'hop utilizzate da altri bilanciatori del carico, forwarding del protocollo come endpoint Private Service Connect.

  • Metodi di specifica e rete e progetto della regola di forwarding. Puoi specificare una regola di inoltro 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 inoltro:

    • Tramite il nome della regola di forwarding (--next-hop-ilb) e la regione (--next-hop-ilb-region): quando specifichi l'inoltro dell'hop successivo regola 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 (un progetto autonomo o un progetto host del VPC condiviso).

    • Tramite il link alle risorse della regola di forwarding: la risorsa della regola di forwarding utilizza il formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, dove PROJECT_ID è il l'ID 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 per l'hop successivo tramite il relativo link della risorsa, la rete della regola di forwarding deve corrispondere al VPC della route in ogni rete. La regola di forwarding può trovarsi uno nel progetto che che contiene la rete della regola di forwarding (un progetto autonomo o progetto host del VPC condiviso) o di un servizio VPC condiviso progetto.

    • In base all'indirizzo IPv4 di una regola di inoltro: quando specifichi una regola di inoltro dell'hop successivo in base al relativo indirizzo IPv4, la rete della regola di inoltro può essere la rete VPC della route o una rete VPC in peering. È possibile trovare la regola di forwarding nel progetto che contiene la rete della regola di forwarding o (un progetto autonomo o un progetto host del VPC condiviso) oppure una Progetto di servizio VPC condiviso.

  • Effetto dell'accesso globale. Route statiche personalizzate utilizzando il bilanciatore del carico di rete passthrough interno gli hop successivi sono programmati 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. Se l'accesso globale è disabilitato, i pacchetti inviati da un'altra regione che utilizza un hop successivo del bilanciatore del carico di rete passthrough interno.

  • 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 rotta vengono inviati a uno dei backend del bilanciatore del carico dell'hop successivo in base al traffico la distribuzione dei contenuti.

  • Regole di forwarding che utilizzano un indirizzo IP interno comune (--purpose=SHARED_LOADBALANCER_VIP) non sono supportati. 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. Il bilanciatore del carico di rete passthrough interno dell'hop successivo deve utilizzare un bilanciatore univoco per la regola di forwarding del bilanciatore del carico, in modo che viene fatto riferimento in modo inequivocabile a un solo servizio di backend (un bilanciatore del carico). È possibile che le regole di forwarding utilizzino un indirizzo IP interno comune fare riferimento a servizi di backend diversi (bilanciatori del carico di rete passthrough interni diversi).

  • 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 per l'hop successivo utilizzando ECMP. Invece, Google Cloud seleziona solo un bilanciatore del carico di rete passthrough interno dell'hop successivo utilizzando una 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 diversi hop successivi del bilanciatore del carico di rete passthrough interno hanno lo stesso 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 consentono di creare più route statiche che hanno la stessa combinazione destinazione, priorità e 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 da una regione all'altra: 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 classico di hop successivo in un'altra regione comporta costi di trasferimento dati in uscita e introduce latenza di rete. Come best practice, utilizza 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: Personalizzato le route statiche i cui hop successivi sono tunnel VPN classica non automaticamente quando i tunnel della VPN classica non vengono in esecuzione. Per maggiori dettagli su cosa succede quando i tunnel non sono in esecuzione, consulta Quando i tunnel vengono abbassa nella documentazione della VPN classica.

Passaggi successivi