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 dei percorsi.

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 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 successivo supportano le destinazioni IPv4 e alcuni di questi 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 più ampia la possibile destinazione per una route statica IPv4 è 0.0.0.0/0. La più ampia la possibile destinazione 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 fare in modo che una route statica venga applicata solo a una VM selezionata di istanze gestite nella rete VPC, identificate da una 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 dell'hop successivo (next-hop-gateway)
Specifica un valore gateway internet predefinito per definire un percorso agli indirizzi IP esterni.
Istanza dell'hop successivo per nome e zona (next-hop-instance)
Invia pacchetti a una VM dell'hop successivo identificata dal nome e dalla zona e che si trova nella stessa progetto come route. Per ulteriori informazioni, vedi Considerazioni sulle istanze dell'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 per ulteriori informazioni, consulta Considerazioni sulle hop successivi del bilanciatore del carico di rete passthrough interno.
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 i pacchetti a un tunnel VPN classica dell'hop successivo utilizzando basato su norme il routing o una 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ù le route statiche 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: ad eccezione di quanto indicato nella tabella seguente, l'hop successivo La rete VPC 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). Ancora qualche possono trovarsi nei progetti di servizio del VPC condiviso.

Tipo di hop successivo Può trovarsi in una rete VPC in peering Può trovarsi in un progetto di servizio del VPC condiviso
Gateway dell'hop successivo (next-hop-gateway)
Istanza dell'hop successivo per nome (next-hop-instance)
Istanza dell'hop successivo in base all'indirizzo (next-hop-address)
Hop successivo del bilanciatore del carico di rete passthrough interno mediante il nome e la regione della regola di forwarding (next-hop-ilb)
Bilanciatore del carico di rete passthrough interno con 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).

Il bilanciatore del carico di rete passthrough interno come hop successivo si riferisce a una route statica con un hop successivo 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 in considerazione 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 l'inoltro, attiva IP di inoltro (can-ip-forward) su una per VM quando crei la VM. Per le VM create automaticamente nell'ambito di un gruppo di istanze gestite, abilita l'IP forwarding nel modello di istanza utilizzata 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 secondo le istruzioni.

  • Le VM di backend o l'istanza dell'hop successivo devono disporre di un firewall appropriato . Devi configurare le regole firewall che si applicano ai pacchetti che vengono vengono indirizzate correttamente. 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.
    • Regole firewall in uscita applicabili alle istanze che eseguono il routing devono includere gli indirizzi IP delle destinazioni dei pacchetti instradati. La regola implicita di autorizzazione in uscita lo consente, a meno che tu non abbia creato una specifica e la regola di negazione in uscita per eseguirne l'override.
    • Considera se la VM di backend o l'istanza dell'hop successivo Eseguire Network Address Translation (NAT) durante la creazione del firewall le regole del caso.

    Per ulteriori informazioni, consulta Firewall implicito. .

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

    • 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, VLAN Cloud Interconnect e VM dell'appliance router di connettività di rete la rete VPC utilizza il routing dinamico a livello di regione

