Bring your own IP

Bring your own IP (BYOIP) consente di eseguire il provisioning e utilizzare i tuoi indirizzi IPv4 pubblici 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 le seguenti eccezioni:

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

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

La migrazione live consente di controllare quando Google inizia le route pubblicitarie per il tuo prefisso. La migrazione live non è disponibile per impostazione predefinita. Per richiedere l'accesso, contatta il tuo rappresentante di Google Cloud.

Panoramica

Per inserire il tuo indirizzo IP in Google, devi creare un prefisso annunciato pubblicamente. La verifica della proprietà viene eseguita per questo prefisso annunciato pubblicamente utilizzando il ROAS e la convalida DNS inversa. Una volta completata la verifica, configuriamo l'annuncio di questo prefisso su Internet, ma il prefisso non viene pubblicizzato fino al provisioning. Il provisioning del prefisso annunciato pubblicamente deve richiedere fino a quattro settimane.

Mentre attendi che venga eseguito il provisioning del prefisso annunciato pubblico, devi suddividerlo in prefissi delegati pubblici (PDP), configurati per avere un ambito regionale o globale. Puoi quindi suddividere 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 annunciato pubblico viene pubblicizzato su Internet. Se utilizzi la migrazione live, consulta la sezione Utilizzare la migrazione live per ulteriori passaggi.

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

Prefissi pubblici

Un prefisso annunciato pubblicamente è una risorsa in Compute Engine che rappresenta un prefisso IP da te trasferito in Google Cloud. In questo modo puoi allocare gli indirizzi IP dal tuo prefisso alle risorse Google Cloud. Il prefisso annunciato pubblicamente è una singola unità pubblicitaria del percorso. La rete backbone globale di Google pubblicizza il prefisso annunciato pubblicamente da tutti i suoi punti di presenza. Gli indirizzi IP nel prefisso annunciato pubblicamente utilizzano sempre il livello Premium dei livelli di servizio di rete.

Quando crei un nuovo prefisso annunciato pubblicamente, deve avere un intervallo IP IPv4 con un intervallo CIDR minimo di dimensioni pari a /24. Un intervallo CIDR inferiore, ad esempio /25, non può essere creato come nuovo prefisso annunciato pubblicamente. Tuttavia, una volta creato, puoi suddividere un prefisso annunciato pubblico, ad esempio /24 o /23, in prefissi delegati pubblici più piccoli.

Prefissi delegati pubblici

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

Puoi suddividere un prefisso annunciato pubblico in più prefissi delegati pubblici e configurarli tutti con l'ambito che desideri nei progetti Google Cloud. Puoi suddividere un singolo prefisso delegato pubblico in più blocchi più piccoli, ma questi hanno lo stesso ambito del blocco principale. Puoi configurare più prefissi delegati pubblici contigui in un determinato ambito. Questi blocchi più piccoli sono prefissi delegati pubblici, ma sono noti anche come prefissi secondari.

Indirizzi IP

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

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

  • compute.addresses.* per indirizzi IP a livello di area geografica

  • compute.globalAddresses.* per indirizzi IP globali

Ruolo Amministratore IP pubblico

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

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

  • Configurare i prefissi pubblici in un progetto di loro proprietà.
  • Configura i prefissi pubblicizzati pubblicamente in prefissi delegati pubblici in un progetto di loro proprietà.
  • Delega i prefissi secondari dai prefissi delegati pubblici a progetti specifici dell'organizzazione.
  • Revoca i prefissi che in precedenza erano stati delegati dai prefissi pubblici delegati a un progetto specifico dell'organizzazione.
  • Elimina prefissi delegati pubblici.

Pianificazione dell'implementazione

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

