Integra i tuoi indirizzi IP

La funzionalità Bring your own IP (BYOIP) ti consente di eseguire il provisioning dei tuoi indirizzi IPv4 pubblici e di utilizzarli per le risorse Google Cloud. Una volta importati gli indirizzi IP, Google Cloud li gestisce allo stesso modo degli indirizzi IP forniti da Google, con queste eccezioni:

  • Gli indirizzi IP sono disponibili solo per il cliente che li ha forniti.

  • Non sono previsti costi per gli indirizzi IP inattivi o in uso.

La migrazione live ti consente di controllare quando Google inizia a pubblicizzare percorsi per il tuo prefisso. La migrazione live non è disponibile per impostazione predefinita. Per richiedere l'accesso, contatta il tuo Customer Engineer di Google Cloud.

Panoramica

Per utilizzare il tuo indirizzo IP su Google, devi creare un prefisso annunciato pubblicamente (PAP). La verifica della proprietà per questo prefisso annunciato pubblicamente viene eseguita utilizzando il ROA e la convalida DNS inversa. Al termine della verifica, configuriamo l'annuncio di questo prefisso su internet, ma il prefisso non viene pubblicizzato finché non viene eseguito il provisioning. Occorrono fino a quattro settimane per eseguire il provisioning del prefisso pubblicizzato pubblico.

Mentre attendi il provisioning del prefisso annunciato pubblicamente, suddividi il prefisso in prefissi delegati pubblici (PDP). Puoi quindi dividere ulteriormente il prefisso delegato pubblico o utilizzarlo per creare indirizzi IP assegnabili. Il provisioning del prefisso delegato pubblico richiede fino a quattro settimane.

Una volta completato il provisioning del prefisso delegato pubblico, il prefisso pubblico annunciato viene pubblicizzato su internet. Se utilizzi la migrazione live, consulta Utilizzare la migrazione live per ulteriori passaggi.

Figura 1. Flusso di lavoro per la creazione di prefissi pubblicizzati pubblici e di prefissi delegati pubblici.

Prefissi annunciato pubblicamente

Un prefisso annunciato pubblicamente (PAP) è una risorsa in Compute Engine che rappresenta un prefisso IP che utilizzi in Google Cloud. Ciò consente di assegnare gli indirizzi IP dal tuo prefisso alle risorse Google Cloud. Il prefisso annunciato pubblicamente è una singola unità di annuncio di route. La spina dorsale globale di Google pubblicizza il prefisso pubblicizzato pubblico da tutti i suoi punti di presenza. Gli indirizzi IP nel prefisso annunciato pubblicamente utilizzano sempre il livello Premium di Network Service Tiers.

Un prefisso annunciato pubblicamente può essere utilizzato per creare prefissi delegati pubblici globali o prefissi delegati pubblici a livello di regione, ma non entrambi.

Se il prefisso annunciato pubblicamente è stato creato prima del 10 luglio 2023, consulta Modifiche del comportamento per BYOIP.

Quando viene creato un nuovo prefisso annunciato pubblicamente, deve avere un intervallo IP IPv4 con un intervallo CIDR minimo di dimensione /24. Non è possibile creare un intervallo CIDR più piccolo, ad esempio /25, come nuovo prefisso annunciato pubblicamente. Tuttavia, una volta creato, puoi suddividere un prefisso annunciato pubblicamente, ad esempio /24 o /23, in prefissi delegati pubblici più piccoli.

Prefissi delegati pubblici

Un prefisso delegato pubblico (PDP) è un blocco di indirizzi IP all'interno del prefisso annunciato pubblicamente e configurato all'interno di un singolo ambito (una regione specifica o globale). I blocchi IP devono essere delegati e assegnati a un ambito prima di poter assegnare indirizzi IP al tuo progetto o alla tua organizzazione.

La creazione di prefissi delegati pubblici globali è limitata. Per saperne di più, consulta Prefissi delegati pubblici globali.

Puoi suddividere un singolo prefisso delegato pubblico in più blocchi più piccoli, ma questi blocchi devono avere lo stesso ambito del blocco padre. Puoi configurare più prefissi delegati pubblici non contigui in un determinato ambito. Questi blocchi più piccoli sono prefissi delegati pubblici, ma sono indicati anche come sottoprefissi.

Prefissi delegati pubblici globali

