Route statiche

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

Per una panoramica generale delle route in Trusted 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 consoleTrusted Cloud , gcloud compute routes create o l'API routes.insert.

• Se utilizzi la console Trusted 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 tra route di subnet e route statiche e Interazioni tra route statiche e di subnet del peering di rete VPC. 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, le 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

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

• Rete: ad eccezione di 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 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 sulle 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, attiva 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 applichino 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 hop successivo esegue la Network Address Translation (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 includono:

  • 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 router di connettività di rete 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 di hop successivo specificata per nome istanza e zona, Trusted 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:

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

  • Trusted 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, Trusted 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, Trusted 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.

  Trusted Cloud aggiorna automaticamente la programmazione per l'hop successivo se l'indirizzo IP dell'hop successivo viene spostato su una VM diversa, 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. Trusted 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: Trusted 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 comporta l'ignoramento dell'istanza dell'hop successivo da parte diTrusted Cloud .

• Nessun hashing simmetrico quando si connettono due reti VPC: Trusted 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, utilizzando 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 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 passthrough interni di hop successivo. Per ulteriori informazioni, consulta la sezione Hashing simmetrico.

• Comportamento quando le istanze vengono arrestate o eliminate: Trusted 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 della 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 route-a con priorità più alta 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'Trusted Cloud ordine di routing.

  • Hai le seguenti route e stati della 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'Trusted Cloud ordine di routing.

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

• Regole di forwarding supportate: Trusted Cloud supporta solo le regole di forwarding del bilanciatore del carico di rete passthrough interno dell'hop successivo. Trusted 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 seguenti tre metodi. 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 suo indirizzo IPv4 o IPv6, la rete della regola di forwarding può essere la rete VPC della route o 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 hop successivi del bilanciatore del carico di rete passthrough interno sono 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. Se 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 di quel 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 dell'hop successivo. Trusted Cloud never distribuisce il traffico tra due o più bilanciatori del carico di rete passthrough interni dell'hop successivo utilizzando ECMP.Trusted 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, Trusted 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: Trusted 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 maggiori informazioni, consulta la panoramica delle route statiche.

Passaggi successivi

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