Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
voici ma config : pg 15.8 sur debian 12
Jusqu'à présent toutes les connexions se faisaient en local soit par les appli installées sur le serveur soit via un tunnel SSH. Mes connexions sur dbeawer se font parfaitement avec le tunnel.
J'ai besoin maintenant d'ouvrir une base de donnée à des connexions distantes. J'ai donc effectué les modifs suivantes :
- dans postgresql.conf : listen_addresses = '*'
- dans pg_hba.conf :
host all ma_base 0.0.0.0/0 scram-sha-256
D'ailleurs voici le fichier complet :
local all postgres peer
local all all peer
host all all 127.0.0.1/32 scram-sha-256
host all all ::1/128 scram-sha-256
host all ma_base 0.0.0.0/0 scram-sha-256
local replication all peer
host replication all 127.0.0.1/32 scram-sha-256
host replication all ::1/128 scram-sha-256
- J'ai ouvert le port dans iptables (iptables -A INPUT -p tcp --dport 5432 -j ACCEPT)
résultat:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5432
- J'ai vérifié qu'il n'y ait pas d'autre pare-feu actif
- J'ai bien sûr redémarrer le service postgresql (systemctl restart postgresql)
J'essaye de me connecter via différents outils en direct à l'ip de mon serveur (port 5432) sur ma_base mais sans succès. La même connexion en localhost via le tunnel ssh se fait sans problème. C'est donc bien ma connexion tcp qui bloque quelque part.
Je veux bien des pistes pour identifier le souci 
Merci d'avance
Dernière modification par dba-sig-sfepm (26/08/2024 08:58:26)
Hors ligne
Avez-vous verefie que "SHOW listen_adresses;" renvoie bien * apres le redemarrage de postgres ?
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
merci de votre réponse ! Alors sous psql la commande "SHOW listen_addresses;" me renvoie bien *
et "netstat -nlt | grep 5432" me donne bien :
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN
tcp6 0 0 :::5432 :::* LISTEN
Donc de ce coté, pas de soucis.
Hors ligne
Je pensais avoir trouvé la solution en constatant mon erreur dans la config hba (inversion base / utilisateur), il fallait mettre :
host ma_base all 0.0.0.0/0 scram-sha-256
Mais non, le problème est toujours là 
. En attendant j'ai mis all / all pour être sûr)
Hors ligne
Le message d'erreur cote client devrait donner un indice sur le type d'erreur (port non joignable vs pb d'authentification / role non trouve), il serait d'ailleurs bon de preciser egalement la commande utilisee. Pareil, les logs du serveur devrait indiquer si une connexion a ete recue ou non.
Vous pouvez egalement essayer a coup de wireshark ou remplacer postgres par un daemon quelconque ecoutant sur le meme port, et/ou remplacer psql par n'importe quel outil ouvrant une connexion tcp sur le meme port pour vous assurer que le probleme vient de postgres plut[ot que du reseau.
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour les pistes. En effet le pb ne vient pas de postgres : j'ai testé la connexion via psql depuis d'autres serveurs (psql -h ip_de_l'hôte -p 5432 -d ma_base -U user -W) et la connexion se fait très bien. C'est vrai j'aurais du commencer par là... mais j'étais focalisé sur les outils. Par contre toujours impossible de connecter un pgAdmin ou un dbeawer, la seule erreur que j'obtient est un timeout expired et rien dans le log de postgres.
Hors ligne
L'étau se resserre un petit peu : un telnet sur le port 5432 permet la connexion depuis d'autre vps mais pas depuis chez moi (ni depuis windows, ni depuis linux, que ce soit en passant par la box ou par la 4g). Avec nmap je détecte bien les port 80 et 22 mais le 5432 reste invisible et inaccessible. Bon je crois que l'on sort de l'objet de ce forum là, postgresql n'est plus en cause je pense. Je vais continué à investiguer... Merci pour votre aide.
Hors ligne
Bon, j'ai un peu honte mais j'ai trouvé la cause de tous mes souci. Ce qui m'a mis la puce à l'oreille est que les connexions distantes ne fonctionnaient que depuis des serveurs ovh. Et là je me suis rappelé !!!! quand j'avais installé mon vps je m'était dis que le Edge Network Firewall était une bonne idée et comme à l'époque je ne voulais pas qu'on puisse se connecter de l'extérieur je n'avais bien sur pas ouvert l'accès au port 5432. Ce pare-feu ne s'appliquant qu'aux portes d'OVH, ceci explique cela 
La sécurité c'est bien aussi faut-il bien tout consigner !!!
Hors ligne
Pages : 1
