Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Bring your own IP

Integra il tuo indirizzo IP (BYOIP) per eseguire il provisioning e utilizzare i tuoi indirizzi IPv4 pubblici per le risorse Google Cloud. Dopo l'importazione degli 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 portati.

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

La migrazione live ti 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 trasferire il tuo indirizzo IP su 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 richiede fino a quattro settimane.

Mentre attendi il provisioning del prefisso annunciato pubblicamente, lo dividi in un prefisso delegato pubblico (PDP), che configuri per l'ambito a livello di area geografica o globale. 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, questo 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 e di delegati pubblici.

Prefissi pubblicizzati pubblicamente

Un prefisso annunciato pubblicamente (PAP) è una risorsa in Compute Engine che rappresenta un prefisso IP che inserisci 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à della pubblicità relativa al percorso. La 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 /24. Un intervallo CIDR più piccolo, ad esempio /25, non può essere creato come nuovo prefisso annunciato pubblicamente. Tuttavia, una volta creato, puoi suddividere un prefisso annunciato pubblicamente, ad esempio un /24 o un /23, in prefissi delegati pubblici più piccoli.

Prefissi delegati pubblici

Un prefisso delegato pubblico (PDP) è un blocco IP all'interno del prefisso annunciato pubblicamente configurato in 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.

Puoi suddividere un prefisso annunciato pubblicamente in più prefissi delegati pubblici e configurare ciascuno di essi con l'ambito che vuoi nei tuoi progetti Google Cloud. Puoi suddividere un singolo prefisso delegato pubblico in più blocchi più piccoli, ma questi ultimi devono avere lo stesso ambito del blocco principale. Puoi configurare più prefissi delegati pubblici non contigui in un determinato ambito. Questi blocchi più piccoli sono prefissi delegati pubblici, ma vengono chiamati anche prefissi.

Indirizzi IP

Quando crei indirizzi IP da un prefisso o prefisso secondario pubblico, puoi utilizzarli solo nel progetto e nell'ambito a cui sono assegnati. Tutti gli indirizzi IP nel prefisso o sottopreferito delegato pubblico vengono resi disponibili; non esiste un indirizzo di rete o indirizzo di trasmissione riservato. Ad esempio, se utilizzi un prefisso o delegato secondario /28 pubblico 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

Porte aperte su 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 denominato Google Front End (GFE). Un indirizzo BYOIP, anche se non utilizzato, potrebbe sembrare che abbia porte aperte perché quelle porte 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 indirizzi IP globali. Per saperne di più sulle porte aperte sui bilanciatori del carico, consulta quanto segue:

Ruolo di amministratore IP pubblico

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

L'amministratore IP pubblico può eseguire le seguenti operazioni:

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

Pianificazione dell'implementazione

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

