GCP BYOIP: l’annuncio pubblico non è una rotta privata
Dividere un prefisso BYOIP tra sede e cloud richiede due piani. Separate l’annuncio pubblico, la delega e il prossimo salto privato.
Parte di un blocco pubblico resta in sede e parte si sposta in Google Cloud. Quella frase descrive due piani, non uno: un piano di annuncio su internet e un piano di inoltro privato. Trattarli come un unico problema di routing è il punto in cui i progetti BYOIP sbagliano.
Gli oggetti coinvolti rispondono a domande diverse, e solo uno di essi riguarda dove vanno i pacchetti in seguito.
Tre oggetti, tre domande
Un prefisso annunciato pubblicamente è l’unità che Google annuncia su internet per tuo conto. Un prefisso delegato pubblicamente è come lo spazio importato viene assegnato alle risorse Cloud supportate. Una rotta VPC, compresa quella appresa tramite Cloud Router da una VPN, seleziona un prossimo salto privato. Ognuno ha il proprio ambito, la propria API e il proprio messaggio di errore.
La versione a tabella è più breve.
| Object | Question it answers |
|---|---|
| Public advertised prefix | Which authorized range Google announces publicly |
| Public delegated prefix | How imported space is allocated to Cloud resources |
| VPN or Cloud Router route | Which private next hop carries a destination |
Solo la terza riga riguarda l’inoltro all’interno della tua rete.
Cosa copre l’avviso di sovrapposizione BYOIP
La documentazione BYOIP di Google tratta il prefisso annunciato come unità di annuncio e avverte degli annunci esterni sovrapposti, incluso un sottoprefisso annunciato fuori da Google. Quell’avviso riguarda il piano di annuncio pubblico. Non è un’affermazione su ogni rotta privata che potresti aggiungere.
Delegare un’allocazione più piccola all’interno di un prefisso importato non ti dà, di per sé, il permesso di annunciare il resto da un’altra origine.
Poni la domanda in termini di chi annuncia cosa. Se Google annuncia l’intero prefisso importato, una seconda origine che annuncia un sottoprefisso crea esattamente la sovrapposizione di cui avverte la documentazione, per quanto ordinate appaiano le tue rotte VPC.
Cosa decide una rotta privata
Un prefisso appreso tramite VPN non è un annuncio su internet, e nessuna quantità di BGP lo renderà tale. È una voce in una tabella di rotte VPC che indica quale tunnel o gateway deve trasportare il traffico verso quella destinazione. Se quella voce sia idonea, selezionata o utilizzabile dipende dalle regole di routing della VPC stessa.
La corrispondenza del prefisso più lungo si applica all’interno della tabella di rotte, quindi una rotta VPN più lunga può vincere localmente senza cambiare nulla al bordo pubblico.
Dividere un prefisso: la decisione che viene prima
Se l’architettura richiede che metà del blocco sia annunciata da un centro dati e metà da Google, definite il piano di annuncio prima di importare qualsiasi cosa. Confermate quali intervalli Google può annunciare, quali restano annunciati altrove e se i due si sovrappongono. Poi progettate il percorso privato per ogni destinazione e il suo percorso di ritorno. Se i provider non supportano la suddivisione che volete, cambiate la suddivisione invece di sperare che un prefisso VPN più lungo annulli una decisione al bordo pubblico.
Quest’ordine conta perché il secondo piano non può riparare il primo.
Verificate i due piani separatamente
Controllate il lato pubblico con gcloud compute public-advertised-prefixes list e confermate gli intervalli e il loro stato. Controllate il lato privato con gcloud compute routes list e gcloud compute routers get-status, che mostra cosa ha effettivamente scambiato BGP.
Un insieme di output ti dice cosa vede internet. L’altro ti dice dove va il tuo traffico. Nessuno dei due sostituisce l’altro.