Не удается подключиться к PostgreSQL Дистанционно на Amazon экземпляра EC2 с помощью PgAdmin

Question

У меня есть микро свободный ярус RHEL 6 экземпляра, запускаемого и имеют PostgreSQL 9.2 установлен с помощью Yum инструкции здесь: http://yum.pgrpms.org/howtoyum.php

И я могу подключиться к серверу PG локально, используя это на сервере:

03:46:20 root@xxx[~]$ psql -hlocalhost -p5432 -Upostgres 

Однако я никогда не подключался к нему за пределами коробки. Сообщение об ошибке выглядит так:

12:11:56 saladinxu@GoodOldMBP[~]$ psql -h ec2-xxx.ap-southeast-1.compute.amazonaws.com -p5432 -Upostgres 
    psql: could not connect to server: Connection refused 
    Is the server running on host "ec2-54-251-188-3.ap-southeast-1.compute.amazonaws.com" (54.251.188.3) and accepting TCP/IP connections on port 5432? 

Я пробовал кучу разных способов. Вот как мои Сконфигурировать файлы теперь посмотрите:

/var/lib/pgsql/9.2/data/postgresql.conf:

... 

# - Connection Settings - 

listen_addresses = '*'  # what IP address(es) to listen on; 
       # comma-separated list of addresses; 
       # defaults to 'localhost'; use '*' for all 
port = 5432    # (change requires restart) 
max_connections = 100   # (change requires restart) 
... 

/var/lib/pgsql/9.2/data/pg_hba.conf:

# TYPE DATABASE  USER   ADDRESS     METHOD 
host all    pgadmin   0.0.0.0/24    trust 
host all    all    [my ip]/24   md5 
# "local" is for Unix domain socket connections only 
local all    all          peer 
# IPv4 local connections: 
host all    all    127.0.0.1/32   ident 
# IPv6 local connections: 
host all    all    ::1/128     ident 

Я попытался сделать вышеуказанный адрес 0.0.0.0/0, но id не работал.

И каждый раз, когда я сделал изменения я перезапуск, выполнив

service postgresql-9.2 restart 

В группе безопасности данного экземпляра EC2 я могу видеть это правило уже:

TCP 
Port (Service) Source Action 
22 (SSH) 0.0.0.0/0 Delete 
80 (HTTP) 0.0.0.0/0 Delete 
5432 0.0.0.0/0 Delete 

В Netstat команда показывает, что порт уже открыт:

04:07:46 root@ip-172-31-26-139[~]$ netstat -na|grep 5432 
tcp  0  0 0.0.0.0:5432    0.0.0.0:*     LISTEN  
tcp  0  0 :::5432      :::*      LISTEN  
unix 2  [ ACC ]  STREAM  LISTENING  14365 /tmp/.s.PGSQL.5432 

Чтобы ответить на вопрос bma:

При запуске Nmap команды на сервере локально, кажется, предположить, что через внутренний DNS это будет другой хост, где 5432 открыто:

10:16:05 root@ip-172-31-26-139[~]$ nmap -Pnv -p 5432 ec2-54-251-188-3.ap-southeast-1.compute.amazonaws.com 

Starting Nmap 5.51 (http://nmap.org) at 2013-07-22 10:16 EDT 
Nmap scan report for ec2-54-251-188-3.ap-southeast-1.compute.amazonaws.com (172.31.26.139) 
Host is up (0.00012s latency). 
rDNS record for 172.31.26.139: ip-172-31-26-139.ap-southeast-1.compute.internal 
PORT  STATE SERVICE 
5432/tcp open postgresql 

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds 

и команда Iptables дает следующему выводу

10:16:14 root@ip-172-31-26-139[~]$ iptables -nvL 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) 
pkts bytes target  prot opt in  out  source    destination   
25776 14M ACCEPT  all -- *  *  0.0.0.0/0   0.0.0.0/0   state RELATED,ESTABLISHED 
0  0 ACCEPT  icmp -- *  *  0.0.0.0/0   0.0.0.0/0   
45 1801 ACCEPT  all -- lo  *  0.0.0.0/0   0.0.0.0/0   
251 15008 ACCEPT  tcp -- *  *  0.0.0.0/0   0.0.0.0/0   state NEW tcp dpt:22 
35 2016 REJECT  all -- *  *  0.0.0.0/0   0.0.0.0/0   reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) 
pkts bytes target  prot opt in  out  source    destination   
0  0 REJECT  all -- *  *  0.0.0.0/0   0.0.0.0/0   reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT 21695 packets, 5138K bytes) 
pkts bytes target  prot opt in  out  source    destination 

[Отредактировано после добавления в соответствии с предложением БМА]

Iptables выглядит следующим образом после того, как новое дополнение:

