Удаленный доступ к базе данных postgresql с FDW [решена]

Question 1

У меня есть два сервера, размещенных в разных местах, с Postgresql.

Я хочу получить доступ к данным Postgresql с сервера 1 (CentOS 7), путем postgresql FDW с сервера 2 (Ubuntu 16).

Проблема:

psql: could not connect to server: Connection refused Is the server running on host "xxx.xxx.xxx.xxx" and accepting TCP/IP connections on port 5432?

Я отредактировал файл postgresql.conf с listenaddresses='*' и оба файла pghba.conf с помощью host all all 0.0.0.0/0 md5

все еще не работает, поэтому я подумал, что это может быть вызвано iptables. Я добавляю эти правила:

iptables -A INPUT -p tcp -m tcp --dport 5432 -j ACCEPT iptables -A OUTPUT -p tcp -m tcp --dport 5432 -j ACCEPT

Все еще не работает.

Спасибо вам!

(извините за мой английский)

Question 2

С точки зрения сети, сервер 2 является клиентом, а сервер 1 - сервером. Операционная система клиента сообщает, что Connection отказалась при попытке подключения к xxx.xxx.xxx.xxx:5432.

Обычно эта ошибка не связана с брандмауэром, поскольку брандмауэры имеют тенденцию отбрасывать пакеты, которые производят Соединение отклонено .

Это также не связано с ошибкой аутентификации на основе хоста postgres, поскольку они создают совершенно разные и конкретные сообщения об ошибках.

Несколько правдоподобных причины:

PostgreSQL действительно не прослушивает порт 5432 на сервере 1. Это может быть подтверждено командой netstat -tlnp | grep 5432 запуститься как root. Обратите внимание, что параметр конфигурации listen_addresses, а не listenaddresses. Кроме того, после этого изменения необходимо перезапустить postgres. Вы можете посмотреть журналы журналов postgres, чтобы подтвердить, что они сработали, или проверить причину, почему это не так. Конфигурация сети такова, что сервер 1 не может быть достигнут с сервера 2 с адресом xxx.xxx.xxx.xxx. Пакеты маршрутизируются в другом месте, в сетевом интерфейсе, где 5432 как порт TCP не привязан к службе. Например, если сервер 1 виртуализирован, ожидается, что он не может быть достигнут непосредственно через адрес его хоста.

Question 3

Question 4

С точки зрения сети, сервер 2 является клиентом, а сервер 1 - сервером. Операционная система клиента сообщает, что Connection отказалась при попытке подключения к xxx.xxx.xxx.xxx:5432.

Обычно эта ошибка не связана с брандмауэром, поскольку брандмауэры имеют тенденцию отбрасывать пакеты, которые производят Соединение отклонено .

Это также не связано с ошибкой аутентификации на основе хоста postgres, поскольку они создают совершенно разные и конкретные сообщения об ошибках.

Несколько правдоподобных причины:

PostgreSQL действительно не прослушивает порт 5432 на сервере 1. Это может быть подтверждено командой netstat -tlnp | grep 5432 запуститься как root. Обратите внимание, что параметр конфигурации listen_addresses, а не listenaddresses. Кроме того, после этого изменения необходимо перезапустить postgres. Вы можете посмотреть журналы журналов postgres, чтобы подтвердить, что они сработали, или проверить причину, почему это не так. Конфигурация сети такова, что сервер 1 не может быть достигнут с сервера 2 с адресом xxx.xxx.xxx.xxx. Пакеты маршрутизируются в другом месте, в сетевом интерфейсе, где 5432 как порт TCP не привязан к службе. Например, если сервер 1 виртуализирован, ожидается, что он не может быть достигнут непосредственно через адрес его хоста.

Daniel Vérité · Answer 1 · 17 July 2018 в 21:23

С точки зрения сети, сервер 2 является клиентом, а сервер 1 - сервером. Операционная система клиента сообщает, что Connection отказалась при попытке подключения к xxx.xxx.xxx.xxx:5432.

