O VPN para a VPC funciona, mas o serviço gerido expira
O túnel termina na sua margem, não à porta de entrada do fornecedor. Classifique o alvo como alojado em VM, ligado à VPC ou apenas público antes de alterar uma rota.
Alcançar uma base de dados gerida através de uma VPN falha normalmente por um motivo que ninguém escreveu no manual: o túnel termina na margem da sua rede, enquanto o serviço nunca esteve do seu lado dela. A tabela de rotas parece correta, o túnel reporta-se ativo e a ligação expira mesmo assim. Percorra as quatro verificações abaixo por ordem e pare na primeira cuja condição de sucesso não se verifica, porque cada verificação seguinte assume que as anteriores passaram.
Primeira verificação: onde vive realmente o ponto final?
Um gateway VPN liga duas redes cujo endereçamento controla. Um serviço gerido é operado atrás da porta de entrada própria do fornecedor, e essa porta assume uma de três formas conforme o produto. Se não sabe com que forma está a lidar, nenhum trabalho de rotas ajudará, porque a falha pode não ser uma falha de encaminhamento.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
A maioria das tardes perdidas vem de saltar esta classificação e ir diretamente para a tabela de rotas. Um serviço alojado no fornecedor com um ponto final público não está atrás do seu túnel diga o que disser o diagrama, e um ligado à VPC nunca aparecerá numa resposta DNS pública.
Segunda verificação: um serviço ligado à VPC como o ElastiCache
As caches desse tipo são endereçadas dentro da sua própria VPC e não têm qualquer ouvinte virado para a internet. Uma VPN de cliente terminada nessa mesma VPC consegue alcançá-las, mas apenas quando três condições coincidem. O ponto final da cache tem de estar associado a sub-redes que o seu túnel veja, o grupo de segurança tem de permitir o endereço de onde vêm os seus clientes, e o lado do cliente precisa de uma rota que cubra as sub-redes da cache.
O erro comum é supor que uma ligação algures por perto conta. Ligar a VPN a outra VPC, ou apoiar-se apenas no peering, não estende o grupo de segurança da cache nem a tabela de rotas da sua sub-rede aos seus clientes. Quando o túnel existente termina noutro local, um jump host ou um servidor VPN colocado dentro dessa VPC é a alternativa habitual. Essa alternativa é um contorno e não um desenho, e deve ser rotulada como tal no manual.
Terceira verificação: um ponto final PaaS com nome público
O Azure Database for PostgreSQL apresenta um nome de servidor público. Não lhe entrega um endereço privado que possa fixar num ficheiro hosts e encaminhar através de um gateway. Os pontos finais de serviço de rede virtual limitam que sub-redes podem alcançar um recurso; não autorizam um cliente local que chega por uma VPN.
Obter acesso privado significa introduzir um ponto final privado ou um desenho de ligação privada e depois acrescentar uma zona DNS privada para que o nome público responda com esse ponto final em vez da internet. Uma VPN combinada com uma regra de ponto final de serviço é outra arquitetura que só se parece num diagrama. O App Service segue a mesma lógica na direção oposta: a integração com VNet permite à aplicação fazer chamadas de saída para uma VNet e não cria um caminho privado de entrada a partir do seu túnel. O acesso privado de entrada exige, por isso, um ponto final privado, um App Service Environment ou um gateway à frente da aplicação, e qual deles pode usar depende do plano.
Quarta verificação: produtos com a sua própria porta de entrada
O Firebase Hosting não pode ser ligado a uma Cloud VPN, porque a camada de alojamento é um frontend global e não algo dentro da VPC de um projeto. A alternativa documentada é construir o ponto de entrada controlado por si, com uma instância de proxy ou um balanceador de carga suportado por um balde. De qualquer forma o site deixa de ser um produto de alojamento puro e passa a ser infraestrutura que agora opera. Vale a pena nomear essa troca antes de alguém prometer que o túnel a cobrirá.
O Private API Gateway está mais próximo do lado dos serviços de VPC: um ponto final de VPC do tipo interface publica um nome de anfitrião cujas respostas são endereços privados, e o tráfego das suas instalações chega pelo túnel ou por uma interligação dedicada. O ponto final tem de estar associado à API, e o certificado juntamente com o nome de anfitrião têm de corresponder ao domínio personalizado usado por quem chama.
Os túneis do Google Cloud VPN ligam-se a endereços IP de pares, não a nomes. O encaminhamento de DNS configura-se em separado, e é por isso que um túnel pode estar perfeitamente saudável enquanto as pesquisas na zona privada remota continuam a falhar.
Depois localize a fronteira
Execute a mesma ligação a partir de uma VM dentro da VPC. Quando ali funciona e falha a partir do cliente VPN, a lacuna está entre o caminho do cliente e o ponto final do serviço: uma rota, um grupo de segurança, uma política de ponto final ou um nome. Quando ambas as tentativas falham, nada nessa rede consegue alcançar o serviço, e a VPN nunca foi o obstáculo.
getent hosts db.internal.example
nc -vz db.internal.example 5432Faça a pesquisa de nome e a verificação de porta em separado, porque falham por motivos diferentes e o par diz-lhe qual metade do caminho está quebrada. Um nome que resolve para um endereço público diz-lhe que a zona DNS privada não está em jogo.