GCP BYOIP: o anuncio público non é unha ruta privada
Dividir un prefixo BYOIP entre a sede e a nube require dous plans. Separe o anuncio público, a delegación e o seguinte salto privado.
Parte dun bloque público queda na sede e parte trasládase a Google Cloud. Esa frase describe dous plans, non un: un plan de anuncio en internet e un plan de reenvío privado. Tratalos como un único problema de encamiñamento é onde fallan os deseños BYOIP.
Os obxectos implicados responden a preguntas distintas, e só un deles trata de cara a onde van os paquetes despois.
Tres obxectos, tres preguntas
Un prefixo anunciado publicamente é a unidade que Google anuncia a internet no seu nome. Un prefixo delegado publicamente é como se asigna o espazo importado aos recursos de Cloud admitidos. Unha ruta de VPC, incluída unha aprendida por Cloud Router desde unha VPN, selecciona un seguinte salto privado. Cada un ten o seu propio ámbito, a súa propia API e a súa propia mensaxe de erro.
A versión en táboa é máis curta.
| 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 |
Só a terceira fila trata do reenvío dentro da súa rede.
Que cubre a advertencia de solapamento de BYOIP
A documentación de BYOIP de Google trata o prefixo anunciado como unha unidade de anuncio e advirte sobre anuncios externos solapados, incluído un subprefixo anunciado fóra de Google. Esa advertencia trata do plan de anuncio público. Non é unha afirmación sobre cada ruta privada que poida engadir.
Delegar unha asignación menor dentro dun prefixo importado non lle dá, por si só, permiso para anunciar o resto desde outra orixe.
Plantee a pregunta en termos de quen anuncia que. Se Google anuncia todo o prefixo importado, unha segunda orixe que anuncie un subprefixo crea exactamente o solapamento do que advirte a documentación, por ordenadas que parezan as súas rutas de VPC.
Que decide unha ruta privada
Un prefixo aprendido por unha VPN non é un anuncio en internet, e ningunha cantidade de BGP o converterá nun. É unha entrada nunha táboa de rutas de VPC que di que túnel ou pasarela debe transportar o tráfico cara a ese destino. Que esa entrada sexa elixible, seleccionada ou utilizábel depende das propias regras de encamiñamento da VPC.
A coincidencia de prefixo máis longo aplícase dentro da táboa de rutas, así que unha ruta VPN máis longa pode gañar localmente sen cambiar nada no bordo público.
Dividir un prefixo: a decisión que chega primeiro
Se a arquitectura necesita que a metade do bloque se anuncie desde un centro de datos e a outra metade desde Google, resolva o plan de anuncio antes de importar nada. Confirme que rangos pode anunciar Google, cales seguen anunciados noutro lugar e se ambos se solapan. Despois deseñe a ruta privada para cada destino e a súa ruta de retorno. Se os provedores non admiten a división que vostede quere, cambie a división en lugar de esperar que un prefixo VPN máis longo anule unha decisión no bordo público.
Esa orde importa porque o segundo plan non pode reparar o primeiro.
Verifique os dous plans por separado
Comprobe o lado público con gcloud compute public-advertised-prefixes list e confirme os rangos e o seu estado. Comprobe o lado privado con gcloud compute routes list e gcloud compute routers get-status, que mostra que intercambiou realmente BGP.
Un conxunto de saídas dille que ve internet. O outro dille a onde vai o seu tráfico. Ningún substitúe o outro.