Considerazioni sulle istanze dell'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 della route.
    • L'istanza ha un'interfaccia di rete (NIC) nella route Rete VPC (non rete VPC in peering).

    Finché esiste la route statica, 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 nel i seguenti casi:

      • Quando l'istanza viene eliminata.
      • L'intervallo di indirizzi IPv6 assegnato alle modifiche al NIC dell'istanza.
      • Quando l'assegnazione dell'indirizzo IPv4 o IPv6 dell'istanza è stata annullata.

  • Indirizzo IP dell'istanza dell'hop successivo (next-hop-address): gli indirizzi IP della VM dell'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 e assegnato a un'interfaccia di rete VM.

    Quando crei una route statica con un'istanza dell'hop successivo specificata da un IP, , Google Cloud accetta qualsiasi indirizzo IP assegnato da una VM all'interno di un intervallo di subnet di una subnet nella stessa rete VPC di lungo il percorso. Tuttavia, Google Cloud programma la route solo se la route l'indirizzo dell'hop è un indirizzo IP della VM hop successivo valido. Ad esempio, se crei una route e specifica l'hop successivo come indirizzo IP proveniente da un alias nell'intervallo IP, viene creata la route. 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.

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

  • 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 e selezionare 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 in uscita i costi di trasferimento dei dati e introduce la latenza di rete.

  • Nessun controllo di integrità, nessuna convalida della configurazione: Google Cloud non verifica mai se un'istanza dell'hop successivo soddisfa tutti i requisiti descritti in le considerazioni comuni all'istanza e al bilanciatore del carico di rete passthrough interno hop. Disabilita l'interfaccia di rete della VM tramite la configurazione del sistema operativo guest dell'istanza non causa di ignorare l'istanza dell'hop successivo.

  • Nessun hashing simmetrico durante il collegamento di due reti VPC: Google Cloud non offre l'hashing simmetrico se ne vengono utilizzati due o più VM dell'hop successivo con più interfacce di rete in una configurazione 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 nel set fa riferimento a una VM univoca dell'hop successivo.

    Se utilizzi due o più VM con più interfacce per connetterti reti VPC e hai bisogno che le stesse VM elaborino di pacchetti per una determinata connessione in entrambe le direzioni, è necessaria una simmetria , che è supportato solo dai bilanciatori del carico di rete passthrough interni con l'hop successivo. Per maggiori informazioni di archiviazione, consulta la sezione Simmetrico di hashing.

  • Comportamento quando istanze vengono arrestate o eliminate: Google Cloud non impedisce all'arresto o all'eliminazione di una VM dell'hop successivo della route statica (specificata da nome e zona o indirizzo interno). Quando una VM dell'hop successivo non viene in esecuzione, il routing per la destinazione dipende dalla presenza o meno di altre route per la stessa destinazione esiste e se questi altri percorsi hanno hop in esecuzione. Per illustrare questo comportamento, considera quanto segue: esempi:

    • I pacchetti le cui destinazioni rientrano in 192.168.168.0/24 vengono inviati al hop successivo di route-vm-b nella seguente situazione in cui l'hop successivo per la route con priorità massima non è in esecuzione. Questa procedura si verifica perché Google Cloud ignora gli hop successivi che non sono in esecuzione prima di considerare il passaggio Ignora le route a bassa priorità della ordine di routing:
    • route-vm-a, destinazione 192.168.168.0/24, priorità 10, VM hop successivo viene interrotto
    • route-vm-b, destinazione 192.168.168.0/24, priorità 20, VM hop successivo è in esecuzione

    • route-vm-c, destinazione 192.168.168.0/24, priorità 30, VM hop successivo è in esecuzione

    • I pacchetti le cui destinazioni rientrano in 192.168.168.0/24 vengono eliminati in questo esempio successivo in cui tutte le VM dell'hop successivo per le route 192.168.168.0/24 vengono non è attiva, anche se un percorso per il 192.168.0.0/16 più ampio ha una della VM dell'hop successivo in esecuzione. I pacchetti vengono eliminati Google Cloud ignora le route con subnet più ampie (subnet mask più breve) length) nel passaggio destinazione più specifica, che avviene prima di ignorare le route statiche personalizzate i cui hop successivi non sono in esecuzione dell'ordine di routing):

    • route-vm-x, destinazione 192.168.168.0/24, priorità 10, VM hop successivo viene interrotto

    • route-vm-y, destinazione 192.168.168.0/24, priorità 20, VM hop successivo viene interrotto

    • route-vm-z, destinazione 192.168.0.0/16, priorità 0, VM dell'hop successivo corrente corsa

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

  • Regole di forwarding supportate. Google Cloud supporta solo l'hop successivo le regole di forwarding del bilanciatore del carico di rete passthrough interno. 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 specifica una regola di forwarding per l'hop successivo utilizzando uno dei tre metodi seguenti. Il metodo di specifica utilizzato determina se l'inoltro della regola deve corrispondere alla rete della route e in quale progetto La regola di forwarding può trovarsi:

    • 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 sia 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.

    • Tramite un indirizzo IPv4 di una regola di forwarding: quando specifichi un hop successivo dalla regola di forwarding tramite il relativo indirizzo IPv4, la rete può essere la rete VPC della route oppure 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. Indica se l'hop successivo è utilizzabile dipende dalla dimensione globale del bilanciatore del carico di accesso. Con impostazioni globali abilitato, l'hop successivo del bilanciatore del carico è accessibile in tutte le regioni la rete VPC. Se l'accesso globale è disattivato, il carico l'hop successivo del bilanciatore è accessibile solo nella stessa regione del carico con il bilanciatore del carico di rete passthrough esterno regionale. 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 il bilanciatore del carico di rete passthrough interno non supera i controlli di integrità, le route che utilizzano quel bilanciatore del carico hop successivo sono ancora attivi. 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. Hop successivo bilanciatori del carico di rete passthrough interni e regole di forwarding del bilanciatore del carico di rete passthrough interno con un IP comune indirizzo si escludono a vicenda. Un 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ù percorsi con le stesse destinazioni e priorità, ma diverse bilanciatori del carico di rete passthrough interni con l'hop successivo. 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 un un algoritmo interno deterministico. Per evitare questa ambiguità, puoi utilizzare tag di rete univoci per ogni route.

    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 destinazioni, priorità e hop successivo uguali bilanciatori del carico di rete passthrough interni. 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, creare più route statiche con la stessa combinazione di destinazione, della priorità e hop successivo del bilanciatore del carico di rete passthrough interno.

Considerazioni sugli hop successivi nei tunnel VPN classica

  • Costi e latenza tra regione: Google Cloud non considera distanza regionale per le route che usano una VPN classica dell'hop successivo tunnel. Invio del traffico a un tunnel VPN classica dell'hop successivo in un'altra regione aggiunge costi di trasferimento di dati in uscita e introduce una latenza di pochi millisecondi. Come best practice, usa una VPN ad alta disponibilità tunnel con dinamico calcolo itinerario poiché la configurazione considera la distanza a livello di regione.

  • 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