[ PostgreSQL ] 데이터 베이스 연결시 네트워크 확인하기

클라이언트에서 PostgreSQL 서버에 처음 접속하는 상황에서, 다음 항목들을 순차적으로 점검하면 연결 상태를 정확히 파악할 수 있습니다. 아래는 체크리스트와 각 단계에서 사용하는 명령어들입니다.

---

1. 서버까지 경로가 열려 있는지 확인 (네트워크 연결 확인)

🔹 ping 명령어로 서버 IP 확인

ping <서버_IP>

• 예: ping 192.168.1.100
• 응답이 오면 IP 레벨에서는 접근 가능

🔹 traceroute (Linux/macOS) 또는 tracert (Windows)로 경로 확인

traceroute <서버_IP>    # Linux/macOS
tracert <서버_IP>       # Windows

• 경로 상 어디에서 패킷이 차단되는지 확인 가능

---

2. 서버의 포트가 열려 있는지 확인

PostgreSQL의 기본 포트는 5432입니다.

🔹 클라이언트에서 telnet 또는 nc (netcat) 사용

방법 A: telnet 사용

telnet <서버_IP> 5432

• 연결에 성공하면 커서가 깜빡이며 입력 대기 상태가 됨.
• 연결 실패 시 "Connection refused" 또는 timeout 에러 발생

방법 B: nc (netcat) 사용

nc -zv <서버_IP> 5432

• 출력 예시: Connection to <서버_IP> 5432 port [tcp/postgresql] succeeded!

---

3. 서버 측에서 포트가 열려 있고 수신 대기 중인지 확인

🔹 서버에서 PostgreSQL이 해당 포트에서 listen 중인지 확인

sudo netstat -tnlp | grep 5432
# 또는
sudo ss -tnlp | grep 5432

• 출력 예시:
• LISTEN 0 128 0.0.0.0:5432 0.0.0.0:* users:(("postgres",pid=1234,fd=5))
• 0.0.0.0이면 모든 IP에서 접속 가능
• 127.0.0.1이면 로컬에서만 접속 가능 (수정 필요)

🔹 PostgreSQL 설정 확인

postgresql.conf 설정

listen_addresses = '*'    # 또는 서버 IP
port = 5432

pg_hba.conf 설정

host    all             all             0.0.0.0/0               md5

설정 변경 후에는 PostgreSQL을 재시작해야 적용됩니다.

sudo systemctl restart postgresql
# 또는
sudo service postgresql restart

---

4. 서버에 TCP 연결 요청이 들어오는지 실시간으로 확인

🔹 tcpdump로 5432 포트에 대한 패킷 수신 확인

sudo tcpdump -i any port 5432

• 클라이언트에서 접속 시도하면 TCP SYN 등의 패킷이 잡혀야 함
• 아무 것도 안 보이면 방화벽, 라우팅, 보안 그룹 문제 가능성 있음

---

5. PostgreSQL 접속 테스트

클라이언트에서 실제 접속 시도:

psql -h <서버_IP> -U <사용자> -d <DB명>

---

6. 추가 점검: 방화벽

🔹 서버 방화벽 확인 (예: ufw, firewalld)

sudo ufw status       # Ubuntu
sudo firewall-cmd --list-all   # CentOS, RHEL

🔹 포트 열기 (예: Ubuntu)

sudo ufw allow 5432/tcp

 

---

 

7. Port 가 닫혀 있거나 방화벽에 막혀 있는 경우

TCP 연결 과정에서 tcpdump로 확인할 수 있는 패킷의 흐름은 포트가 열려 있는 경우와 닫혀 있거나 방화벽으로 막혀 있는 경우에 따라 다릅니다. 아래는 각각의 경우에 tcpdump로 캡처할 수 있는 TCP 3-way handshake 또는 에러 응답 패킷의 예시입니다.

---

1. 사용 명령어 예시

sudo tcpdump -i any port 5432 -nn

• -i any: 모든 인터페이스 감시
• -nn: 포트 번호 및 IP 주소를 그대로 표시
• port 5432: PostgreSQL 포트만 필터링

---

2. 정상적으로 포트가 열려 있고 연결이 되는 경우

TCP 3-Way Handshake

클라이언트 -> 서버 : SYN
서버 -> 클라이언트 : SYN, ACK
클라이언트 -> 서버 : ACK

📦 예시 패킷 (tcpdump 출력)

12:00:00.123456 IP 192.168.1.50.54321 > 192.168.1.100.5432: Flags [S], seq 123456, win 64240, options [...], length 0
12:00:00.123789 IP 192.168.1.100.5432 > 192.168.1.50.54321: Flags [S.], seq 654321, ack 123457, win 65160, options [...], length 0
12:00:00.124000 IP 192.168.1.50.54321 > 192.168.1.100.5432: Flags [ACK], ack 654322, win 64240, length 0

이후 PostgreSQL 프로토콜을 통한 데이터 교환이 시작됨