Ecco alcune decisioni da prendere in considerazione quando pianifichi il deployment:

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

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

  • Come vengono nominati i prefissi? Ogni risorsa BYOIP (prefisso pubblicizzato al pubblico, prefisso delegato pubblico, prefisso secondario) richiede un nome e tale nome viene utilizzato per gestire ogni risorsa. Puoi assegnare il nome durante la creazione della risorsa e non è più possibile cambiarla senza eliminarla e ricrearla. 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, sub-203-0-113-0-28, dove le lettere indicano il tipo di risorsa, mentre i numeri indicano il prefisso e la lunghezza del prefisso specifici.

  • Dove viene eseguito il provisioning degli indirizzi IP? È utile considerare il processo di provisioning come "stocking" IP in aree geografiche (o l'ambito globale). Il completamento del processo di provisioning per l'archiviazione degli indirizzi IP richiede diverse settimane, pertanto è utile pianificare e sottoporre a deployment i prefissi delegati pubblici molto prima che siano necessari.

    Non devi utilizzare immediatamente tutti gli IP in un prefisso delegato pubblico. Se non sai dove serve, esegui solo il provisioning dei prefissi delegati pubblici che devi utilizzare. Lo spostamento di un prefisso delegato pubblico richiede l'eliminazione completa e la creazione successiva, che può richiedere fino a otto settimane.

    Una volta completato il provisioning del prefisso delegato pubblico, puoi delegare i prefissi secondari ai progetti e creare indirizzi da utilizzare con le risorse. Se devi abilitare gli indirizzi BYOIP in un'area geografica, completa in anticipo il processo pubblico di provisioning dei prefissi, in modo da soddisfare le esigenze di gestione on demand.

    Ad esempio, supponiamo che tu abbia un prefisso annunciato pubblicamente di /24. Hai bisogno di alcuni indirizzi IP in us-central1, di alcuni indirizzi IP per i bilanciatori del carico globali e di volerne riservare alcuni per l'uso futuro. Potresti creare il piano seguente:

    Tipo di prefisso Prefisso Ambito
    Prefisso annunciato pubblicamente 203.0.113.0/24
    Prefisso delegato pubblico 203.0.113.0/28 us-central1
    Prefisso delegato pubblico 203.0.113.16/28 globale
    Indirizzi IP rimanenti riservati per 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 qualsiasi prefisso è già pubblicizzato pubblicamente. L'importazione di un prefisso pubblicizzato senza utilizzare la migrazione in tempo reale potrebbe causare un routing imprevisto e una perdita di pacchetti.

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

La migrazione live viene attivata quando crei un prefisso delegato pubblico. Per impedire a Google di pubblicizzare il prefisso annunciato pubblicamente alle app peer, devi assicurarti che:

  • Tutti i prefissi delegati pubblici all'interno del prefisso annunciato pubblico sono configurati con ambito a livello di area geografica, non a livello globale. Per ulteriori informazioni, consulta i consigli per la migrazione live.

  • Nessun indirizzo IP compreso nell'intervallo del prefisso annunciato pubblicamente è assegnato alle risorse.

La Figura 2 mostra lo stesso progetto con configurazioni diverse, una delle quali impedisce la promozione del prefisso e due le quali fanno promuovere il prefisso annunciato pubblicamente.

Figura 2. Annuncio prefisso pubblico pubblicizzato 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 annunciato pubblico sono configurati con la migrazione live abilitata. Nessuna VM è configurata con indirizzi IP di questo prefisso.

    Risultato: il prefisso annunciato pubblicamente non è pubblicizzato.

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

    Risultato: il prefisso annunciato pubblicamente è pubblicizzato.

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

    Risultato: il prefisso annunciato pubblicamente è pubblicizzato.

Sei tu a controllare quando inizia la pubblicità assegnando gli indirizzi IP dal tuo prefisso delegato pubblico alle risorse Google Cloud. Per ulteriori informazioni, consulta la sezione Utilizzare la migrazione live.

Al termine della migrazione live, contatta il tuo rappresentante di Google Cloud perché possa disattivare la migrazione live per il tuo prefisso. Per impostazione predefinita, la migrazione live viene disattivata 30 giorni dopo che hai avviato la pubblicità del prefisso annunciato pubblicamente. Se devi avere a disposizione l'opzione di migrazione live per più di 30 giorni, contatta il tuo rappresentante di Google Cloud.

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 la migrazione live non è supportata se l'ambito è impostato su globale. Consulta i consigli 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 è /24 perché /24 è il numero massimo di prefisso instradabile su Internet.

  • Non dare per scontato che tutti i 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 tali peer è l'unico (e quindi il più lungo) che il peer vede. Di conseguenza, l'esistenza di un prefisso da parte di Google ha la precedenza, anche se pubblicizzi un percorso più specifico dalla località on-premise.

    Ad esempio:

    Un cliente ha un /23 che viene instradato attivamente dalla sua località on-premise. Il cliente prevede di disaggregare /23 in due prefissi /24 e di annunciare i percorsi più specifici dalla sua località on-premise. In seguito alla disaggregazione, prevede di configurare un prefisso annunciato pubblicamente /23 per BYOIP. Presuppongono che le route più specifiche provenienti dalla località on-premise abbiano la precedenza sul prefisso BYOIP più breve e che il traffico continui verso i prefissi on-premise più specifici.

    Purtroppo questo piano funziona solo parzialmente:

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

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

  • Il traffico non viene pubblicato se Google riceve traffico per un prefisso valido pubblicizzato, per il quale non hai eseguito il provisioning dei servizi, anche se è presente un annuncio on-premise attivo per il prefisso.

    Ad esempio:

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

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

    Questa configurazione comporta l'instradamento del traffico a Google per l'intero prefisso /23, anche se è stato ancora annunciato un prefisso /24 più specifico dalla località on-premise. Questo scenario è difficile da diagnosticare, in quanto vari sistemi autonomi distribuiscono il traffico verso la tua sede on-premise, ma altri la inviano a Google, nel qual caso il traffico viene ridotto.

Consigli sulla migrazione live

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

  • Separa i prefissi di migrazione live nei prefissi più lunghi che riflettono il modo in cui vuoi pubblicizzare questi prefissi durante la migrazione. Negli esempi precedenti, l'elemento /23 dovrebbe essere disaggregato in due prefissi /24 e annunciato come tale dalla sua posizione on-premise prima di creare il prefisso pubblicizzato.

  • Crea richieste di tipo ROA per la 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 origine on-premise sia per l'ASN di origine di Google. Se non è previsto alcun ROAS per il prefisso on-premise, la creazione di un ROAS originale di Google potrebbe indurre gli ISP di terze parti a filtrare i prefissi on-premise, se utilizzano un filtro RPKI automatico.

  • Se devi utilizzare la migrazione live, crea prefissi pubblici distinti per le risorse globali e per le risorse a livello di area geografica. Quando abiliti la migrazione live su un prefisso delegato pubblico, devi specificare un'area geografica per l'ambito. Non è supportato specificare l'ambito globale di un prefisso delegato pubblico per cui è abilitata la migrazione live. Se crei un prefisso delegato pubblico con ambito globale e migrazione live, il prefisso viene pubblicizzato immediatamente.

    Se disponi di prefissi regionali in un prefisso annunciato pubblicamente e di prefissi globali in un altro prefisso annunciato pubblico, puoi gestirli separatamente. Puoi gestire la migrazione live delle risorse a livello di area geografica e contattare il tuo rappresentante di Google Cloud per gestire la migrazione live delle risorse a livello globale.

Architettura del progetto

Ti consigliamo di utilizzare le organizzazioni per trarre vantaggio da funzionalità quali le autorizzazioni IAM a livello di organizzazione e di VPC condiviso. Per scoprire di più su come utilizzare un'organizzazione, vedi Creazione e gestione delle organizzazioni.

Amministrazione degli indirizzi BYOIP in un'organizzazione

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

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

L'organizzazione può contenere più progetti e l'amministratore degli IP pubblici può delegare a ciascuno di essi gli indirizzi IP da Public IP Project.

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

Gestione degli indirizzi BYOIP con VPC condiviso

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

Quando Shared VPC Host Project o i progetti di servizi correlati necessitano di 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 del progetto host.

La creazione di indirizzi IP in un progetto di servizio 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 VPC condiviso. Tuttavia, un progetto di servizio può utilizzare indirizzi BYOIP delegati al progetto host.

Amministrazione di indirizzi BYOIP senza 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 pubblico e i prefissi delegati pubblici nello stesso progetto che richiede gli indirizzi BYOIP.

Passaggi successivi