Muitas equipas acreditam que o IP privado do Cloud SQL só funciona de dentro da VPC, e a crença persiste porque a falha parece um problema de base de dados. A Google documenta o acesso a partir de redes ligadas através do Cloud VPN ou do Cloud Interconnect. Essas redes não precisam de uma funcionalidade especial de base de dados, mas de duas trocas de rotas fáceis de deixar meio configuradas. O túnel sobe, as instâncias de computação respondem e a ligação à base de dados expira — exatamente a combinação que envia as pessoas para a consola errada.

Mito: IP privado significa privado para a VPC

O acesso a serviços privados é um emparelhamento de VPC entre a sua rede e uma rede de produtor pertencente à Google. O intervalo atribuído ao serviço vive do lado do produtor, e o endereço da instância está dentro dele. É esse emparelhamento que permite a uma base de dados no seu projeto ficar num endereço para o qual a sua VPC encaminha sem que nenhuma sub-rede explícita sua o contenha.

Como é um emparelhamento, também tem comportamento de emparelhamento, incluindo a parte em que as rotas personalizadas não atravessam automaticamente.

Mito: um túnel a funcionar transporta a rota da base de dados consigo

Dois intervalos têm de sobreviver à viagem. O primeiro é o prefixo do cliente: a sua rede local tem de ser conhecida pelo Cloud Router com prefixos concretos, porque uma rota predefinida não consegue fornecer a importação de que a rede do produtor precisa para o caminho de volta. O segundo é o intervalo de serviço atribuído, que o lado externo tem de aprender para que os seus pacotes para a base de dados tenham para onde ir. São rotas diferentes mantidas em fronteiras diferentes, e corrigir uma deixa a outra quebrada.

Do lado da Google, isso significa ativar Export custom routes nas ligações de emparelhamento relevantes e adicionar o intervalo de serviço atribuído às rotas anunciadas do Cloud Router para o túnel.

Mantenha os anúncios que já existem. Adicionar o intervalo de serviço não deve remover as rotas da VPC que a mesma sessão BGP transporta para outro tráfego, e um conjunto de anúncios substituído por completo é uma segunda falha escondida atrás da primeira. Verifique também as rotas efetivas no dispositivo externo, porque conseguir alcançar a gateway VPN ou outra sub-rede só prova transporte.

Mito: o Cloud SQL Auth Proxy resolve a rede

The Auth Proxy fornece autenticação suportada e transporte cifrado entre a sua aplicação e a instância. Não cria uma rota. Um proxy iniciado num anfitrião sem caminho para a rede privada falhará exatamente como falharia uma ligação direta, e os seus registos serão menos úteis sobre o porquê. Mover o proxy para um anfitrião que tem conetividade altera qual troço do caminho tem de funcionar, e isso é uma decisão de projeto real e não um contorno.

O que não faz é permitir que um portátil desligado alcance uma instância apenas privada.

Mito: o Private Service Connect segue as mesmas regras

O Private Service Connect usa um endpoint na sua própria sub-rede e um arranjo de DNS que controla, por isso a rota até ele é uma rota comum para um endereço que possui. As definições de exportação de emparelhamento não se aplicam a esse desenho, e copiar alterações de emparelhamento para uma implementação PSC acrescenta risco sem acrescentar alcance.

Ambos lhe dão um endereço privado; a semelhança termina aí.

Teste o caminho pela ordem correta

A partir do cliente externo, teste primeiro o endpoint TCP da base de dados. Um aperto de mão TCP concluído significa que encaminhamento, firewall e ouvinte estão todos no lugar, e o teste seguinte é uma operação autenticada permitida. Uma rejeição de autenticação é, nesse momento, uma boa notícia, porque prova que um ouvinte da base de dados respondeu. Um tempo limite de ICMP não diz quase nada sobre o acesso à base de dados, porque muitos caminhos o descartam enquanto encaminham TCP sem problemas.

Se os seus intervalos de cliente estiverem fora de RFC 1918, reveja os requisitos adicionais de exportação de rotas e de autorização de rede antes de concluir que o desenho não é suportado.

Registe quatro objetos com a ligação: o prefixo externo, o intervalo de serviço atribuído, as ligações de emparelhamento envolvidas e o encaminhador que anuncia. Esses quatro explicam todo o caminho privado e substituem a lenda de que o Cloud SQL ou precisa sempre de um proxy ou não pode ser alcançado por VPN de todo.

Artigos relacionados