Per creare un prefisso delegato pubblico globale, devi utilizzare un prefisso annunciato pubblicamente che viene utilizzato per creare solo prefissi delegati pubblici globali. Devi creare il prefisso delegato pubblico in un progetto a cui è stato concesso l'accesso per creare prefissi globali.

Per richiedere l'accesso, invia una richiesta di assistenza per richiedere che il tuo progetto venga inserito nella lista consentita per la creazione di prefissi delegati pubblici globali.

Indirizzi IP

Quando crei indirizzi IP da un prefisso delegato pubblico o sottoprefisso pubblico, gli indirizzi IP possono essere utilizzati solo all'interno del progetto e dell'ambito a cui sono allocati. Sono resi disponibili tutti gli indirizzi IP nel prefisso delegato pubblico o nel sottoprefisso pubblico; non esiste un indirizzo di rete o un indirizzo di trasmissione riservati. Ad esempio, se utilizzi un prefisso o un sottoprefisso delegato pubblico /28 per creare gli indirizzi IP, vengono create 16 risorse di indirizzi IP.

Chiunque disponga delle autorizzazioni IAM appropriate nel progetto può utilizzare gli indirizzi IP:

  • compute.addresses.* per gli indirizzi IP a livello di regione

  • compute.globalAddresses.* per gli indirizzi IP globali

Modifiche del comportamento per BYOIP

Le seguenti modifiche al comportamento entreranno in vigore il 10 luglio 2023:

  • Un prefisso annunciato pubblicamente può essere utilizzato per creare prefissi delegati pubblici globali o prefissi delegati pubblici a livello di regione, ma non entrambi.
  • I prefissi pubblicizzati pubblici creati prima del 10 luglio 2023 possono essere utilizzati solo per creare prefissi delegati pubblici a livello di regione.
  • Per creare prefissi delegati pubblici globali, devi richiedere l'accesso.

Le configurazioni esistenti del prefisso delegato pubblico globale non saranno interessate.

Porte aperte sugli indirizzi BYOIP

L'esecuzione di una scansione delle porte su un indirizzo BYOIP potrebbe restituire risultati imprevisti. Gli indirizzi BYOIP globali sono implementati da un servizio di infrastruttura chiamato Google Front End (GFE). Un indirizzo BYOIP, anche se non è utilizzato, potrebbe sembrare avere porte aperte perché queste sono utilizzate da altri servizi Google che condividono anche il GFE. Il traffico verso queste porte viene eliminato e non viene registrato.

Solo i bilanciatori del carico supportati possono utilizzare gli indirizzi IP globali. Per saperne di più sulle porte aperte sui bilanciatori del carico, consulta quanto segue:

Ruolo Amministratore IP pubblico

Puoi designare un amministratore per i prefissi e gli indirizzi BYOIP assegnando il ruolo Amministratore IP pubblico Compute (roles/compute.publicIpAdmin). Questo ruolo consente all'amministratore di gestire gli IP instradabili pubblicamente nella tua organizzazione.

L'amministratore IP pubblico può eseguire le seguenti attività:

  • Configurare prefissi pubblicizzati pubblici in un progetto di loro proprietà.
  • Configura i prefissi annunciati pubblici in prefissi delegati pubblici in un progetto di loro proprietà.
  • Delegare i sottoprefissi dai prefissi delegati pubblici a progetti specifici nell'organizzazione.
  • Revoca i sottoprefissi che in precedenza erano delegati dai prefissi pubblici delegati a un progetto specifico nell'organizzazione.
  • Elimina i prefissi delegati pubblici.

Pianificazione dell'implementazione

È importante pianificare il deployment, perché il completamento dei processi di provisioning ed eliminazione richiede diverse settimane. Per ulteriori informazioni sulla sequenza temporale del provisioning e sulle dimensioni consentite dei prefissi, consulta Limitazioni.