11:57:20 root@ip-172-31-26-139[~]$ iptables -nvL 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) 
pkts bytes target  prot opt in  out  source    destination   
26516 14M ACCEPT  all -- *  *  0.0.0.0/0   0.0.0.0/0   state RELATED,ESTABLISHED 
0  0 ACCEPT  icmp -- *  *  0.0.0.0/0   0.0.0.0/0   
47 1885 ACCEPT  all -- lo  *  0.0.0.0/0   0.0.0.0/0   
255 15236 ACCEPT  tcp -- *  *  0.0.0.0/0   0.0.0.0/0   state NEW tcp dpt:22 
38 2208 REJECT  all -- *  *  0.0.0.0/0   0.0.0.0/0   reject-with icmp-host-prohibited 
0  0 ACCEPT  tcp -- *  *  [my ip]   54.251.188.3  tcp spts:1024:65535 dpt:5432 state NEW,ESTABLISHED 
0  0 ACCEPT  tcp -- *  *  0.0.0.0/0   54.251.188.3  tcp spt:5432 dpts:1024:65535 state ESTABLISHED 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) 
pkts bytes target  prot opt in  out  source    destination   
0  0 REJECT  all -- *  *  0.0.0.0/0   0.0.0.0/0   reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT 5 packets, 1124 bytes) 
pkts bytes target  prot opt in  out  source    destination   
0  0 ACCEPT  tcp -- *  *  54.251.188.3   [my ip]  tcp spt:5432 dpts:1024:65535 state ESTABLISHED 
0  0 ACCEPT  tcp -- *  *  54.251.188.3   0.0.0.0/0   tcp spts:1024:65535 dpt:5432 state NEW,ESTABLISHED 

Но я все еще не могу подключиться (та же ошибка). Что может быть недостающим здесь?

Answer 1

У вас есть порт блокировки брандмауэра 5432? Быстрый nmap показывает, что он фильтруется.

nmap -Pnv -p 5432 ec2-54-251-188-3.ap-southeast-1.compute.amazonaws.com 

Starting Nmap 6.00 (http://nmap.org) at 2013-07-21 11:05 PDT 
Nmap scan report for ec2-54-251-188-3.ap-southeast-1.compute.amazonaws.com (54.251.188.3) 
Host is up (0.19s latency). 
PORT  STATE SERVICE 
5432/tcp filtered postgresql 

Что делает iptables на вашем EC2 для порта 5432?

iptables -nvL 

[после OP добавил подробнее]

Netstat показывает, что слушает, но выход брандмауэр не выглядеть 5432 порт открыт (Признаюсь, я не в большей части сети парень). Ссылаясь на некоторые из моих заметок из предыдущих установок, вам может потребоваться открыть EC2-порт 5432 на ваш IP-адрес.

Чтобы разрешить доступ ввода брандмауэра, замените YOUR-REMOTE-IP с IP вы подключаетесь:

iptables -A INPUT -p tcp -s YOUR-REMOTE-IP --sport 1024:65535 -d 54.251.188.3 --dport 5432 -m state --state NEW,ESTABLISHED -j ACCEPT 
iptables -A OUTPUT -p tcp -s 54.251.188.3 --sport 5432 -d YOUR-REMOTE-IP --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT 

--outbound доступ

iptables -A OUTPUT -p tcp -s 54.251.188.3 --sport 1024:65535 -d 0/0 --dport 5432 -m state --state NEW,ESTABLISHED -j ACCEPT 
iptables -A INPUT -p tcp -s 0/0 --sport 5432 -d 54.251.188.3 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT 

Что iptables -nvL список после этого. Можете ли вы подключиться?

Answer 2

Я нашел решение этой проблемы. Требуются две вещи.

1. Используйте текстовый редактор, чтобы изменить pg_hba.conf. Найдите хост линии все все 127.0.0.1/0 md5. Сразу под ним, добавить новую строку: размещаем все все 0.0.0.0/0 md5

2. Редактирование postgresql.conf файла PostgreSQL:

   Используйте текстовый редактор для изменения postgresql.conf. Найдите строку, начинающуюся с #listen_addresses = 'localhost'. Раскомментируйте строку, удалив #, и измените localhost на . Линия теперь должна выглядеть так: listen_addresses = '' # какой IP-адрес для прослушивания ;.

Теперь Просто перезапустите службу Postgres, и он будет иметь возможность подключиться

Answer 3

кажется ваш pg_hba.conf не попадает в «+» после названия группы. попробуйте

# TYPE DATABASE USER ADDRESS METHOD host all pgadmin+ 0.0.0.0/24 trust host all all [my ip]/24 md5

pg_hba.conf объясняет о пользователе:

значение все указывает на то, что она соответствует всем пользователям. В противном случае это либо имя конкретного пользователя базы данных, либо имя группы, которому предшествует +. (Напомним, что нет никакого реального различия между пользователями и группами в PostgreSQL, знак + действительно означает «соответствовать любой из ролей, которые прямо или косвенно являются членами этой роли», а имя без знака + соответствует только этой конкретной роли.)