Cliente local de base de datos y RDS privado: por qué la conexión agota el tiempo

El portátil de un desarrollador agota el tiempo al conectar con el punto de enlace privado de RDS, mientras las mismas credenciales funcionan desde un host bastión. Nada está caído. Al camino entre ese portátil y la base de datos le falta una de tres cosas: un nombre que resuelva, una ruta que transporte el tráfico o una regla de grupo de seguridad que admita el origen que la base de datos ve realmente. Averigüe cuál falta antes de cambiar las otras dos.

Lea el fallo en la capa correcta

Un tiempo de espera no es un solo error. Un nombre que no resuelve falla antes de que un paquete salga de la máquina. Una dirección sin ruta envía paquetes a un agujero negro. Un puerto filtrado produce una espera que parece exactamente un host equivocado. Ejecute los pasos en orden y deténgase en el primero que falle.

dig +short db.internal.example
nc -vz db.internal.example 5432

Si el nombre devuelve una dirección pública, o no devuelve nada, el túnel todavía no es el problema.

Si el nombre resuelve y la prueba del puerto se cuelga, compare la dirección que resolvió con la dirección que informa la base de datos. Un punto de enlace gestionado puede resolver a una dirección privada dentro de la VPC y a nada útil fuera de ella, y una dirección copiada de una consulta antigua apuntará a un host que ya no responde.

Separe el túnel de la ruta

Conectar una VPN de cliente no encamina automáticamente todos los rangos privados. El perfil lleva las rutas que empuja el servicio, y el cliente puede instalar solo algunas de ellas. Mire qué rangos añadió realmente el cliente y si la dirección de la base de datos cae dentro de uno.

ip route get 10.20.40.15
ip addr show tun0

Una ruta que apunta a la interfaz del túnel es necesaria; no es suficiente, porque el lado opuesto todavía tiene que aceptar el tráfico.

Los perfiles de túnel dividido son el origen habitual de este fallo parcial. Funcionan para la aplicación para la que se diseñó el perfil y dejan el rango de la base de datos fuera del túnel, lo que produce exactamente el tiempo de espera que produciría un cortafuegos.

Ajuste el grupo de seguridad al origen real

El grupo de seguridad de RDS admite orígenes, no personas. Según la arquitectura, el origen puede ser el grupo de clientes de la VPN, la dirección privada de un bastión o una dirección NAT a la que se traduce el tráfico. Lea la regla y el origen real del paquete a la vez.

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

Una regla para la dirección de casa de un solo portátil es un problema de mantenimiento, no un diseño de acceso.

Cuando una VPN de cliente o una puerta de enlace NAT está en el camino, la base de datos puede ver la dirección del traductor en lugar de la dirección del túnel del desarrollador. Por eso una regla copiada de una configuración de bastión que funciona puede fallar para un portátil: los dos caminos llegan desde orígenes distintos aunque ambos parezcan internos.

Prefiera un camino estrecho a uno ancho

Cuando un desarrollador necesita una base de datos, el reenvío basado en sesión suele ser más barato de operar que un túnel de red completo. El cliente local se conecta a un puerto reenviado, y el componente remoto hace la conexión a la base de datos desde dentro de la red.

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

Mantenga intacta la verificación TLS en ese diseño. El cliente debería seguir validando el certificado del servidor contra el nombre que espera; un puerto reenviado local no es motivo para desactivar la verificación, y desactivarla oculta exactamente el problema de identidad que merece la pena detectar.

La elección entre un túnel completo y un reenvío estrecho es una decisión sobre el alcance, no sobre teatro de seguridad.

Deje un camino repetible detrás

Documente el nombre del punto de enlace en lugar de una dirección resuelta, el rango de origen que admite el grupo de seguridad y el rol de base de datos que usa el desarrollador. Esos tres hechos explican la mayoría de fallos futuros sin una llamada. Añada también la versión del perfil de cliente, porque un cambio de perfil puede eliminar una ruta que el antiguo llevaba.

Después pruebe el caso negativo una vez: un cliente fuera del origen aprobado debería seguir siendo rechazado.

Una base de datos privada que solo funciona para la persona que la configuró no es acceso privado; es una excepción no documentada que espera ser redescubierta. Escriba el camino, y el siguiente desarrollador heredará un método en lugar de un misterio.