PostgreSQL per VPN: quina adreça d’origen veurà pg_hba

PostgreSQL no sap mai que un client és en una VPN. Rep una connexió TCP des d’una adreça i un conjunt de credencials, i decideix què fer-ne. Per tant, fer que l’accés depengui del túnel significa ordenar tres decisions separades perquè coincideixin, i després comprovar l’única adreça que el servidor veu realment en lloc de la que heu dibuixat al diagrama.

Tres decisions que no s’han de fusionar

On escolta el servidor és una decisió. Quin trànsit pot arribar a aquesta adreça és una segona, presa pel tallafoc de l’amfitrió i qualsevol frontera de xarxa davant seu. Quina identitat de base de dades pot autenticar-se des de quin origen és una tercera, presa a pg_hba.conf.

Cada una és aplicada per un component diferent, i cada una falla amb un missatge diferent. Fusionar-les en una discussió és com la gent acaba editant el fitxer HBA per arreglar un problema de tallafoc. Manteniu-les en ordre: un listener que no està lligat no es pot assolir, a un port filtrat no s’hi pot connectar, i una regla HBA només decideix què passa quan ja existeix una connexió. Quan un canvi no té efecte, identifiqueu quina de les tres capes heu canviat realment.

On escolta el servidor

Lligueu-vos a una adreça que estigui realment assignada a la màquina, no a un nom d’interfície:

listen_addresses = '10.20.0.30'

La base de dades pot estar darrere de la passarel·la VPN sense cap interfície de túnel pròpia, i és exactament per això que una adreça és el que cal nomenar. Canviar aquest paràmetre requereix un reinici complet; una recàrrega no n’hi ha prou.

Després filtreu el port, normalment 5432, a l’amfitrió i a cada frontera davant seu. Lligar-se a una adreça privada no és prova de denegació pública, perquè una redirecció de port o un mapatge d’adreça al núvol encara pot lliurar paquets a aquest listener privat.

L’adreça que l’HBA veu realment

Amb accés encaminat el servidor veu l’adreça interna del túnel de cada client. Amb traducció d’origen veu, en canvi, l’adreça traduïda de la passarel·la, i cada client es col·lapsa en aquest únic valor. Inspeccioneu l’origen a través de les pròpies evidències de connexió del servidor abans de triar un prefix a permetre.

Per a un desplegament que ja fa servir TLS i SCRAM, un exemple d’accés remot deliberadament estret és aquest:

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

Això permet un rol i una base de dades sobre TLS des del pool indicat, i després rebutja altres accessos TCP remots. No substitueix un fitxer HBA complet: manteniu l’administració local, la replicació i qualsevol altre servei autoritzat, i poseu les regles estretes abans de les autoritzacions més àmplies.

Quan la traducció hi és, l’HBA no pot distingir els clients per les seves adreces originals. Manteniu l’admissió de xarxa estreta i exigiu credencials reals de base de dades, i no substituïu mai l’autenticació trust per un compte real.

Guanya la primera coincidència, sense alternativa

PostgreSQL llegeix el fitxer de dalt a baix i utilitza el primer registre que coincideix amb la connexió. No hi ha un segon intent si l’autenticació d’aquell registre falla, així que una autorització àmplia anterior derrota silenciosament una denegació posterior.

Aquesta regla d’ordre és el motiu més comú pel qual una denegació escrita amb cura no arriba a tenir efecte. Poseu les regles específiques primer i les àmplies al final, i després llegiu el fitxer com una seqüència i no com un conjunt. Una regla que heu afegit al final no és una política, és un comentari. Moveu-la amunt i recarregueu abans de concloure que el fitxer s’ignora.

La referència HBA defineix tant l’ordre com la diferència entre els registres host i hostssl, cosa que importa quan el sentit de la regla és que la connexió ha d’anar xifrada.

Recàrrega, reinici i el cas denegat

Els canvis HBA s’apliquen amb una recàrrega, i la vista pg_hba_file_rules us ajuda a trobar errors d’anàlisi. Aquesta vista descriu el contingut actual del fitxer, no si el servidor en execució els ha carregat correctament, així que un llistat net no és prova que les noves regles estiguin actives.

Els canvis al listener necessiten el seu propi reinici, i les dues operacions es confonen fàcilment quan un canvi sembla no tenir efecte.

Proveu amb sessions noves: un client aprovat amb el compte previst es connecta, el mateix compte des d’un camí no aprovat no ho fa, i una identitat de base de dades no autoritzada encara falla des de dins de la VPN. Aquests tres resultats separen la frontera de xarxa de l’autorització de base de dades, que és tot el sentit de mantenir les decisions separades.