Di seguito sono riportate alcune decisioni da prendere in considerazione quando pianifichi l'implementazione:

  • Chi è responsabile dell'amministrazione degli indirizzi BYOIP? In genere si tratta di un amministratore o di un gruppo, ma in genere non sono gli stessi utenti che gestiscono singoli progetti. Utilizza i ruoli e le autorizzazioni IAM per distinguere chi dispone dei privilegi per i prefissi pubblicizzati pubblici e i prefissi delegati pubblici di cui prevedi di eseguire il provisioning.

  • Come vengono gestiti i prefissi? È probabile che tu voglia utilizzare i tuoi indirizzi BYOIP in progetti diversi. Puoi gestire i prefissi a livello centrale in un progetto, diverso dalle destinazioni finali degli indirizzi IP. Ti consigliamo di isolare l'amministrazione dei prefissi in un progetto proprietario, inclusi gli utenti e i gruppi con autorizzazioni di amministratore IP pubblico. Questo isolamento consente di evitare confusione sull'amministrazione dei prefissi e sull'uso involontario o non autorizzato di prefissi. Per ulteriori informazioni, consulta Architettura del progetto.

  • Come vengono denominati i prefissi? Ogni risorsa BYOIP (prefisso annunciato pubblicamente, prefisso delegato pubblico, sottoprefisso) richiede un nome, che viene utilizzato per gestire ogni risorsa. Il nome viene assegnato durante la creazione della risorsa, ma non può essere modificato senza eliminare e ricreare la risorsa. Per questo motivo, ti consigliamo di creare nomi facili da gestire. Ad esempio, pap-203-0-113-0-24, pdp-203-0-113-0-25 e sub-203-0-113-0-28, dove le lettere indicano il tipo di risorsa, mentre i numeri indicano la lunghezza del prefisso e del prefisso specifici.

  • Dove viene eseguito il provisioning degli indirizzi IP? È utile pensare al processo di provisioning come allo "stoccaggio" degli IP in regioni (o in ambito globale). Il processo di provisioning per l'archiviazione degli indirizzi IP richiede diverse settimane, perciò è utile pianificare ed eseguire il deployment di prefissi delegati pubblici molto prima che siano necessari.

    Non è necessario utilizzare immediatamente tutti gli IP in un prefisso delegato pubblico. Se non sai con certezza dove ne hai bisogno, esegui il provisioning solo dei prefissi delegati pubblici che hai sicuramente bisogno di utilizzare. Lo spostamento di un prefisso delegato pubblico richiede l'eliminazione completa e poi la nuova creazione, che può richiedere fino a otto settimane.

    Una volta completato il provisioning del prefisso delegato pubblico, puoi delegare sottoprefissi ai progetti e creare indirizzi da utilizzare con le risorse. Se prevedi di aver bisogno di indirizzi BYOIP in una regione, completa in anticipo il processo pubblico di provisioning del prefisso delegato, in modo da poter soddisfare le esigenze di gestione on demand in un secondo momento.

    Ad esempio, se hai bisogno di alcuni indirizzi IP in us-central1 e di alcuni indirizzi IP per i bilanciatori del carico globali e vuoi prenotare alcuni indirizzi IP per il futuro, devi creare il piano seguente.

    Tipo di prefisso Prefisso Ambito
    Prefisso annunciato pubblicamente 203.0.113.0/24
    Prefisso annunciato pubblicamente per i bilanciatori del carico globali 192.0.2.0/24
    Prefisso delegato pubblico 203.0.113.0/28 us-central1
    Prefisso delegato pubblico 203.0.113.16/28 us-east-4
    Prefisso delegato pubblico 192.0.2.0/28 globale

    I restanti indirizzi IP vengono riservati per un uso futuro.

Migrazione live

La migrazione live è una potente funzionalità che richiede pianificazione ed esecuzione dettagliate.

Utilizza la migrazione live per importare un prefisso BYOIP quando una qualsiasi parte del prefisso è già pubblicizzata pubblicamente. L'importazione di un prefisso pubblicizzato senza utilizzare la migrazione live potrebbe causare un routing e una perdita di pacchetti imprevisti.

La migrazione live ha una disponibilità limitata. Contatta il Customer Engineer di Google Cloud per ottenere l'accesso prima di creare un prefisso delegato pubblico con migrazione live abilitata.

Puoi abilitare la migrazione live quando crei un prefisso delegato pubblico. Per impedire a Google di pubblicizzare il prefisso annunciato pubblicamente ad app peer, devi garantire quanto segue:

  • Tutti i prefissi delegati pubblici all'interno del prefisso annunciato pubblico sono configurati con l'ambito regionale, non globale. Per ulteriori informazioni, consulta i suggerimenti per la migrazione live.

  • Nessun indirizzo IP nell'intervallo del prefisso annunciato pubblico viene assegnato alle risorse.

La Figura 2 mostra lo stesso progetto con configurazioni diverse, una delle quali impedisce la promozione del prefisso e due causa la promozione del prefisso pubblicizzato pubblico.

Figura 2. Annuncio con prefisso annunciato pubblicamente durante la migrazione live (fai clic per ingrandire).

