GCP BYOIP: o anúncio público não é uma rota privada
Dividir um prefixo BYOIP entre o local e a nuvem exige dois planos. Separe o anúncio público, a delegação e o próximo salto privado.
Parte de um bloco público fica no local e parte passa para o Google Cloud. Essa frase descreve dois planos, não um: um plano de anúncio na internet e um plano de encaminhamento privado. Tratá-los como um único problema de roteamento é onde os projetos BYOIP falham.
Os objetos envolvidos respondem a perguntas diferentes, e apenas um deles trata de para onde os pacotes vão em seguida.
Três objetos, três perguntas
Um prefixo anunciado publicamente é a unidade que o Google anuncia na internet em seu nome. Um prefixo delegado publicamente é como o espaço importado é atribuído aos recursos de Cloud suportados. Uma rota de VPC, incluindo uma aprendida pelo Cloud Router a partir de uma VPN, seleciona um próximo salto privado. Cada um tem o seu próprio âmbito, a sua própria API e a sua própria mensagem de erro.
A versão em tabela é mais 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 |
Apenas a terceira linha trata do encaminhamento dentro da sua rede.
O que o aviso de sobreposição do BYOIP cobre
A documentação do BYOIP do Google trata o prefixo anunciado como unidade de anúncio e avisa sobre anúncios externos sobrepostos, incluindo um subprefixo anunciado fora do Google. Esse aviso é sobre o plano de anúncio público. Não é uma afirmação sobre cada rota privada que você possa adicionar.
Delegar uma alocação menor dentro de um prefixo importado não lhe dá, por si só, permissão para anunciar o restante a partir de outra origem.
Faça a pergunta em termos de quem anuncia o quê. Se o Google anuncia todo o prefixo importado, uma segunda origem que anuncie um subprefixo cria exatamente a sobreposição sobre a qual a documentação avisa, por mais arrumadas que pareçam as suas rotas de VPC.
O que uma rota privada decide
Um prefixo aprendido por uma VPN não é um anúncio na internet, e nenhuma quantidade de BGP o tornará um. É uma entrada numa tabela de rotas de VPC que diz qual túnel ou gateway deve transportar o tráfego para esse destino. Se essa entrada é elegível, selecionada ou utilizável depende das próprias regras de roteamento da VPC.
A correspondência de prefixo mais longo aplica-se dentro da tabela de rotas, por isso uma rota VPN mais longa pode ganhar localmente sem mudar nada na borda pública.
Dividir um prefixo: a decisão que vem primeiro
Se a arquitetura exige que metade do bloco seja anunciada a partir de um centro de dados e metade a partir do Google, resolva o plano de anúncio antes de importar qualquer coisa. Confirme quais intervalos o Google pode anunciar, quais continuam anunciados noutro lugar e se os dois se sobrepõem. Depois desenhe o caminho privado para cada destino e o seu caminho de retorno. Se os fornecedores não suportam a divisão que você quer, mude a divisão em vez de esperar que um prefixo VPN mais longo anule uma decisão na borda pública.
Essa ordem importa porque o segundo plano não pode reparar o primeiro.
Verifique os dois planos em separado
Verifique o lado público com gcloud compute public-advertised-prefixes list e confirme os intervalos e o estado deles. Verifique o lado privado com gcloud compute routes list e gcloud compute routers get-status, que mostra o que o BGP realmente trocou.
Um conjunto de saídas diz-lhe o que a internet vê. O outro diz-lhe para onde vai o seu tráfego. Nenhum substitui o outro.