Panoramica degli endpoint in uscita

Questo documento fornisce una panoramica degli endpoint in uscita di Cloud DNS. Gli endpoint in uscita possono essere collegati a zone di forwarding o policy dei server per abilitare il forwarding diretto delle query DNS dalle reti VPC ai resolver DNS esterni e on-premise utilizzando indirizzi IP privati. L'utilizzo di endpoint in uscita fornisce un controllo granulare sul traffico DNS in uscita e migliora la tua capacità di sbloccare i casi d'uso della risoluzione DNS ibrida e multi-cloud.

Per scoprire come creare, aggiornare e associare endpoint in uscita a zone di forwarding o policy dei server, consulta Crea e aggiorna endpoint in uscita.

Funzionalità degli endpoint in uscita

Gli endpoint in uscita consentono di controllare gli indirizzi IP di origine per il traffico DNS in uscita, abilitando il comportamento specifico della rete VPC assegnando un intervallo in uscita univoco per ogni rete. L'intervallo di traffico in uscita univoco supera le limitazioni di routing dell'intervallo di proxy di forwarding fisso esistente.

I cluster GKE ereditano automaticamente gli endpoint in uscita quando eseguono query su destinazioni esterne con la rete VPC host. Se la rete VPC host è autorizzata per una zona di forwarding Cloud DNS globale standard o una policy dei server configurata con endpoint in uscita, i pod che utilizzano la risoluzione DNS VPC instradano automaticamente le query in uscita tramite endpoint in uscita regionali senza richiedere modifiche a livello di cluster o zone di forwarding di zona.

Per scoprire di più sulla migrazione della configurazione di forwarding DNS esistente agli endpoint in uscita, consulta Esegui la migrazione di una configurazione di forwarding Cloud DNS esistente agli endpoint in uscita.

Architettura degli endpoint in uscita e routing delle query

Un endpoint in uscita viene creato all'interno di una rete VPC specifica (utilizzando una subnet regolare nella regione di destinazione per l'indirizzo IP interno dell'endpoint) e utilizza la subnet solo proxy regionale di quella rete per il proprio indirizzo IP di origine.

Quando colleghi endpoint in uscita alle zone di forwarding o alla policy dei server, Cloud DNS tenta innanzitutto di instradare le query DNS attraverso l'endpoint in uscita con il ranking più alto utilizzando l'algoritmo di ranking dei target esistente. Se l'endpoint non è integro, Cloud DNS prova l'endpoint con il ranking più alto successivo. L'endpoint in uscita geograficamente più vicino è preferito, ma non garantito.

L'algoritmo di ranking per i server di destinazione viene eseguito automaticamente e si basa sul pattern di failover delle zone di forwarding esistenti: selezione dell'IP con latenza e tasso di errore più bassi. I seguenti fattori aumentano il ranking di un target di forwarding:

  • Maggiore numero di risposte DNS riuscite elaborate dal target di forwarding. Le risposte DNS riuscite includono anche le risposte NXDOMAIN.
  • Minore latenza per la comunicazione con il target di forwarding.
  • Distanza geografica più breve dall'endpoint in uscita. Se i dati relativi a esito positivo e latenza non sono disponibili, viene preferita la destinazione più vicina.

Per proteggerti da interruzioni a livello di regione, puoi configurare gli endpoint in uscita in almeno due regioni in cui esegui i workload di computing. Questo approccio fornisce a Cloud DNS un target di failover regionale e mantiene una latenza minima delle query. Se il provisioning della connettività ibrida viene eseguito solo in regioni selezionate, gli endpoint in altre regioni di computing possono comunque eseguire il routing attraverso queste connessioni per raggiungere i resolver on-premise.

Anche se l'endpoint con il ranking più alto si trova in una regione diversa, Cloud DNS continua a instradare le query a quell'endpoint. Ad esempio, se un endpoint nella regione A non è disponibile, il traffico viene indirizzato automaticamente a un endpoint integro nella regione B. Quando l'endpoint nella Regione A torna integro, l'algoritmo di ranking rileva il miglioramento delle prestazioni e inizia a preferirlo di nuovo per le query successive.

