El VPN al VPC funciona, pero el servicio gestionado agota el tiempo
El túnel termina en tu borde, no en la puerta de entrada del proveedor. Clasifica el destino como alojado en VM, conectado al VPC o solo público antes de cambiar una ruta.
Llegar a una base de datos gestionada a través de una VPN suele fallar por un motivo que nadie escribió en el manual: el túnel termina en el borde de tu red, mientras que el servicio nunca estuvo de tu lado. La tabla de rutas parece correcta, el túnel informa de que está activo y la conexión agota el tiempo igualmente. Recorre las cuatro comprobaciones siguientes en orden y detente en la primera cuya condición de éxito no se cumpla, porque cada comprobación posterior da por hecho que las anteriores se cumplieron.
Comprobación uno: ¿dónde vive realmente el extremo?
Una puerta de enlace VPN une dos redes cuyo direccionamiento controlas tú. Un servicio gestionado se opera detrás de la puerta de entrada propia del proveedor, y esa puerta adopta una de tres formas según el producto. Si no sabes con qué forma tratas, ninguna cantidad de trabajo de rutas ayudará, porque el fallo puede no ser un fallo de enrutamiento 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 |
La mayoría de las tardes perdidas vienen de saltarse esta clasificación e ir directo a la tabla de rutas. Un servicio alojado en el proveedor con un extremo público no está detrás de tu túnel diga lo que diga el diagrama, y uno conectado al VPC nunca aparecerá en una respuesta DNS pública.
Comprobación dos: un servicio conectado al VPC como ElastiCache
Las cachés de ese tipo se direccionan dentro de tu propio VPC y no tienen ningún oyente orientado a internet. Una VPN de cliente terminada en ese mismo VPC puede alcanzarlas, pero solo cuando coinciden tres condiciones. El extremo de la caché tiene que estar asociado a subredes que tu túnel pueda ver, su grupo de seguridad tiene que permitir la dirección desde la que llegan tus clientes, y el lado del cliente necesita una ruta que cubra las subredes de la caché.
El error habitual es suponer que una conexión en algún lugar cercano cuenta. Conectar la VPN a otro VPC, o apoyarse solo en el emparejamiento, no extiende el grupo de seguridad de la caché ni la tabla de rutas de su subred a tus clientes. Cuando el túnel existente termina en otro sitio, un host de salto o un servidor VPN colocado dentro de ese VPC es la alternativa habitual. Esa alternativa es un apaño y no un diseño, y debería etiquetarse como tal en el manual.
Comprobación tres: un extremo PaaS con nombre público
Azure Database for PostgreSQL presenta un nombre de servidor público. No te entrega una dirección privada que puedas fijar en un archivo hosts y enrutar por una puerta de enlace. Los extremos de servicio de red virtual limitan qué subredes pueden llegar a un recurso; no autorizan a un cliente local que llega por una VPN.
Obtener acceso privado significa introducir un extremo privado o un diseño de vínculo privado y luego añadir una zona DNS privada para que el nombre público responda con ese extremo en lugar de con internet. Una VPN combinada con una regla de extremo de servicio es otra arquitectura que solo se parece en un diagrama. App Service sigue la misma lógica desde la dirección contraria: la integración con VNet permite a la aplicación hacer llamadas salientes hacia un VNet y no crea una ruta privada entrante desde tu túnel. El acceso privado entrante exige, por tanto, un extremo privado, un entorno de App Service o una puerta de enlace delante de la aplicación, y cuál de ellos puedes usar depende del plan.
Comprobación cuatro: productos con su propia puerta de entrada
Firebase Hosting no se puede conectar a una Cloud VPN, porque la capa de alojamiento es un frontal global y no algo dentro del VPC de un proyecto. La alternativa documentada es construir el punto de entrada controlado uno mismo, con una instancia de proxy o un balanceador de carga respaldado por un depósito. En cualquier caso el sitio deja de ser un producto de alojamiento puro y pasa a ser infraestructura que ahora operas tú. Ese intercambio merece nombrarse antes de que alguien prometa que el túnel lo cubrirá.
Private API Gateway está más cerca del lado de los servicios de VPC: un extremo de VPC de interfaz publica un nombre de host cuyas respuestas son direcciones privadas, y el tráfico desde tus instalaciones llega por el túnel o por una interconexión dedicada. El extremo tiene que estar asociado a la API, y el certificado junto con el nombre de host deben coincidir con el dominio personalizado que usan quienes llaman.
Los túneles de Google Cloud VPN se enlazan a direcciones IP de pares, no a nombres. El reenvío de DNS se configura por separado, y por eso un túnel puede estar perfectamente sano mientras las consultas en la zona privada remota siguen fallando.
Después localiza la frontera
Ejecuta la misma conexión desde una VM dentro del VPC. Cuando allí funciona y falla desde el cliente VPN, el hueco está entre la ruta del cliente y el extremo del servicio: una ruta, un grupo de seguridad, una política de extremo o un nombre. Cuando fallan ambos intentos, nada de esa red puede alcanzar el servicio, y la VPN nunca fue el obstáculo.
getent hosts db.internal.example
nc -vz db.internal.example 5432Haz la consulta de nombre y la comprobación de puerto por separado, porque fallan por motivos distintos y el par te dice qué mitad del camino está rota. Un nombre que se resuelve a una dirección pública te está diciendo que la zona DNS privada no está en juego.