API do Google por VPN: encaminhe a VIP, não apenas a sub-rede

Entre no servidor local por SSH, suba o túnel e a VM privada responde; depois a primeira chamada a uma API do Google falha sem rota. A sub-rede da VM e as VIPs da API são destinos diferentes, então uma rota para uma não seleciona a outra. Três condições precisam valer antes de uma chamada privada à API funcionar. O nome da API precisa resolver para uma VIP, o prefixo VIP precisa ser anunciado pelo túnel, e a VPC precisa saber como devolver a resposta. Um ping não diz nada disso, e uma sessão SSH funcionando até uma máquina na sub-rede também não.

As VIPs da API são destinos separados

O Google publica VIPs dedicadas para acesso à API a partir da rede local, e são esses os endereços que o seu DNS precisa devolver para os nomes da API. Ambas são prefixos pequenos e nenhuma é espaço RFC 1918:

Endereços que parecem públicos não significam que a rota deva sair do túnel para a internet comum. Os prefixos existem para que um cliente local alcance os front-ends do Google por um caminho suportado em vez de um ponto de saída arbitrário. Trate-os como destinos que pertencem ao túnel, não como hosts a sondar. Uma regra de firewall escrita para saída à internet costuma descartá-los, e essa é uma razão comum para uma chamada falhar antes de começar.

O DNS decide a que endpoint você chega

Aponte o resolvedor local para os registros que o Google documenta para o endpoint escolhido, de modo que os nomes de que a aplicação precisa respondam com essa VIP. Apenas googleapis.com não é um inventário: registros de pacotes, registros de contêineres e conectores de migração têm seus próprios nomes documentados. A VIP restrita também não carrega todos os serviços, então um nome que resolve pode continuar sem suporte. Anote os domínios que a aplicação realmente contata antes de mexer no resolvedor.

Adivinhar um endereço de VM na VPC como substituto de um nome de serviço não é correção, e normalmente esconde a lacuna de DNS até outro cliente falhar.

Anuncie o prefixo VIP, mantenha o resto

Com uma conexão baseada em BGP, o Cloud Router precisa anunciar o prefixo VIP escolhido para que o roteador local aprenda essa faixa pela sessão prevista. Anunciar apenas as sub-redes da VPC não acrescenta essa faixa, e o roteador local continua usando o caminho padrão para esses endereços. O prefixo na tabela de rotas é a única prova de que o anúncio atravessou a sessão.

Mantenha os anúncios existentes enquanto acrescenta o novo, porque opções no nível do roteador e no nível do par têm alcance diferente, e trocar o conjunto pode retirar redes que já funcionavam. Depois verifique o anúncio efetivo em cada sessão, e não no roteador como um todo. Um prefixo ausente e um prefixo retirado parecem iguais do lado local, então é a visão da sessão que separa uma omissão de uma regressão.

O lado da VPC precisa da própria rota e de caminho de volta

Dentro da VPC, o caminho da VIP precisa usar o gateway de internet padrão como próximo salto, e apesar do nome esse tráfego permanece na rede do Google. A VPC também precisa de uma rota de volta à origem local pela VPN, que é um objeto separado do prefixo anunciado. Leve em conta os requisitos regionais de roteamento documentados quando o túnel e o cliente não estão na mesma região.

Verifique o caminho de volta de forma independente, porque uma direção de requisição que funciona pode esconder uma direção de resposta quebrada. Duas direções, duas rotas, e cada uma falha com o próprio sintoma.

Teste a requisição e então leia a rejeição

O eco ICMP não recebe resposta dessas VIPs, então um ping que falha não prova nada e um que funciona prova muito pouco. No cliente real, examine a resposta do nome e a rota selecionada, e então faça uma requisição HTTPS autorizada ao serviço que lhe importa. Se a requisição chegar ao serviço e for rejeitada, olhe as credenciais, o IAM e qualquer política de perímetro de serviço aplicável.

O roteamento privado não concede autorização de API e não muda o que a identidade pode fazer. Sucesso de transporte e uma resposta autorizada são resultados separados, e você precisa dos dois. Mantenha também explícito o caminho IPv6, porque configurar os prefixos IPv4 não diz nada sobre um cliente que prefere IPv6.

O guia do Google sobre Private Google Access a partir da rede local cobre os registros DNS e os requisitos de roteamento em conjunto, então compare suas configurações de resolvedor e de anúncio com ele e não com um post de fórum. Depois repita a mesma requisição e anote a resposta e a rota no mesmo tíquete.