Puoi avere fino a 10 endpoint in uscita per progetto per regione e fino a 100 endpoint in uscita collegati a una zona di forwarding o a una policy dei server.

Instrada le query ai resolver on-premise regionali

Cloud DNS non garantisce che il traffico venga inviato all'endpoint nella stessa regione della VM di origine, ma puoi utilizzare le policy di routing di geolocalizzazione per instradare il traffico al server dei nomi di destinazione più vicino. Sebbene Cloud DNS instradi preferibilmente il traffico verso l'endpoint in uscita nella regione più vicina alla query di origine e al server dei nomi di destinazione, la regione del server dei nomi di destinazione e la regione dell'endpoint in uscita non presentano un alto accoppiamento. Indipendentemente dalla località, Cloud DNS sceglie l'endpoint che storicamente ha fornito la latenza più bassa.

Di seguito è riportata una panoramica generale di ciò che devi fare per instradare le query ai resolver on-premise regionali:

  • Crea una zona con una policy di geolocalizzazione: crea una nuova zona privata Cloud DNS per un FQDN che controlli (ad esempio onprem-resolvers.example.com) autorizzato per la tua rete VPC. In questa zona, crea record A per gli IP dei server DNS on-premise e applica una policy di routing di geolocalizzazione. Configura la policy in modo che restituisca gli IP del resolver per le query provenienti da quella regione specifica. Ad esempio, restituisci gli IP dei resolver europei per le query provenienti dalle regioni Google Cloud europee.
  • Utilizza l'FQDN come target di forwarding: nella zona di forwarding, utilizza l'FQDN appena creato (onprem-resolvers.example.com) come server DNS di destinazione.
  • Configura gli endpoint in uscita: associa gli endpoint in uscita regionali (ad esempio, uno in una regione degli Stati Uniti e uno in una regione europea) a questa zona di forwarding.

Quando una VM in una regione esegue una query, il sistema segue un processo di routing in due passaggi:

  • Selezione dell'endpoint: Cloud DNS valuta l'elenco degli endpoint in uscita associati alla zona di forwarding e seleziona l'endpoint migliore (ad esempio, è probabile che venga scelto un endpoint in Europa per una query da una VM in Europa).
  • Risoluzione della destinazione: Cloud DNS risolve l'FQDN di destinazione (onprem-resolvers.example.com) per la regione di origine della query. Cloud DNS inoltra quindi la query originale tramite l'endpoint in uscita selezionato all'IP del server DNS risolto. La policy di geolocalizzazione identifica l'origine della query come quella regione e restituisce l'indirizzo IP specifico che hai configurato per quella regione.

Per saperne di più, consulta il tutorial sul forwarding DNS in uscita FQDN di Cloud DNS.

Forwarding da una regione senza un endpoint locale in una singola rete VPC

Una rete VPC Google Cloud è una risorsa globale che può contenere subnet in più regioni. Se una VM esegue una query da una regione in cui non hai configurato un endpoint in uscita, il forwarding verrà comunque eseguito correttamente. La query verrà instradata tra le regioni all'endpoint in uscita disponibile con il ranking più alto che esiste all'interno della stessa rete VPC ed è configurato nella zona di forwarding o nella policy dei server.

Forwarding da più reti VPC nella stessa regione con isolamento dell'IP di origine

Se devi inoltrare query da più reti VPC nella stessa regione e hai bisogno che il resolver on-premise veda un indirizzo IP di origine distinto per ogni rete VPC, segui questi passaggi:

  1. Crea un endpoint in uscita in ogni rete VPC: per saperne di più, consulta Crea un endpoint in uscita.
  2. Crea una zona di forwarding o una policy dei server in ogni rete VPC: autorizza la zona di forwarding o la policy dei server solo per quella rete VPC e utilizza solo l'endpoint in uscita di quella rete VPC.

Questa azione fa sì che le VM in ogni rete VPC inviino query tramite l'endpoint in uscita nella propria rete VPC. Ogni endpoint inoltra la query al resolver on-premise. La rete on-premise vede l'indirizzo IP di origine della subnet solo proxy di ogni rete VPC, il che consente di applicare configurazioni diverse per il traffico di ogni rete.

Forwarding unificato tra diverse reti VPC (hub and spoke)

