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 degli endpoint in uscita fornisce un controllo granulare sul traffico DNS in uscita e migliora la tua capacità di sbloccare i casi d'uso di risoluzione DNS ibrida e multicloud.

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

Funzionalità degli endpoint in uscita

Gli endpoint in uscita ti consentono di controllare gli indirizzi IP di origine per il traffico DNS in uscita, abilitando un comportamento specifico della rete VPC assegnando un intervallo di traffico 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 o una policy dei server Cloud DNS globale standard configurata con endpoint in uscita, i pod che utilizzano la risoluzione DNS VPC instradano automaticamente le query in uscita tramite gli 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 Eseguire 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 e utilizza la subnet solo proxy della rete per il relativo indirizzo IP di origine.

Quando colleghi gli endpoint in uscita alle zone di forwarding o alla policy dei server, Cloud DNS tenta innanzitutto di instradare le query DNS tramite 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 è preferibile, 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 esistente - selezione dell'IP con la latenza e la frequenza di errori più basse. 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.
  • Latenza inferiore per la comunicazione con il target di forwarding.
  • Distanza geografica più breve dall'endpoint in uscita. Se i dati di successo e latenza non sono disponibili, viene preferito il target più vicino.

Per la protezione da interruzioni regionali, puoi configurare gli endpoint in uscita in almeno due regioni in cui esegui i carichi di lavoro di Compute. Questo approccio fornisce a Cloud DNS un target di failover regionale e mantiene una latenza di query minima. Se la connettività ibrida viene fornita solo in regioni selezionate, gli endpoint in altre regioni di Compute possono comunque essere instradati tramite queste connessioni per raggiungere i resolver on-premise.

Anche se l'endpoint con il ranking più alto si trova in un'altra regione, Cloud DNS continua a instradare le query a quell'endpoint. Ad esempio, se un endpoint nella regione A diventa non disponibile, il traffico viene instradato automaticamente a un endpoint integro nella regione B. Quando l'endpoint nella regione A è di nuovo integro, l'algoritmo di ranking rileverà il miglioramento delle prestazioni e inizierà a preferirlo di nuovo per le query future.

Puoi avere fino a 10 endpoint in uscita per progetto per regione, ma se necessario puoi richiedere un aumento della quota nella Google Cloud console. A una zona di forwarding o a una policy dei server possono essere collegati fino a 100 endpoint in uscita.

Instradare 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 basate sulla geolocalizzazione per instradare il traffico al server dei nomi target 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 target, la regione del server dei nomi target e la regione dell'endpoint in uscita non sono strettamente accoppiate. 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) autorizzata per la tua rete VPC. In questa zona, crea record A per gli IP del server DNS on-premise e applica una policy di routing basata sulla 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 del resolver europeo per le query provenienti dalle regioni europee Google Cloud .
  • 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 una procedura 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: l'endpoint in uscita selezionato risolve l' FQDN di destinazione (onprem-resolvers.example.com). Poiché l'endpoint in uscita è una risorsa di regione che si trova nella regione specificata, la policy di geolocalizzazione identifica l'origine della query come quella regione e restituisce l'indirizzo IP specifico che hai configurato per quella regione. L'endpoint in uscita inoltra quindi la query originale all'IP del server DNS di destinazione.

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

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

Una rete Google Cloud VPC è 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 avrà comunque esito positivo. La query verrà instradata tra le regioni all'endpoint in uscita disponibile con il ranking più alto che esiste nella 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 le query da più reti VPC nella stessa regione e richiedi che il resolver on-premise visualizzi 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 Creare 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 visualizza l'indirizzo IP di origine della subnet solo proxy di ogni rete VPC, consentendole di applicare configurazioni diverse per il traffico di ogni rete.

Forwarding unificato tra diverse reti VPC (hub e spoke)

Puoi configurare una zona di forwarding o una policy dei server in modo che utilizzi un endpoint in uscita in una rete VPC diversa e centralizzata (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 internamente il forwarding delle query.

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 e la relativa subnet solo proxy vengono creati centralmente nel progetto host. I progetti di servizio possono quindi creare zone di forwarding private o policy dei server e associarle tra progetti all'endpoint in uscita centralizzato nel progetto host (che richiede dns.outboundEndpoints.bindPrivateDNSZone o dns.outboundEndpoints.bindPrivateDNSPolicy nel progetto host).

Gestire le risorse di rete associate agli endpoint in uscita

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

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

Una subnet solo proxy o una rete VPC in uso attiva 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: una volta che l'endpoint non è più in uso, puoi eliminarlo. Questa azione rilascia la dipendenza dalla subnet solo proxy.
  3. Elimina la subnet solo proxy: dopo aver verificato che nessun'altra risorsa la stia utilizzando, elimina la subnet solo proxy.
  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, contribuendo 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:

  1. Crea una subnet di backup: crea una nuova subnet solo proxy nella stessa rete VPC e regione. Durante la creazione, devi impostare il ruolo di questa subnet su BACKUP.
  2. Attiva la nuova subnet: aggiorna il ruolo della nuova subnet a ACTIVE. In questo modo, il ruolo della subnet originale viene impostato automaticamente su BACKUP e le connessioni attive vengono eliminate.
  3. Attendi lo svuotamento della connessione: attendi il completamento del processo di svuotamento della connessione.
  4. Elimina la vecchia subnet: ora puoi eliminare la subnet originale una volta che ha il 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 dal traffico DNS, ti consigliamo di applicare la seguente architettura:

  • Esegui il deployment in una rete VPC di traffico in uscita dedicata: crea una rete VPC dedicata con una subnet normale (per l'indirizzo IP dell'endpoint in uscita) e una subnet solo proxy regionale riservata esclusivamente a Cloud DNS (--purpose=REGIONAL_MANAGED_PROXY e --role=ACTIVE).
  • Isola le reti VPC dell'applicazione:non eseguire il peering o il routing delle reti VPC dell'applicazione a questa rete di traffico in uscita dedicata. Cloud DNS instrada le query internamente all' Google Cloud infrastruttura, pertanto non è necessaria la connettività di rete diretta tra queste reti VPC.
  • Connetti la rete VPC di traffico in uscita dedicata ai target di forwarding esterni: Configura la connettività solo tra la rete VPC di traffico in uscita dedicata e i server dei nomi target esterni o on-premise. Stabilisci questo percorso utilizzando:
    • Peering di rete VPC a 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 a questo 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 dell'IP di origine e della subnet limitata alle risorse nella stessa regione: gli endpoint in uscita allocano gli intervalli di IP di origine dalla subnet solo proxy regionale della rete VPC a cui sono collegati. Nei deployment 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 connettività di rete ai server dei nomi esterni deve essere stabilita tramite il routing VPC standard, come Cloud Interconnect, Cloud VPN o il peering di rete VPC.

  • Supporto solo per 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 nelle zone di forwarding che si risolvono 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 risiedere 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 e non possono essere utilizzati come proxy di traffico in uscita o ancoraggio IP di origine statico per il traffico DNS di internet pubblico. Le query ai target di internet pubblico 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 regionali. Devi creare endpoint in ogni regione in cui intendi utilizzarli.

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

Passaggi successivi