PostgreSQL por VPN: que enderezo de orixe verá pg_hba

O listener, a devasa e a primeira regra HBA coincidente son tres decisións. Comprobe a orixe que PostgreSQL recibe realmente antes de escoller un prefixo.

PostgreSQL nunca se entera de que un cliente está nunha VPN. Recibe unha conexión TCP desde un enderezo e un conxunto de credenciais, e decide que facer con elas. Por tanto, facer que o acceso dependa do túnel implica ordenar tres decisións separadas para que coincidan, e despois comprobar o único enderezo que o servidor ve realmente en lugar do que debuxou no diagrama.

Tres decisións que non deben fusionarse

Onde escoita o servidor é unha decisión. Que tráfico pode chegar a ese enderezo é unha segunda, tomada pola devasa do host e calquera fronteira de rede diante dela. Que identidade de base de datos pode autenticarse desde que orixe é unha terceira, tomada en pg_hba.conf.

Cada unha é aplicada por un compoñente distinto, e cada unha falla cunha mensaxe distinta. Fusionalas nunha discusión é como a xente acaba editando o ficheiro HBA para arranxar un problema de devasa. Mantéñaas en orde: un listener que non está ligado non se pode alcanzar, a un porto filtrado non se pode conectar, e unha regra HBA só decide que ocorre despois de que exista unha conexión. Cando un cambio non ten efecto, identifique cal das tres capas cambiou realmente.

Onde escoita o servidor

Ligazón a un enderezo que estea realmente asignado á máquina, non a un nome de interface:

listen_addresses = '10.20.0.30'

A base de datos pode estar detrás da pasarela VPN sen a súa propia interface de túnel, e é exactamente por iso que un enderezo é o correcto que nomear. Cambiar esta configuración require un reinicio completo; unha recarga non abonda.

Despois filtre o porto, normalmente 5432, no host e en cada fronteira diante del. Ligarse a un enderezo privado non é proba de denegación pública, porque unha redirección de porto ou unha asignación de enderezo na nube aínda pode entregar paquetes a ese listener privado.

O enderezo que o HBA ve realmente

Con acceso encamiñado o servidor ve o enderezo interno do túnel de cada cliente. Con tradución de orixe ve no seu lugar o enderezo traducido da pasarela, e cada cliente colapsa nese único valor. Inspeccione a orixe a través das propias evidencias de conexión do servidor antes de escoller un prefixo que permitir.

Para un despregamento que xa usa TLS e SCRAM, un exemplo deliberadamente estreito de acceso remoto ten 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

Iso permite un rol e unha base de datos sobre TLS desde o pool indicado, e despois rexeita outro acceso TCP remoto. Non substitúe un ficheiro HBA completo: manteña a administración local, a replicación e calquera outro servizo autorizado, e coloque as regras estreitas antes das autorizacións máis amplas.

Cando a tradución está en xogo, o HBA non pode distinguir os clientes polos seus enderezos orixinais. Manteña a admisión de rede axustada e esixa credenciais reais de base de datos, e nunca substitúa a autenticación trust por unha conta real.

Gaña a primeira coincidencia, sen respaldo

PostgreSQL le o ficheiro de arriba abaixo e usa o primeiro rexistro que coincide coa conexión. Non hai un segundo intento se falla a autenticación dese rexistro, así que unha autorización ampla anterior derrota en silencio un rexeitamento posterior.

Esa regra de orde é o motivo máis común polo que un rexeitamento escrito con coidado nunca chega a ter efecto. Pon as regras específicas primeiro e as amplas ao final, e despois le o ficheiro como unha secuencia en lugar de como un conxunto. Unha regra que engadiu ao final non é unha política, é un comentario. Móvaa cara arriba e recargue antes de concluír que o ficheiro se está ignorando.

A referencia de HBA define tanto a orde como a diferenza entre os rexistros host e hostssl, o que importa cando o sentido da regra é que a conexión debe estar cifrada.

Recarga, reinicio e o caso denegado

Os cambios de HBA aplícanse cunha recarga, e a vista pg_hba_file_rules axúdalle a atopar erros de análise. Esa vista describe o contido actual do ficheiro, non se o servidor en execución os cargou correctamente, así que unha listaxe limpa non é proba de que as novas regras estean activas.

Os cambios do listener necesitan o seu propio reinicio, e as dúas operacións confúndense facilmente cando un cambio parece non ter efecto.

Probe con sesións novas: un cliente aprobado coa conta prevista conéctase, a mesma conta desde unha ruta non aprobada non, e unha identidade de base de datos non autorizada segue fallando desde dentro da VPN. Eses tres resultados separan a fronteira de rede da autorización de base de datos, que é todo o sentido de manter as decisións separadas.

Artigos relacionados