PostgreSQL por VPN: qué dirección de origen verá pg_hba

PostgreSQL nunca se entera de que un cliente está en una VPN. Recibe una conexión TCP desde una dirección y un conjunto de credenciales, y decide qué hacer con ellas. Por tanto, hacer que el acceso dependa del túnel implica ordenar tres decisiones separadas para que coincidan, y luego comprobar la única dirección que el servidor ve realmente en lugar de la que dibujó en el diagrama.

Tres decisiones que no deben fusionarse

Dónde escucha el servidor es una decisión. Qué tráfico puede llegar a esa dirección es una segunda, tomada por el cortafuegos del host y cualquier frontera de red delante de él. Qué identidad de base de datos puede autenticarse desde qué origen es una tercera, tomada en pg_hba.conf.

Cada una la aplica un componente distinto, y cada una falla con un mensaje distinto. Fusionarlas en una discusión es como la gente acaba editando el archivo HBA para arreglar un problema de cortafuegos. Manténgalas en orden: un listener que no está enlazado no se puede alcanzar, a un puerto filtrado no se puede conectar, y una regla HBA solo decide qué ocurre después de que exista una conexión. Cuando un cambio no tiene efecto, identifique cuál de las tres capas cambió realmente.

Dónde escucha el servidor

Enlácese a una dirección que esté realmente asignada a la máquina, no a un nombre de interfaz:

listen_addresses = '10.20.0.30'

La base de datos puede estar detrás de la pasarela VPN sin su propia interfaz de túnel, y es exactamente por eso que una dirección es lo correcto que nombrar. Cambiar esta configuración requiere un reinicio completo; una recarga no basta.

Luego filtre el puerto, normalmente 5432, en el host y en cada frontera delante de él. Enlazarse a una dirección privada no es prueba de denegación pública, porque una redirección de puerto o un mapeo de dirección en la nube todavía puede entregar paquetes a ese listener privado.

La dirección que el HBA ve realmente

Con acceso enrutado el servidor ve la dirección interna del túnel de cada cliente. Con traducción de origen ve en su lugar la dirección traducida de la pasarela, y cada cliente se colapsa en ese único valor. Inspeccione el origen a través de las propias evidencias de conexión del servidor antes de elegir un prefijo que permitir.

Para un despliegue que ya usa TLS y SCRAM, un ejemplo deliberadamente estrecho de acceso remoto tiene este aspecto:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

Eso permite un rol y una base de datos sobre TLS desde el grupo indicado, y luego rechaza otro acceso TCP remoto. No sustituye a un archivo HBA completo: mantenga la administración local, la replicación y cualquier otro servicio autorizado, y coloque las reglas estrechas antes de las autorizaciones más amplias.

Cuando la traducción está en juego, el HBA no puede distinguir a los clientes por sus direcciones originales. Mantenga la admisión de red ajustada y exija credenciales reales de base de datos, y nunca sustituya la autenticación trust por una cuenta real.

Gana la primera coincidencia, sin respaldo

PostgreSQL lee el archivo de arriba abajo y usa el primer registro que coincide con la conexión. No hay un segundo intento si falla la autenticación de ese registro, así que una autorización amplia anterior derrota en silencio a un rechazo posterior.

Esa regla de orden es el motivo más común por el que un rechazo cuidadosamente escrito nunca surte efecto. Ponga las reglas específicas primero y las amplias al final, y luego lea el archivo como una secuencia en lugar de como un conjunto. Una regla que añadió al final no es una política, es un comentario. Muévala hacia arriba y recargue antes de concluir que el archivo se está ignorando.

La referencia de HBA define tanto el orden como la diferencia entre los registros host y hostssl, lo que importa cuando el sentido de la regla es que la conexión debe estar cifrada.

Recarga, reinicio y el caso denegado

Los cambios de HBA se aplican con una recarga, y la vista pg_hba_file_rules le ayuda a encontrar errores de análisis. Esa vista describe el contenido actual del archivo, no si el servidor en ejecución los cargó correctamente, así que un listado limpio no es prueba de que las nuevas reglas estén activas.

Los cambios del listener necesitan su propio reinicio, y las dos operaciones se confunden fácilmente cuando un cambio parece no tener efecto.

Pruebe con sesiones nuevas: un cliente aprobado con la cuenta prevista se conecta, la misma cuenta desde una ruta no aprobada no lo hace, y una identidad de base de datos no autorizada sigue fallando desde dentro de la VPN. Esos tres resultados separan la frontera de red de la autorización de base de datos, que es todo el sentido de mantener las decisiones separadas.