La Figura 2 illustra i seguenti scenari:

  • Nel primo esempio di progetto, tutti i prefissi delegati pubblici nel prefisso pubblico pubblicizzato sono configurati con la migrazione live abilitata. Nessuna VM è configurata con indirizzi IP con questo prefisso.

    Risultato: il prefisso annunciato pubblicamente non è pubblicizzato.

  • Nel secondo esempio di progetto, tutti i prefissi delegati pubblici nel prefisso pubblico pubblicizzato sono configurati con la migrazione live abilitata. Una VM è configurata con un indirizzo IP di questo prefisso.

    Risultato: il prefisso annunciato pubblicamente viene pubblicizzato.

  • Nel terzo esempio di progetto, un prefisso delegato pubblico all'interno del prefisso pubblico annunciato non è configurato con la migrazione live abilitata. Nessuna VM è configurata con indirizzi IP con questo prefisso.

    Risultato: il prefisso annunciato pubblicamente viene pubblicizzato.

Puoi stabilire quando inizia la pubblicità assegnando gli indirizzi IP dal prefisso delegato pubblico alle risorse Google Cloud. Per ulteriori informazioni, consulta Utilizzare la migrazione live.

Al termine della migrazione live, contatta il tecnico del cliente Google Cloud in modo che possa disattivare la migrazione live per il prefisso. Per impostazione predefinita, la migrazione live viene disabilitata 30 giorni dopo l'avvio della pubblicità del prefisso annunciato pubblicamente. Se è necessario che l'opzione di migrazione live sia disponibile per più di 30 giorni, contatta il tuo Customer Engineer.

Limitazioni della migrazione live

Quando pianifichi una migrazione live, è importante che tu comprenda i seguenti requisiti e limitazioni:

  • La creazione di un prefisso delegato pubblico con migrazione live abilitata non è supportata se l'ambito è impostato su globale. Consulta i suggerimenti per la migrazione live per informazioni sulla gestione della migrazione live per le risorse globali.

  • Il prefisso più lungo di cui è possibile eseguire la migrazione è un /24 perché /24 è la lunghezza massima del prefisso instradabile su internet.

  • Non dare per scontato che tutte le app peer di Google rispettino il prefisso più lungo tra due siti. Alcuni peer potrebbero non avere tabelle di routing complete. Di conseguenza, un prefisso più breve pubblicizzato da Google per i peer è l'unico (e quindi anche il più lungo) che il peer vede. Di conseguenza, l'esistenza di qualsiasi prefisso da Google ha la precedenza, anche se pubblicizzi una route più specifica dalla tua località on-premise.

    Ad esempio:

    Un cliente ha un /23 che viene instradato attivamente dalla sua località on-premise. Il cliente prevede di separare /23 in due prefissi /24 e annunciare le route più specifiche dalla sua località on-premise. A seguito della disaggregazione, pianifica la configurazione di un prefisso /23 pubblicizzato pubblicamente per BYOIP. Presumono che le route più specifiche della loro località on-premise abbiano la precedenza sul prefisso BYOIP più breve e che il traffico continui a essere instradato ai prefissi on-premise più specifici.

    Purtroppo questo piano funziona solo parzialmente:

    • I peer Google che hanno tabelle di routing complete preferiscono i prefissi on-premise /24 più specifici.

    • I peer di Google che non hanno tabelle di routing complete preferiscono il prefisso pubblico pubblicizzato da Google, poiché le loro tabelle di routing non includono i prefissi più specifici.

  • Il traffico non viene recapitato se Google riceve traffico per un prefisso valido annunciato pubblicamente per il quale non hai eseguito il provisioning dei servizi, anche se è presente una pubblicità on-premise attiva per il prefisso.

    Ad esempio:

    Un cliente ha una rete on-premise che comprende due prefissi /24. Il prefisso annunciato pubblicamente è /23 aggregato.

    Il cliente esegue la migrazione di un singolo /24 a Google e ritira il prefisso on-premise, ma lascia l'altro /24 attivo nella località on-premise.

    Questa configurazione comporta una parte del routing del traffico a Google per l'intero prefisso /23, anche se viene annunciato un prefisso /24 più specifico dalla località on-premise. Questo scenario è difficile da diagnosticare, poiché vari sistemi autonomi consegnano il traffico alla tua località on-premise, mentre altri lo indirizzano a Google, nel qual caso il traffico viene ridotto.

Suggerimenti per la migrazione live

