nie można połączyć się z PostgreSQL Zdalnie na Amazon instancji EC2 przy użyciu pgAdmin

Question

Mam mikro wolnego Poziom RHEL 6 instancji działa i mieć PostgreSQL 9.2 zainstalowany przy użyciu instrukcji yum tutaj: http://yum.pgrpms.org/howtoyum.php

i jestem w stanie połączyć się z serwerem PG lokalnie używają tego na serwerze:

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

Jednak nigdy nie udało mi się z nim połączyć po wyjęciu z pudełka. Komunikat o błędzie wygląda następująco:

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? 

Próbowałem różnych sposobów. Oto jak wyglądają moje pliki Skonfiguruj teraz:

/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 

Próbowałem wprowadzić powyższy adres na adres 0.0.0.0/0, ale identyfikator nie zadziałał.

I za każdym razem, gdy dokonane zmiany i wznowiona przez uruchomienie tej

service postgresql-9.2 restart 

W Grupie Bezpieczeństwa tej instancji EC2 widzę tę zasadę już:

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 podaje komunikat, że port jest już otwarty:

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 

Aby odpowiedzieć na pytanie bmy:

Jeśli uruchomić polecenie nmap na serwerze lokalnie wydaje się sugerować, że thru wewnętrznego DNS to jedzie do innego hosta, gdzie 5432 jest otwarty:

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 

i polecenia iptables daje następujący wynik

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 

[Edytowane po dodaniu zgodnie z sugestią BMA'S]

iptables wygląda tak po nowym Ponadto:

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 

Ale nadal nie mogę się połączyć (ten sam błąd). Jaki może być brakujący element tutaj?

Answer 1

Czy masz port blokujący zaporę ogniową 5432? Szybki nmap pokazuje, że jest filtrowany.

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 

Co pokazuje iptables na twoim EC2 dla portu 5432?

iptables -nvL 

[OP dodaje po więcej szczegółów]

Netstat pokazuje, że słucha, ale wyjście zapora nie wyglądać Port 5432 jest otwarty (Przyznaję, nie jest dużo faceta sieci). Nawiązując do niektórych moich uwag z poprzednich instalacji, może być konieczne otwarcie portu EC2 5432 na adres IP.

Aby umożliwić dostęp zapory wejście, wymień-remote-IP z IP łączysz z:

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 dostęp

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 

Co iptables -nvL listy po tym. Czy możesz się połączyć?

Answer 2

Znalazłem rozwiązanie tego problemu. Dwie rzeczy są wymagane.

1. Użyj edytora tekstu, aby zmodyfikować pg_hba.conf. Znajdź host linii wszystkie 127.0.0.1/0 md5. Bezpośrednio pod nią dodaj nową linię: host Wszystkie 0.0.0.0/0 md5

2. Edycja pliku postgresql.conf PostgreSQL:

   użyć edytora tekstu do modyfikowania postgresql.conf. Znajdź wiersz rozpoczynający się od #listen_addresses = 'localhost'. Odkomentuj linię, usuwając znak # i zmień wartość localhost na . Linia powinna teraz wyglądać następująco: listen_addresses = '' # jakie adresy IP, na których chcesz nasłuchiwać ;.

Teraz wystarczy ponownie uruchomić usługę postgres'owy i będzie w stanie połączyć

Answer 3

Wygląda Twój pg_hba.conf strzela „+” po nazwie grupy. spróbuj

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

pg_hba.conf wyjaśnia o użytkowniku:

Wartość wszystko wskazuje, że to pasuje do wszystkich użytkowników. W przeciwnym razie jest to nazwa konkretnego użytkownika bazy danych lub nazwa grupy poprzedzona znakiem +. (Przypomnijmy, że nie ma prawdziwego rozróżnienia między użytkownikami i grupami w PostgreSQL; znak + naprawdę oznacza "dopasowanie dowolnej z ról, które są bezpośrednio lub pośrednio członkami tej roli", podczas gdy nazwa bez znaku + pasuje tylko do tej konkretnej roli.)