---

3. 서버의 포트가 닫혀 있거나 PostgreSQL이 해당 포트에서 Listen하지 않을 경우

TCP 연결 거부 (RST 응답)

📦 예시 패킷

12:00:00.223456 IP 192.168.1.50.54321 > 192.168.1.100.5432: Flags [S], seq 123456, win 64240, options [...], length 0
12:00:00.223789 IP 192.168.1.100.5432 > 192.168.1.50.54321: Flags [R], seq 0, win 0, length 0

Flags [R]는 "Reset" 패킷으로, 서버가 해당 포트에서 수신 대기 중이 아니라는 의미입니다. 즉, OS가 "이 포트는 열려 있지 않다"고 알려주는 것.

---

4. 서버가 방화벽 등으로 인해 패킷을 드롭하고 응답하지 않는 경우

무응답 (Silent Drop)

📦 예시 패킷

12:00:00.323456 IP 192.168.1.50.54321 > 192.168.1.100.5432: Flags [S], seq 123456, win 64240, options [...], length 0

이후 아무 응답도 없음 (SYN 패킷만 있고, 서버에서 RST/SYN-ACK 응답이 없음)

클라이언트는 일정 시간 후 Connection timed out 에러를 받음

---

5.요약 비교

상황 SYN → 응답 패킷 의미

✅ 포트 열림	있음	SYN-ACK → ACK	연결 성공
❌ 포트 닫힘	있음	RST	연결 거부
❌ 방화벽	있음	없음	무응답, 연결 시간 초과

---

좋습니다! 서버와 클라이언트 사이에 방화벽(Firewall) 이 있는 경우, TCP 연결 시도에 따라 tcpdump에서 어떤 패킷이 보이는지 예시로 설명드리겠습니다.

---

8. 방화벽이 클라이언트와 서버 사이에 위치한 경우

🔹 위치:

클라이언트 → 방화벽 (중간) → 서버

---

1. 정상 연결 (방화벽 허용)

🔸 조건:

• 방화벽이 TCP 포트 5432 (PostgreSQL 포트)를 허용하고 있을 때

📦 tcpdump (서버 측에서)

12:00:00.100000 IP 192.168.1.50.54321 > 192.168.1.100.5432: Flags [S], seq 123456, win 64240, length 0
12:00:00.100200 IP 192.168.1.100.5432 > 192.168.1.50.54321: Flags [S.], seq 654321, ack 123457, win 65160, length 0
12:00:00.100300 IP 192.168.1.50.54321 > 192.168.1.100.5432: Flags [ACK], ack 654322, win 64240, length 0

✅ 3-way handshake가 정상적으로 이루어지고 이후 PostgreSQL 연결 가능

---

2. 방화벽이 포트 5432를 차단할 때

시나리오 1: 방화벽이 SYN 패킷 자체를 드롭 (무응답 Drop)

📦 클라이언트에서 tcpdump

12:01:00.000000 IP 192.168.1.50.54321 > 192.168.1.100.5432: Flags [S], seq 123456, win 64240, length 0

• 서버에서는 아무 것도 보이지 않음 (패킷이 서버에 도달하지 못함)
• 방화벽이 패킷을 조용히 폐기(Silent Drop)

클라이언트는 나중에 "Connection timed out" 오류를 받음
tcpdump는 서버 측에서는 아무 것도 캡처되지 않음

---

시나리오 2: 방화벽이 명시적으로 RST 패킷 반환

일부 보안 장비나 침입 방지 시스템(IPS)은 패킷을 차단하고 가짜 RST를 응답하는 경우도 있습니다.

📦 클라이언트에서

12:02:00.000000 IP 192.168.1.50.54321 > 192.168.1.100.5432: Flags [S], seq 123456, win 64240, length 0
12:02:00.000100 IP 192.168.1.100.5432 > 192.168.1.50.54321: Flags [R], seq 0, win 0, length 0

• 이 경우도 서버에서는 아무 응답이 없고, 중간 방화벽이 대신 응답한 것
• 클라이언트는 "Connection refused" 같은 메시지를 받게 됨

---

3. 요약: 방화벽이 있는 경우의 패킷 흐름

방화벽 동작 클라이언트 SYN 서버 SYN-ACK 결과 tcpdump에서 보임?

허용	전송됨	응답함	연결 성공	O (클/서버 모두)
드롭(Silent)	전송됨	없음	타임아웃	클라이언트만 보임
RST 응답	전송됨	RST 응답	연결 거부	클라이언트만 보임 (서버 X)

---

4. 팁: 서버 측에서 아무 것도 보이지 않는다면?

• 방화벽이나 보안 장비에서 SYN 패킷이 차단되고 있을 가능성이 높음
• 클라이언트 쪽에서는 telnet, nc, psql 모두 timeout 발생
• 서버 측 tcpdump에는 아무 것도 안 찍힘

---