Come best practice, segui questi suggerimenti quando utilizzi la migrazione live.

  • Disaggrega tutti i prefissi della migrazione live nei prefissi più lunghi che riflettono il modo in cui vuoi pubblicizzare questi prefissi durante la migrazione. Negli esempi precedenti, /23 deve essere separato in due prefissi /24 e annunciato come tale a partire dalla sua posizione on-premise prima di creare il prefisso pubblicizzato pubblico.

  • Crea richieste ROA con lunghezza esatta del prefisso e non fare affidamento sul parametro di lunghezza massima da rispettare.

  • Assicurati che esistano richieste ROA RPKI sia per l'ASN di origine on-premise che per l'ASN di origine di Google. In assenza di un ROA per il prefisso on-premise, la creazione di un ROA di origine Google potrebbe far sì che gli ISP di terze parti escludano i prefissi on-premise se utilizzano il filtro RPKI automatico.

  • Crea prefissi pubblici separati per le risorse globali e per le risorse regionali se devi utilizzare la migrazione live. Quando abiliti la migrazione live su un prefisso delegato pubblico, devi specificare una regione per l'ambito. Non è possibile specificare l'ambito globale per un prefisso delegato pubblico in cui è abilitata la migrazione live. Se crei un prefisso delegato pubblico con ambito globale e migrazione live abilitati, il prefisso viene pubblicizzato immediatamente.

    Avere prefissi regionali in un prefisso annunciato pubblico e prefissi globali in un altro prefisso annunciato pubblicamente per gestirli separatamente. Puoi gestire la migrazione live delle risorse di regione e contattare il tuo Customer Engineer di Google Cloud per gestire la migrazione live delle risorse globali.

Architettura del progetto

Ti consigliamo di utilizzare le organizzazioni per trarre vantaggio da funzionalità quali le autorizzazioni IAM a livello di organizzazione e il VPC condiviso. Per ulteriori informazioni sull'utilizzo di un'organizzazione, vedi Creazione e gestione delle organizzazioni.

Amministrazione di indirizzi BYOIP in un'organizzazione

In questo esempio di un progetto appartenente a un'organizzazione, è presente un progetto dedicato, Public IP project, utilizzato per gestire gli indirizzi BYOIP. L'amministratore IP pubblico dell'organizzazione ha creato il prefisso annunciato pubblicamente e i prefissi delegati pubblici in Public IP project.

Quando VPC project richiede indirizzi IP pubblici, l'amministratore IP pubblico dell'organizzazione crea gli indirizzi IP in VPC project.

L'organizzazione può contenere più progetti e l'amministratore IP pubblico può delegare gli indirizzi IP a tutti da Public IP project.

Figura 3. Puoi utilizzare organizzazioni e progetti per gestire gli indirizzi BYOIP.

Amministrazione degli indirizzi BYOIP con il VPC condiviso

In questo esempio di un'organizzazione che contiene un VPC condiviso, esiste un progetto dedicato, Public IP project, utilizzato per gestire gli indirizzi BYOIP. L'amministratore IP pubblico dell'organizzazione ha creato il prefisso annunciato pubblicamente e i prefissi delegati pubblici in Public IP project.

Quando Shared VPC host project o i progetti di servizio correlati richiedono indirizzi IP pubblici, l'amministratore IP pubblico dell'organizzazione crea gli indirizzi IP in Shared VPC host project. Il progetto host e i progetti di servizio possono accedere agli indirizzi BYOIP dal progetto host.

La creazione di indirizzi IP in un progetto di servizio del VPC condiviso non è supportata.

Figura 4. Puoi delegare gli indirizzi BYOIP a un progetto host del VPC condiviso, ma non a un progetto di servizio del VPC condiviso. Tuttavia, un progetto di servizio può utilizzare indirizzi BYOIP delegati al progetto host.

Amministrazione di indirizzi BYOIP senza un'organizzazione

Se utilizzi un progetto che non appartiene a un'organizzazione, non puoi creare un progetto separato per l'amministrazione degli indirizzi BYOIP. Crea il prefisso annunciato pubblicamente e i prefissi delegati pubblici nello stesso progetto che richiede gli indirizzi BYOIP.

Quote e limiti

Sono previsti quote e limiti per i prefissi delegati pubblici (PDP) e i prefissi pubblicizzati pubblici (PAP). Per ulteriori informazioni, consulta Quote e limiti VPC.

Passaggi successivi