Ecco alcune decisioni da prendere quando pianifichi il deployment:

  • Chi è responsabile dell'amministrazione degli indirizzi BYOIP? Si tratta in genere di un amministratore o di un gruppo, ma di solito non è lo stesso utente che gestisce i singoli progetti. Utilizza i ruoli e le autorizzazioni IAM per distinguere chi dispone di privilegi per i prefissi pubblicizzati pubblicamente 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 in modo centralizzato in un progetto diverso dalle destinazioni finali degli indirizzi IP. Ti consigliamo di isolare l'amministrazione dei prefissi in un progetto, inclusi gli utenti e i gruppi specifici con le 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 Architettura del progetto.

  • Come vengono denominati i prefissi? Ogni risorsa BYOIP (prefisso annunciato pubblicamente, prefisso delegato pubblico) richiede un nome, che viene utilizzato per gestire ogni risorsa. Puoi assegnare il nome durante la creazione della risorsa, ma non è 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, e i numeri indicano il prefisso e la lunghezza del prefisso specifici.

  • Dove viene eseguito il provisioning degli indirizzi IP? È utile pensare al processo di provisioning come a "IP di stoccaggio" in aree geografiche (o all'ambito globale). Il processo di provisioning per lo stoccaggio degli indirizzi IP richiede diverse settimane, quindi è utile pianificare ed eseguire il deployment dei prefissi delegati pubblici molto prima che siano necessari.

    Non è necessario utilizzare subito tutti gli indirizzi IP in un prefisso delegato pubblico. Se non sai dove averne bisogno, esegui il provisioning solo dei prefissi delegati pubblici che hai la certezza di dover utilizzare. Lo spostamento di un prefisso delegato pubblico richiede l'eliminazione completa e quindi la ricreazione, 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 prevedi che gli indirizzi BYOIP sono necessari in una regione, completa in anticipo la procedura di provisioning del prefisso delegata pubblica, in modo da poter soddisfare le esigenze di elaborazione on demand.

    Ad esempio, supponiamo che tu abbia un prefisso annunciato pubblicamente da /24. Sai che ti serviranno alcuni indirizzi IP in us-central1, alcuni indirizzi IP per i bilanciatori del carico globali e vuoi prenotarne alcuni per l'uso futuro. Puoi creare il seguente piano:

    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 un uso futuro.

Migrazione live

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

Utilizza la migrazione live per importare un prefisso BYOIP quando qualsiasi parte del prefisso è già pubblicizzata pubblicamente. L'importazione di un prefisso pubblicizzato senza utilizzare la migrazione live 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.

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

  • Tutti i prefissi delegati pubblici all'interno del prefisso annunciato pubblicamente sono configurati con ambito regionale, non globale. Per ulteriori informazioni, consulta i consigli sulla migrazione live.

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

La figura 2 mostra lo stesso progetto con diverse configurazioni, una delle quali impedisce la pubblicità del prefisso e due del che comportano la promozione del prefisso annunciato pubblicamente.

Figura 2. Pubblicità pubblica del prefisso annunciato 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 pubblicamente sono configurati con la migrazione live abilitata. Nessuna VM è configurata con indirizzi IP da questo prefisso.

    Risultato: il prefisso annunciato pubblicamente non è pubblicizzato.

  • Nel secondo esempio di progetto, per tutti i prefissi delegati pubblici nel prefisso annunciato pubblicamente è configurata 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 pubblicamente non è configurato con la migrazione live abilitata. Nessuna VM è configurata con indirizzi IP da questo prefisso.

    Risultato: il prefisso annunciato pubblicamente è pubblicizzato.

Puoi controllare l'inizio della pubblicità assegnando gli indirizzi IP dal tuo prefisso delegato pubblico alle risorse Google Cloud. Per ulteriori informazioni, consulta la pagina relativa all'uso della migrazione live.

Una volta completata la migrazione live, contatta il tuo rappresentante Google Cloud in modo che 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 hai bisogno di avere l'opzione di migrazione live disponibile per più di 30 giorni, contatta il tuo rappresentante Google Cloud.

Limitazioni della migrazione live

Quando si pianifica una migrazione live, è importante comprendere 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 consigli sulla migrazione live per informazioni su come gestire la migrazione live per le risorse globali.

  • Il prefisso più lungo di cui è possibile eseguire la migrazione è /24, perché /24 è la lunghezza massima del 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 questi peer è l'unico (e quindi anche il più lungo) visualizzato dal peer. Di conseguenza, l'esistenza di un prefisso di Google ha la precedenza, anche se pubblicizzi un percorso più specifico dalla sede on-premise.

    Ad esempio:

    Un cliente ha un /23 che viene instradato attivamente dalla sua località on-premise. Il cliente prevede di suddividere il /23 in due prefissi /24 e di annunciare le route più specifiche dalla propria località on-premise. In seguito alla disaggregazione, prevede di configurare un prefisso annunciato pubblicamente /23 per BYOIP. Si presume che le route più specifiche dalla località on-premise abbiano la precedenza sul prefisso BYOIP più breve e che il traffico continui instradato ai 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 hanno 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 annunciato pubblicamente valido 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 prefisso annunciato pubblicamente è l'aggregato /23.

    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 l'esecuzione del routing del traffico a Google per l'intero prefisso /23, anche se esiste un prefisso /24 più specifico annunciato dalla località on-premise. Questo scenario è difficile da diagnosticare, in quanto vari sistemi autonomi inviano traffico alla tua sede on-premise, mentre altri la inviano a Google. In questo caso, il traffico viene ridotto.

Consigli sulla migrazione live

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

  • Disaggrega tutti 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, /23 deve essere disaggregato in due prefissi /24 e annunciato come tale dalla sua posizione on-premise prima di creare il prefisso annunciato pubblicamente.

  • Creare richieste di rotazione esatte della lunghezza del prefisso esatta 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 on-premise per il prefisso on-premise, la creazione di un ROA di origine Google potrebbe indurre gli ISP di terze parti a escludere tali prefissi se utilizzano un filtro RPKI automatico.

  • Crea prefissi pubblici annunci separati per le risorse globali e le risorse di regione se devi utilizzare la migrazione live. Quando abiliti la migrazione live su un prefisso delegato pubblico, devi specificare una regione per l'ambito. La specifica dell'ambito globale per un prefisso delegato pubblico per cui è abilitata la migrazione live non è supportata. Se crei un prefisso delegato pubblico con ambito globale e migrazione live abilitata, il prefisso viene pubblicizzato immediatamente.

    La presenza di prefissi regionali in un prefisso annunciato pubblicamente e di prefissi globali in un altro prefisso annunciato pubblicamente ti consente di gestirli separatamente. Puoi gestire la migrazione live delle risorse a livello di regione e contattare il tuo rappresentante Google Cloud per gestire la migrazione in tempo reale delle risorse globali.

Architettura del progetto

Ti consigliamo di utilizzare le organizzazioni per trarre vantaggio da funzionalità quali autorizzazioni IAM a livello di organizzazione e VPC condiviso. Per saperne di più sull'utilizzo di un'organizzazione, consulta 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 IP pubblico dell'organizzazione ha creato il prefisso annunciato pubblicamente e i prefissi delegati pubblici in Public IP Project.

Quando VPC Project ha bisogno di indirizzi IP pubblici, l'amministratore dell'IP pubblico dell'organizzazione crea gli indirizzi IP in VPC Project.

L'organizzazione può contenere più progetti e l'amministratore dell'IP pubblico può delegare loro gli indirizzi IP a partire da Public IP Project.

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

Amministrazione degli indirizzi BYOIP con VPC condiviso

In questo esempio di 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 hanno bisogno di indirizzi IP pubblici, l'amministratore dell'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 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 degli 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. Creare il prefisso annunciato pubblicamente e i prefissi delegati pubblici nello stesso progetto che richiede gli indirizzi BYOIP.

Quote e limiti

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

Passaggi successivi