Puoi configurare una zona di forwarding o una policy dei server in modo che utilizzi un endpoint in uscita in una rete VPC centralizzata diversa (l'hub). La connettività di rete non è necessaria tra la rete hub e la rete VPC da cui proviene la query (lo spoke), poiché Cloud DNS gestisce l'inoltro delle query internamente.

Devi configurare la connettività di rete tra l'endpoint in uscita e i target di forwarding nella zona di forwarding o nella policy dei server. La connettività può essere stabilita utilizzando Cloud Interconnect o Cloud VPN per raggiungere i resolver on-premise. Il peering di rete VPC può essere utilizzato per raggiungere i target di forwarding in un'altra rete VPC.

  1. Crea un endpoint in uscita nella rete VPC hub.
  2. Crea una zona di forwarding o una policy dei server nella rete VPC spoke e configurala in modo che utilizzi l'endpoint in uscita della rete hub.

Le VM nelle reti VPC spoke inviano query tramite l'endpoint in uscita nella rete VPC hub. L'endpoint inoltra la query al resolver on-premise.

Supporto per il VPC condiviso

Gli endpoint in uscita supportano i deployment VPC condiviso. L'endpoint, la relativa subnet normale e la subnet solo proxy associata vengono creati centralmente nel progetto host. I progetti di servizio possono ereditare le zone di forwarding o le policy dei server create nel progetto host oppure creare le proprie zone di forwarding private o policy dei server e associarle tra progetti all'endpoint in uscita centralizzato nel progetto host (richiede dns.outboundEndpoints.bindPrivateDNSZone o dns.outboundEndpoints.bindPrivateDNSPolicy nel progetto host).

Gestisci le risorse di rete associate agli endpoint in uscita

Gli endpoint in uscita di Cloud DNS applicano rigide dipendenze del ciclo di vita con le reti VPC e le subnet sottostanti per proteggere il traffico DNS di produzione da modifiche accidentali dell'infrastruttura, come eliminazioni o modifiche.

Elimina la subnet solo proxy o la rete VPC quando è in uso da un endpoint in uscita

Una subnet normale, una subnet solo proxy o una rete VPC utilizzata attivamente da un endpoint in uscita è protetta dall'eliminazione per evitare interruzioni. Il tentativo di eliminare queste risorse genera un errore. Se vuoi eliminare queste risorse, devi seguire questi passaggi nell'ordine esatto:

  1. Aggiorna la configurazione di Cloud DNS: modifica le zone di forwarding o le policy dei server che utilizzano l'endpoint in uscita e rimuovilo dalla configurazione in modo che non sia più in uso.
  2. Elimina l'endpoint in uscita: quando l'endpoint non è più in uso, puoi eliminarlo. Questa azione rilascia la dipendenza dalla subnet normale e dalla subnet solo proxy.
  3. Elimina le subnet: dopo aver verificato che non siano utilizzate da altre risorse, elimina le subnet solo proxy e quelle normali.
  4. Elimina la rete VPC: una volta rimosse tutte le altre dipendenze VPC, puoi eliminare la rete VPC.

Modifica della subnet

Non puoi modificare direttamente una subnet solo proxy quando un endpoint in uscita la utilizza attivamente. Questa limitazione impedisce di modificare le proprietà chiave, come l'intervallo di indirizzi IP, il che contribuisce a evitare interruzioni del servizio. Per modificare la subnet, devi seguire le linee guida esistenti ed eseguire prima la migrazione a una nuova subnet.

Per modificare una subnet utilizzata da un endpoint in uscita, segui questi passaggi:

  1. Crea una subnet di backup: crea una nuova subnet solo proxy nella stessa rete VPC e nella stessa regione. Devi impostare il ruolo di questa subnet su BACKUP durante la creazione.
  2. Attiva la nuova subnet: aggiorna il ruolo della nuova subnet impostandolo su ACTIVE. In questo modo, la subnet originale viene impostata automaticamente sul ruolo BACKUP e inizia lo svuotamento delle connessioni attive.
  3. Attendi lo svuotamento: attendi il completamento del processo di svuotamento della connessione.
  4. Elimina la subnet precedente: ora puoi eliminare la subnet originale una volta che è nel ruolo BACKUP e non ha connessioni attive.

Prevedibilità dell'IP di origine dedicato per i firewall on-premise

Se i firewall DNS on-premise richiedono un intervallo di indirizzi IP di origine dedicato e prevedibile isolato per il traffico DNS, ti consigliamo di applicare la seguente architettura:

  • Esegui il deployment in una rete VPC in uscita dedicata: crea una rete VPC dedicata con una subnet regolare (per l'indirizzo IP dell'endpoint in uscita) e una subnet proxy-only regionale riservata esclusivamente a Cloud DNS (--purpose=REGIONAL_MANAGED_PROXY e --role=ACTIVE).
  • Isola le reti VPC delle applicazioni: non eseguire il peering o il routing delle reti VPC delle applicazioni a questa rete in uscita dedicata. Cloud DNS instrada le query internamente all'infrastruttura Google Cloud, quindi non è necessaria una connessione di rete diretta tra queste reti VPC.
  • Connetti la rete VPC in uscita dedicata ai target di forwarding esterni: configura la connettività solo tra la rete VPC in uscita dedicata e i server dei nomi target esterni o on-premise. Stabilisci questo percorso utilizzando quanto segue:
    • Peering di rete VPC con un VPC di transito esistente: questo è l'approccio consigliato e il più conveniente. Se la tua organizzazione ha già una rete VPC di transito centrale con Cloud Interconnect o Cloud VPN on-premise, esegui il peering della rete VPC DNS dedicata con quell'hub di transito. Questo approccio evita il provisioning di circuiti ibridi ridondanti e riduce al minimo i costi.
    • Connettività ibrida diretta: Dedicated Interconnect, Cross-Cloud Interconnect o Cloud VPN che termina direttamente nella rete VPC DNS dedicata.

Limitazioni

Gli endpoint in uscita presentano le seguenti limitazioni:

  • Condivisione di IP di origine e subnet limitata alle risorse nella stessa regione: gli endpoint in uscita allocano gli intervalli IP di origine dalla subnet solo proxy regionale della rete VPC a cui sono collegati. Nelle implementazioni standard, questa subnet solo proxy può essere condivisa con altre risorse regionali, come i bilanciatori del carico delle applicazioni regionali.

  • Il peering diretto alle subnet solo proxy non è supportato: non puoi eseguire il peering diretto con una subnet solo proxy. La connessione di rete ai server dei nomi esterni deve essere stabilita tramite il routing VPC standard, ad esempio Cloud Interconnect, Cloud VPN o il peering di rete VPC.

  • Solo supporto IPv4: l'indirizzo IP di origine di un endpoint in uscita è solo IPv4 e le query possono essere inoltrate solo a target IPv4 o target di forwarding FQDN su zone di forwarding che vengono risolte in indirizzi IPv4.

  • L'associazione di endpoint in uscita a una rete tra progetti non è supportata: la creazione di un endpoint in uscita in un progetto di servizio collegato alla rete VPC condivisa di un progetto host non è supportata. Gli endpoint in uscita devono trovarsi nello stesso progetto della rete VPC e della subnet a cui sono collegati.

  • Limitato ai target privati: gli endpoint in uscita supportano solo il forwarding ai target privati (inclusi RFC 1918, RFC 6598 e indirizzi non RFC 1918 con routing privato configurati con --private-forward-targets o forwardingPath: "private") e non possono essere utilizzati come proxy in uscita o anchor IP di origine statico per il traffico DNS di internet pubblico. Le query alle destinazioni internet pubbliche vengono risolte direttamente tramite l'edge anycast distribuito di Google per ridurre al minimo la latenza ed evitare dipendenze da Cloud NAT.

  • Ambito regionale: gli endpoint in uscita sono risorse a livello di regione. Devi creare endpoint in ogni regione in cui intendi utilizzarli.

  • Solo un meccanismo di forwarding: il meccanismo di forwarding (l'intervallo 35.199.192.0/19 predefinito o gli endpoint in uscita) è configurato a livello di zona di forwarding o di policy del server. Tuttavia, non puoi utilizzare entrambi i metodi contemporaneamente per la stessa zona o policy.

Passaggi successivi