PostgreSQL nie przyjmuje połączeń z sieci - listen_addresses

PostgreSQL

W skrócie

Problem: lokalnie baza działa, ale z innej maszyny połączenie nie przechodzi - serwer nie nasłuchuje na adresie sieciowym.
Dlaczego: domyślnie listen_addresses = 'localhost', więc serwer otwiera gniazdo tylko na pętli zwrotnej i jest niewidoczny z sieci.
Rozwiązanie: ustawiamy listen_addresses na właściwy interfejs, restartujemy serwer i dopiero wtedy dodajemy regułę w pg_hba.conf.

To jedna z najczęstszych pułapek przy pierwszym wystawianiu bazy do sieci. Wszystko działa na serwerze, ale aplikacja z innej maszyny nie może się połączyć. Winny jest parametr listen_addresses, który decyduje, na których interfejsach sieciowych serwer w ogóle otwiera gniazdo nasłuchu. Dotyczy Cię to zawsze, gdy baza i aplikacja stoją na różnych maszynach albo w różnych kontenerach. Pokazujemy, jak ustawić to poprawnie i bezpiecznie.

Jak to wygląda w praktyce

Na serwerze wszystko działa, a z innej maszyny dostajesz odmowę połączenia:

$ psql -h 10.0.0.12 -U app -d sklep
psql: error: connection to server at "10.0.0.12", port 5432 failed: Connection refused

Gdy sprawdzisz na serwerze, co faktycznie nasłuchuje, widać sedno problemu - gniazdo jest tylko na adresie pętli zwrotnej:

$ sudo ss -ltnp | grep 5432
LISTEN 0  244  127.0.0.1:5432  0.0.0.0:*  users:(("postgres",pid=811,fd=6))

Brak wiersza z adresem interfejsu sieciowego (na przykład 10.0.0.12:5432 albo 0.0.0.0:5432) oznacza, że serwer po prostu nie słucha ruchu z zewnątrz.

Dlaczego tak się dzieje

listen_addresses to parametr z postgresql.conf, który mówi serwerowi, na których adresach IP ma otworzyć gniazda nasłuchu przy starcie. Domyślna wartość to 'localhost', czyli tylko 127.0.0.1 oraz ::1 - świadomy wybór twórców, aby świeżo zainstalowana baza nie była od razu dostępna z sieci. Dopóki nie zmienisz tego parametru, żaden wpis w pg_hba.conf nie pomoże, bo serwer nawet nie odbiera pakietów z sieci. Wartość '*' otwiera nasłuch na wszystkich interfejsach, a można też podać konkretne adresy po przecinku, na przykład 'localhost,10.0.0.12' - to bezpieczniejsze, bo ogranicza nasłuch do wybranej sieci.

Jak to rozwiązać krok po kroku

Otwórz postgresql.conf (ścieżkę pokaże SHOW config_file;) i ustaw nasłuch na właściwym adresie, na przykład listen_addresses = '10.0.0.12' albo '*' dla wszystkich interfejsów.
Zapisz plik i zrestartuj serwer - to zmiana wymagająca restartu, sam reload nie otworzy nowych gniazd: sudo systemctl restart postgresql.
Potwierdź, że serwer nasłuchuje na adresie sieciowym: sudo ss -ltnp | grep 5432 - teraz powinien pojawić się wpis z adresem interfejsu.
Dodaj regułę dostępu w pg_hba.conf dla podsieci klienta, na przykład host sklep app 10.0.0.0/24 scram-sha-256, i przeładuj: SELECT pg_reload_conf();.
Otwórz port 5432 w zaporze, jeśli jest aktywna: sudo ufw allow from 10.0.0.0/24 to any port 5432 proto tcp.
Nie zostawiaj listen_addresses = '*' bez zabezpieczeń - w połączeniu z otwartą zaporą wystawia bazę szeroko. Ogranicz albo adres nasłuchu, albo dostęp na zaporze do zaufanej sieci.

Jak sprawdzić, że zadziałało

Sprawdź aktualną wartość parametru w działającym serwerze - powinna odpowiadać temu, co ustawiłeś:

$ sudo -u postgres psql -c "SHOW listen_addresses;"
 listen_addresses
------------------
 10.0.0.12

Następnie z maszyny klienta zweryfikuj, że połączenie faktycznie przechodzi - jeśli serwer poprosi o hasło, nasłuch i dostęp działają:

$ psql -h 10.0.0.12 -U app -d sklep

Poczytaj więcej
Lekcja z kursu PostgreSQL na ten temat
Cały bezpłatny kurs administracji PostgreSQL

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Autorzy

Tekst: Redakcja JSystems

Najczęściej zadawane pytania

Co dokładnie robi parametr listen_addresses?

Określa, na których adresach IP serwer PostgreSQL otwiera gniazda nasłuchu przy starcie. Domyślnie ma wartość localhost, więc przyjmuje połączenia tylko z tej samej maszyny. Ustawienie na konkretny adres lub gwiazdkę sprawia, że serwer zaczyna nasłuchiwać na interfejsach sieciowych i dopiero wtedy klienci z innych maszyn mogą się w ogóle połączyć.

Dlaczego samo dodanie reguły w pg_hba.conf nie wystarcza, by połączyć się z sieci?

Bo pg_hba.conf decyduje o dostępie dopiero po tym, jak serwer odbierze pakiet. Jeśli listen_addresses ma wartość localhost, serwer nie nasłuchuje na adresie sieciowym i pakiet z innej maszyny w ogóle do niego nie dociera. Najpierw trzeba otworzyć nasłuch przez listen_addresses i zrestartować serwer, a dopiero potem reguła z pg_hba.conf zaczyna mieć znaczenie.

Czy ustawienie listen_addresses na gwiazdkę jest bezpieczne?

Sama gwiazdka tylko otwiera nasłuch na wszystkich interfejsach - nie pomija haseł ani reguł dostępu. Ryzyko pojawia się w połączeniu z otwartą zaporą i luźnymi wpisami w pg_hba.conf. Bezpieczniej jest podać konkretny adres interfejsu albo ograniczyć dostęp na zaporze do zaufanej podsieci, zamiast wystawiać port 5432 na cały świat.

Dlaczego zmiana listen_addresses wymaga restartu, a nie reload?

Bo gniazda nasłuchu serwer otwiera tylko podczas startu procesu. Reload przeładowuje pliki konfiguracyjne dla już działającego serwera, ale nie zamyka i nie otwiera na nowo gniazd sieciowych. Dlatego po zmianie listen_addresses trzeba wykonać pełny restart klastra i dopiero wtedy serwer zacznie nasłuchiwać na nowych adresach.