Обычно эта ошибка не связана с брандмауэром, поскольку брандмауэры имеют тенденцию отбрасывать пакеты, которые производят Соединение отклонено .

Это также не связано с ошибкой аутентификации на основе хоста postgres, поскольку они создают совершенно разные и конкретные сообщения об ошибках.

Несколько правдоподобных причины:

PostgreSQL действительно не прослушивает порт 5432 на сервере 1. Это может быть подтверждено командой netstat -tlnp | grep 5432 запуститься как root. Обратите внимание, что параметр конфигурации listen_addresses, а не listenaddresses. Кроме того, после этого изменения необходимо перезапустить postgres. Вы можете посмотреть журналы журналов postgres, чтобы подтвердить, что они сработали, или проверить причину, почему это не так. Конфигурация сети такова, что сервер 1 не может быть достигнут с сервера 2 с адресом xxx.xxx.xxx.xxx. Пакеты маршрутизируются в другом месте, в сетевом интерфейсе, где 5432 как порт TCP не привязан к службе. Например, если сервер 1 виртуализирован, ожидается, что он не может быть достигнут непосредственно через адрес его хоста.

Daniel Vérité · Answer 2 · 23 July 2018 в 22:01

С точки зрения сети, сервер 2 является клиентом, а сервер 1 - сервером. Операционная система клиента сообщает, что Connection отказалась при попытке подключения к xxx.xxx.xxx.xxx:5432.

Обычно эта ошибка не связана с брандмауэром, поскольку брандмауэры имеют тенденцию отбрасывать пакеты, которые производят Соединение отклонено .

Это также не связано с ошибкой аутентификации на основе хоста postgres, поскольку они создают совершенно разные и конкретные сообщения об ошибках.

Несколько правдоподобных причины:

PostgreSQL действительно не прослушивает порт 5432 на сервере 1. Это может быть подтверждено командой netstat -tlnp | grep 5432 запуститься как root. Обратите внимание, что параметр конфигурации listen_addresses, а не listenaddresses. Кроме того, после этого изменения необходимо перезапустить postgres. Вы можете посмотреть журналы журналов postgres, чтобы подтвердить, что они сработали, или проверить причину, почему это не так. Конфигурация сети такова, что сервер 1 не может быть достигнут с сервера 2 с адресом xxx.xxx.xxx.xxx. Пакеты маршрутизируются в другом месте, в сетевом интерфейсе, где 5432 как порт TCP не привязан к службе. Например, если сервер 1 виртуализирован, ожидается, что он не может быть достигнут непосредственно через адрес его хоста.

PostgreSQL прослушивает порт 5432, он работает и, конечно же, перезагружен. (Да, я имел в виду listen_adresses, а не listenadresses. К сожалению ...) Очевидно, что сервер 2 является клиентом с точки зрения сети. Спасибо ! Все, что было необходимо: чтобы клиент мог подключиться к серверу. Я добавил правило для iptables, и он работает: -A INPUT -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 5432 -j ACCEPT Большое спасибо за вашу помощь! — Splendens, 9 February 2018 в 19:55
@Splendens: приятно слышать, что он решен, но это правило iptable выглядит так, как будто оно ничего не должно меняться по сравнению с INPUT -p tcp -m tcp --dport 5432 -j ACCEPT, упомянутым в вопросе. — Daniel Vérité, 9 February 2018 в 20:33
На самом деле, я добавил это правило (INPUT -p tcp -m tcp --dport 5432 -j ACCEPT) на сервере 2, сначала для удаленного подключения к pgadmin, и я забыл добавить правила для сервера. 1. Ваш ответ заставил меня осознать мое очевидное упущение. — Splendens, 9 February 2018 в 21:58

Удаленный доступ к базе данных postgresql с FDW [решена]

2 ответа

Другие вопросы по тегам:

Похожие вопросы: