PostgreSQL via un VPN : quelle adresse source pg_hba verra

PostgreSQL n’apprend jamais qu’un client est sur un VPN. Il reçoit une connexion TCP depuis une adresse et un ensemble d’identifiants, et décide quoi en faire. Faire dépendre l’accès du tunnel signifie donc agencer trois décisions distinctes pour qu’elles concordent, puis vérifier l’unique adresse que le serveur voit réellement plutôt que celle que vous avez dessinée sur le schéma.

Trois décisions qui ne doivent pas fusionner

L’endroit où le serveur écoute est une décision. Le trafic qui peut atteindre cette adresse en est une deuxième, prise par le pare-feu de l’hôte et toute frontière réseau devant lui. L’identité de base de données qui peut s’authentifier depuis quelle source en est une troisième, prise dans pg_hba.conf.

Chacune est appliquée par un composant différent, et chacune échoue avec un message différent. Les fusionner dans une discussion, c’est ainsi que les gens finissent par modifier le fichier HBA pour corriger un problème de pare-feu. Gardez-les dans l’ordre : un écouteur non lié ne peut pas être atteint, un port filtré ne peut pas être joint, et une règle HBA ne décide que de ce qui se passe après qu’une connexion existe. Quand un changement n’a aucun effet, identifiez laquelle des trois couches vous avez réellement modifiée.

Où le serveur écoute

Liez-vous à une adresse réellement attribuée à la machine, pas à un nom d’interface :

listen_addresses = '10.20.0.30'

La base de données peut se trouver derrière la passerelle VPN sans interface de tunnel propre, et c’est précisément pourquoi une adresse est la bonne chose à nommer. Modifier ce réglage exige un redémarrage complet ; un rechargement ne suffit pas.

Filtrez ensuite le port, normalement 5432, sur l’hôte et à chaque frontière devant lui. Se lier à une adresse privée n’est pas une preuve de refus public, car une redirection de port ou un mappage d’adresse cloud peut encore livrer des paquets à cet écouteur privé.

L’adresse que le HBA voit réellement

Avec un accès routé, le serveur voit l’adresse de tunnel interne de chaque client. Avec une traduction de source, il voit à la place l’adresse traduite de la passerelle, et chaque client s’effondre en cette valeur unique. Inspectez la source à travers les propres preuves de connexion du serveur avant de choisir un préfixe à autoriser.

Pour un déploiement qui utilise déjà TLS et SCRAM, un exemple d’accès distant délibérément étroit ressemble à ceci :

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

Cela autorise un rôle et une base de données sur TLS depuis le pool indiqué, puis refuse les autres accès TCP distants. Ce n’est pas un remplacement d’un fichier HBA complet : conservez l’administration locale, la réplication et tout autre service autorisé, et placez les règles étroites avant les autorisations plus larges.

Quand la traduction est en jeu, le HBA ne peut pas distinguer les clients par leurs adresses d’origine. Maintenez l’admission réseau stricte et exigez de véritables identifiants de base de données, et ne remplacez jamais l’authentification trust par un compte réel.

La première correspondance l’emporte, sans recours

PostgreSQL lit le fichier de haut en bas et utilise le premier enregistrement qui correspond à la connexion. Il n’y a pas de seconde tentative si l’authentification de cet enregistrement échoue, donc une autorisation large antérieure défait silencieusement un refus ultérieur.

Cette règle d’ordre est la raison la plus courante pour laquelle un refus soigneusement rédigé ne prend jamais effet. Placez les règles spécifiques d’abord et les larges en dernier, puis lisez le fichier comme une séquence plutôt que comme un ensemble. Une règle ajoutée en bas n’est pas une politique, c’est un commentaire. Remontez-la et rechargez avant de conclure que le fichier est ignoré.

La référence HBA définit à la fois l’ordre et la différence entre les enregistrements host et hostssl, ce qui compte lorsque l’intérêt de la règle est que la connexion doit être chiffrée.

Rechargement, redémarrage et le cas refusé

Les changements HBA sont appliqués par un rechargement, et la vue pg_hba_file_rules vous aide à trouver les erreurs d’analyse. Cette vue décrit le contenu actuel du fichier, pas si le serveur en cours d’exécution les a chargés avec succès, donc une liste propre n’est pas la preuve que les nouvelles règles sont actives.

Les changements de l’écouteur nécessitent leur propre redémarrage, et les deux opérations sont faciles à confondre quand un changement semble sans effet.

Testez avec des sessions neuves : un client approuvé avec le compte prévu se connecte, le même compte depuis un chemin non approuvé non, et une identité de base de données non autorisée échoue toujours depuis l’intérieur du VPN. Ces trois résultats séparent la frontière réseau de l’autorisation de base de données, ce qui est tout l’intérêt de garder les décisions distinctes.