O VPN ao VPC funciona, pero o servizo xestionado esgota o tempo
O túnel remata no teu bordo, non na porta de entrada do provedor. Clasifica o destino como aloxado en VM, conectado ao VPC ou só público antes de cambiar unha ruta.
Chegar a unha base de datos xestionada a través dun VPN adoita fallar por un motivo que ninguén escribiu no manual: o túnel remata no bordo da túa rede, mentres que o servizo nunca estivo do teu lado. A táboa de rutas parece correcta, o túnel informa de que está activo e a conexión esgota o tempo igualmente. Percorre as catro comprobacións seguintes en orde e detente na primeira cuxa condición de éxito non se cumpra, porque cada comprobación posterior dá por feito que as anteriores se cumpriron.
Comprobación un: onde vive realmente o extremo?
Unha pasarela VPN une dúas redes cuxo direccionamento controlas ti. Un servizo xestionado opérase detrás da porta de entrada propia do provedor, e esa porta adopta unha de tres formas segundo o produto. Se non sabes con que forma tratas, ningún traballo de rutas axudará, porque o fallo pode non ser un fallo de encamiñamento en absoluto.
| 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 maioría das tardes perdidas veñen de saltar esta clasificación e ir directo á táboa de rutas. Un servizo aloxado no provedor cun extremo público non está detrás do teu túnel diga o que diga o diagrama, e un conectado ao VPC nunca aparecerá nunha resposta DNS pública.
Comprobación dous: un servizo conectado ao VPC como ElastiCache
As cachés dese tipo diríxense dentro do teu propio VPC e non teñen ningún oínte orientado a internet. Un VPN de cliente rematado nese mesmo VPC pode alcanzalas, pero só cando coinciden tres condicións. O extremo da caché ten que estar asociado a subredes que o teu túnel poida ver, o seu grupo de seguridade ten que permitir o enderezo desde o que chegan os teus clientes, e o lado do cliente necesita unha ruta que cubra as subredes da caché.
O erro habitual é supoñer que unha conexión nalgún lugar próximo conta. Conectar o VPN a outro VPC, ou apoiarse só no emparellamento, non estende o grupo de seguridade da caché nin a táboa de rutas da súa subrede aos teus clientes. Cando o túnel existente remata noutro sitio, un host de salto ou un servidor VPN colocado dentro dese VPC é a alternativa habitual. Esa alternativa é un apaño e non un deseño, e debería etiquetarse como tal no manual.
Comprobación tres: un extremo PaaS con nome público
Azure Database for PostgreSQL presenta un nome de servidor público. Non che entrega un enderezo privado que poidas fixar nun ficheiro hosts e encamiñar por unha pasarela. Os extremos de servizo de rede virtual limita que subredes poden chegar a un recurso; non autorizan a un cliente local que chega por un VPN.
Obter acceso privado significa introducir un extremo privado ou un deseño de vínculo privado e despois engadir unha zona DNS privada para que o nome público responda con ese extremo en lugar de con internet. Un VPN combinado cunha regra de extremo de servizo é outra arquitectura que só se parece nun diagrama. App Service segue a mesma lóxica desde a dirección contraria: a integración con VNet permite á aplicación facer chamadas saíntes cara a un VNet e non crea unha ruta privada entrante desde o teu túnel. O acceso privado entrante esixe, por tanto, un extremo privado, un contorno de App Service ou unha pasarela diante da aplicación, e cal deles podes usar depende do plan.
Comprobación catro: produtos coa súa propia porta de entrada
Firebase Hosting non se pode conectar a un Cloud VPN, porque a capa de aloxamento é un frontal global e non algo dentro do VPC dun proxecto. A alternativa documentada é construír o punto de entrada controlado un mesmo, cunha instancia de proxy ou un balanceador de carga respaldado por un depósito. En calquera caso o sitio deixa de ser un produto de aloxamento puro e pasa a ser infraestrutura que agora operas ti. Ese intercambio merece nomearse antes de que alguén prometa que o túnel o cubrirá.
Private API Gateway está máis preto do lado dos servizos de VPC: un extremo de VPC de interface publica un nome de host cuxas respostas son enderezos privados, e o tráfico desde as túas instalacións chega polo túnel ou por unha interconexión dedicada. O extremo ten que estar asociado á API, e o certificado xunto co nome de host deben coincidir co dominio personalizado que usan quen chama.
Os túneles de Google Cloud VPN enlánzanse a enderezos IP de pares, non a nomes. O reenvío de DNS configúrase por separado, e por iso un túnel pode estar perfectamente san mentres as consultas na zona privada remota seguen fallando.
Despois localiza a fronteira
Executa a mesma conexión desde unha VM dentro do VPC. Cando alí funciona e falla desde o cliente VPN, o oco está entre a ruta do cliente e o extremo do servizo: unha ruta, un grupo de seguridade, unha política de extremo ou un nome. Cando fallan ambos os intentos, nada desa rede pode alcanzar o servizo, e o VPN nunca foi o obstáculo.
getent hosts db.internal.example
nc -vz db.internal.example 5432Fai a consulta de nome e a comprobación de porto por separado, porque fallan por motivos distintos e o par diche que metade do camiño está rota. Un nome que se resolve a un enderezo público está a dicirche que a zona DNS privada non está en xogo.