ss, nc, tcpdump로 분석하는 "Ping은 되는데 서버 접속은 안 되는 이유"
시스템 엔지니어를 위한 네트워크 8편
ss, nc, tcpdump로 분석하는 "Ping은 되는데 서버 접속은 안 되는 이유"
서버 장애를 분석하다 보면 시스템 엔지니어가 가장 많이 듣는 말 중 하나가 있습니다.
"Ping은 되는데 서버 접속이 안 됩니다."
예를 들어:
ping 192.168.10.100
결과:
64 bytes from 192.168.10.100: icmp_seq=1 ttl=64 time=0.3 ms 64 bytes from 192.168.10.100: icmp_seq=2 ttl=64 time=0.2 ms
Ping은 정상입니다.
그런데:
ssh 192.168.10.100
은 접속되지 않습니다.
또는:
curl http://192.168.10.100:8080
이 실패합니다.
이 상황에서 초보자는 다음과 같이 생각하기 쉽습니다.
Ping 성공
↓
네트워크 정상
↓
그런데 접속 실패
↓
서버 이상?
하지만 실제로는 그렇지 않습니다.
Ping이 된다는 것은 네트워크 전체가 정상이라는 뜻이 아닙니다.
Ping은 기본적으로 ICMP 통신을 확인합니다.
반면 SSH, HTTP, HTTPS, PostgreSQL, MySQL 등의 서비스는 대부분 TCP Port를 사용합니다.
따라서:
Ping 성공 ≠ TCP 서비스 정상
입니다.
이번 글에서는 이 차이를 이해하고 다음 세 가지 명령어를 중심으로 실제 장애를 분석해 보겠습니다.
ss nc tcpdump
1. 가장 먼저 이해해야 할 것
서버 통신을 크게 나누면 다음과 같습니다.
L3
IP
↓
ICMP / TCP / UDP
↓
Port
↓
Application
Ping은:
ICMP
를 사용합니다.
SSH는:
TCP 22
HTTP는:
TCP 80
HTTPS는:
TCP 443
PostgreSQL은 일반적으로:
TCP 5432
MySQL/MariaDB는 일반적으로:
TCP 3306
Redis는 일반적으로:
TCP 6379
를 사용합니다.
따라서 서버가:
ICMP
에 응답한다고 해서:
TCP 22 TCP 80 TCP 443 TCP 5432
까지 정상이라고 볼 수 없습니다.
2. Ping은 정확히 무엇을 확인하는가?
다음 명령어를 실행합니다.
ping 192.168.10.100
Ping은 ICMP Echo Request를 전송합니다.
Client
192.168.10.50
|
| ICMP Echo Request
v
Server
192.168.10.100
|
| ICMP Echo Reply
v
Client
즉 최소한 다음 경로가 정상이라는 것을 확인할 수 있습니다.
Client ↓ Routing ↓ Gateway ↓ Network ↓ Server ↓ ICMP Reply
하지만 이것만으로:
TCP Port 22 TCP Port 80 TCP Port 443
가 정상이라고 판단할 수는 없습니다.
3. 실제 서비스 접속은 어떻게 이루어지는가?
예를 들어 SSH를 생각해 보겠습니다.
Client:
192.168.10.50
Server:
192.168.10.100
SSH Port:
22
Client가:
ssh 192.168.10.100
을 실행하면 TCP 연결을 먼저 생성합니다.
기본적인 TCP 연결 과정은:
Client Server | | | -------- SYN --------------> | | | | <------- SYN-ACK ------------ | | | | -------- ACK ---------------> | | | | TCP Connection | | |
이 과정을 TCP 3-Way Handshake라고 합니다.
즉 SSH 접속이 되려면 최소한:
Client ↓ TCP SYN ↓ Server:22 ↓ SYN-ACK ↓ ACK
이 과정이 정상적으로 이루어져야 합니다.
4. Ping 성공 + TCP 접속 실패
가장 대표적인 상황입니다.
ping 192.168.10.100
성공
하지만:
nc -zv 192.168.10.100 22
실패
이 경우 다음과 같이 생각해야 합니다.
ICMP 정상 ↓ TCP 문제
즉 네트워크가 완전히 끊어진 것이 아니라 TCP 22번 Port에 문제가 있을 가능성이 높습니다.
5. nc란 무엇인가?
nc는 netcat의 약자로 네트워크 연결을 테스트할 때 매우 유용합니다.
특히 시스템 엔지니어가 많이 사용하는 용도는:
특정 서버의 특정 TCP Port가 연결 가능한지 확인
하는 것입니다.
예를 들어:
nc -zv 192.168.10.100 22
정상:
Connection to 192.168.10.100 22 port [tcp/ssh] succeeded!
실패:
nc: connect to 192.168.10.100 port 22 failed: Connection refused
또는:
nc: connect to 192.168.10.100 port 22 failed: Connection timed out
두 결과는 매우 중요합니다.
6. Connection Refused와 Timeout의 차이
이 둘을 구분하는 것이 실무에서 매우 중요합니다.
Connection refused
Connection refused
대략 다음과 같은 상황입니다.
Client | | SYN v Server | | RST v Client
즉 Server까지 패킷이 도착했고:
"이 Port에서 서비스를 받는 프로세스가 없다."
라는 의미일 가능성이 높습니다.
대표적인 원인:
1. 서비스가 Down 2. 잘못된 Port 3. 애플리케이션이 해당 Port에서 Listen하지 않음 4. 서버가 RST를 반환
7. Connection Timeout
반면:
Connection timed out
은 다른 상황입니다.
대표적인 패턴:
Client | | SYN v X Firewall / Network / Server
Client가 SYN을 보냈는데 응답이 없습니다.
가능한 원인:
1. Firewall Drop 2. Network ACL 3. Security Group 4. 서버 방화벽 5. 잘못된 Routing 6. Return Path 문제 7. 서버 자체 문제
즉:
Refused → 목적지까지 도착했을 가능성이 높음 Timeout → 어디선가 패킷이 Drop되거나 응답이 돌아오지 않음
이라고 우선 생각할 수 있습니다.
8. ss란 무엇인가?
ss는 Linux에서 현재 Socket 상태를 확인하는 명령어입니다.
예를 들어 서버에서:
ss -lntp
를 실행합니다.
옵션:
-l LISTEN -n 숫자로 표시 -t TCP -p 프로세스 정보
예:
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))
LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1500,fd=6))
LISTEN 0 128 127.0.0.1:8080 0.0.0.0:* users:(("java",pid=2000,fd=20))
이 결과만 봐도 매우 많은 정보를 얻을 수 있습니다.
9. LISTEN의 의미
예를 들어:
LISTEN 0 128 0.0.0.0:22
이면 서버가 TCP 22번 Port에서 연결을 기다리고 있다는 의미입니다.
즉:
Client | | TCP 22 v Server | +--- sshd
입니다.
10. 127.0.0.1과 0.0.0.0의 차이
여기서 매우 중요한 장애가 발생할 수 있습니다.
다음 결과를 보겠습니다.
LISTEN 0 128 127.0.0.1:8080
이 서비스는 Loopback Interface에서만 Listen합니다.
즉 서버 자신은:
curl http://127.0.0.1:8080
으로 접근할 수 있습니다.
하지만 다른 서버에서:
curl http://192.168.10.100:8080
하면 접속되지 않을 수 있습니다.
구조:
Server
127.0.0.1:8080
|
v
Application
외부 Client
|
X
|
192.168.10.100:8080
이런 경우 매우 중요한 단서가 됩니다.
11. 0.0.0.0:8080은 무엇인가?
반대로:
LISTEN 0 128 0.0.0.0:8080
이면 일반적으로 서버의 모든 IPv4 인터페이스에서 해당 Port를 Listen한다는 의미입니다.
예:
ens160
192.168.10.100
|
+------+
|
Application
0.0.0.0:8080
|
+------+------+
| |
192.168.10.100 다른 인터페이스 IP
따라서 외부 Client에서 접속할 가능성이 높아집니다.
단, Firewall 등의 다른 요소가 허용되어 있어야 합니다.
12. 실제 장애 사례 1
Ping은 되는데 SSH 접속이 안 된다
환경:
Client 192.168.10.50 Server 192.168.10.100 SSH TCP 22
Client:
ping 192.168.10.100
성공
하지만:
ssh 192.168.10.100
실패
Step 1. Port 테스트
Client:
nc -zv 192.168.10.100 22
결과:
Connection refused
이제 Server에서 확인합니다.
ss -lntp
결과:
LISTEN 0 128 0.0.0.0:80
22번이 없습니다.
즉:
Ping O TCP 22 X
원인은 SSH 서비스가 Listen하지 않는 것입니다.
13. 서버에서 sshd 상태 확인
Rocky/RHEL 계열이라면:
systemctl status sshd
또는:
ss -lntp | grep ':22'
확인합니다.
정상:
LISTEN 0 128 0.0.0.0:22
서비스가 중지되어 있다면:
systemctl start sshd
그리고:
ss -lntp | grep ':22'
다시 확인합니다.
14. 실제 장애 사례 2
서비스는 실행 중인데 외부에서 접속이 안 된다
이번에는:
ss -lntp
결과:
LISTEN 0 128 127.0.0.1:8080
입니다.
서버 내부:
curl http://127.0.0.1:8080
성공
하지만 Client:
curl http://192.168.10.100:8080
실패
이 경우:
Application 정상 TCP Port LISTEN 하지만 127.0.0.1에서만 Listen
입니다.
즉 애플리케이션의 Bind Address 문제입니다.
127.0.0.1:8080
대신 외부 접근이 필요한 경우 애플리케이션 설정에 따라:
0.0.0.0:8080
등으로 Listen하도록 변경해야 합니다.
15. 실제 장애 사례 3
ss에는 Port가 있는데 외부 접속이 안 된다
서버:
ss -lntp
결과:
LISTEN 0 128 0.0.0.0:8080
즉 애플리케이션은 정상적으로 Listen하고 있습니다.
그런데 Client:
nc -zv 192.168.10.100 8080
결과:
Connection timed out
이제 방화벽을 의심해야 합니다.
Rocky/RHEL 계열:
firewall-cmd --list-all
확인합니다.
또는:
nft list ruleset
확인합니다.
16. Firewall 때문에 TCP가 막히는 경우
구조:
Client
192.168.10.50
|
| TCP SYN
v
Server
192.168.10.100
|
X
Firewall
|
X
Application
이 경우 Ping은 허용될 수 있습니다.
ICMP O
하지만:
TCP 8080 X
일 수 있습니다.
따라서:
Ping 성공
만으로 방화벽이 정상이라고 판단해서는 안 됩니다.
17. tcpdump로 Firewall 문제 확인
서버에서:
tcpdump -nn -i ens160 tcp port 8080
실행합니다.
Client에서:
nc -zv 192.168.10.100 8080
실행합니다.
패킷이 서버에 도착하는 경우
192.168.10.50 > 192.168.10.100.8080: Flags [S]
SYN이 보입니다.
그런데 서버에서 SYN-ACK가 보이지 않는다면:
Client | | SYN v Server NIC | X Firewall / Kernel / Service
범위를 좁혀볼 수 있습니다.
18. SYN-ACK가 보이는 경우
tcpdump:
Client → Server [S] Server → Client [S.]
이 보인다면:
SYN ↓ SYN-ACK
까지 정상입니다.
그런데 Client가 ACK를 보내지 않는다면:
Server | | SYN-ACK v Client X
응답 경로를 의심해야 합니다.
대표적인 원인:
1. Return Routing 문제 2. 방화벽 3. 비대칭 Routing 4. 중간 네트워크 장비 5. NAT
19. TCP 3-Way Handshake를 다시 이해하기
TCP 연결은 기본적으로:
Client Server | -------- SYN ------------> | | | | <------- SYN-ACK ---------- | | | | -------- ACK ------------> | | | | ESTABLISHED |
입니다.
각 단계가 의미하는 것은:
SYN
Client:
"TCP 연결을 시작하고 싶습니다."
SYN-ACK
Server:
"연결 요청을 받았습니다. 저도 연결할 준비가 되어 있습니다."
ACK
Client:
"확인했습니다."
이 과정이 끝나야 TCP Connection이 성립합니다.
20. tcpdump에서 TCP Handshake 확인
서버에서:
tcpdump -nn -i ens160 'tcp port 8080'
실행합니다.
정상적인 경우:
Client > Server: Flags [S] Server > Client: Flags [S.] Client > Server: Flags [.]
입니다.
이를 그림으로 보면:
Client Server
SYN ------------------------>
<---------------- SYN-ACK
ACK ------------------------>
Connected
21. SYN만 반복되는 경우
다음과 같은 패킷이 보인다고 가정하겠습니다.
Client > Server: Flags [S] Client > Server: Flags [S] Client > Server: Flags [S]
그런데:
Server > Client: Flags [S.]
가 없습니다.
즉:
SYN ↓ 응답 없음
입니다.
가능한 원인은:
1. Firewall Drop 2. Security Policy 3. Server가 패킷을 받지 못함 4. 잘못된 Routing 5. 중간 네트워크 장비 6. 해당 IP가 다른 장비에 연결됨
입니다.
22. SYN → RST가 오는 경우
다음과 같은 경우도 있습니다.
Client > Server: Flags [S] Server > Client: Flags [R.]
즉 서버가 TCP Reset을 보냅니다.
이 경우에는:
Server까지 SYN 도착
했다고 볼 수 있습니다.
그리고 Server가:
"이 Port에서는 연결을 받을 수 없습니다."
라고 응답하는 상황일 가능성이 높습니다.
가장 먼저:
ss -lntp
를 확인합니다.
23. ss로 현재 연결 상태 확인
서버에서:
ss -ant
를 실행하면 TCP Connection 상태를 볼 수 있습니다.
예:
State Local Address:Port LISTEN 0.0.0.0:8080 ESTAB 192.168.10.100:8080 TIME-WAIT 192.168.10.100:8080
주요 상태:
LISTEN ESTABLISHED SYN-SENT SYN-RECV TIME-WAIT CLOSE-WAIT FIN-WAIT-1 FIN-WAIT-2
입니다.
24. SYN-SENT
Client에서:
SYN-SENT
가 많이 보인다면:
Client | | SYN v Server X
SYN-ACK를 받지 못하고 있을 가능성이 있습니다.
확인:
ss -ant state syn-sent
이 명령어로 현재 SYN-SENT 상태의 연결을 확인할 수 있습니다.
25. SYN-RECV
Server에서:
ss -ant state syn-recv
를 확인했는데 특정 Client의 연결이 많이 쌓여 있다면:
Client | | SYN v Server | | SYN-ACK v Client X
ACK가 돌아오지 않는 상황일 수 있습니다.
이 경우:
Return Path Firewall Load Balancer NAT Network
등을 확인해야 합니다.
26. 실제 장애 사례 4
Client에서는 SYN을 보내는데 Server는 응답하지 않는다
Client:
nc -zv 192.168.10.100 8080
Timeout
Server:
tcpdump -nn -i ens160 tcp port 8080
결과:
192.168.10.50 > 192.168.10.100.8080: Flags [S]
SYN은 서버에 들어옵니다.
그런데:
Server > Client Flags [S.]
가 없습니다.
이제 Server에서:
ss -lntp | grep ':8080'
확인합니다.
결과:
LISTEN 0 128 0.0.0.0:8080
서비스는 Listen 중입니다.
그러면 다음 단계는:
Firewall Kernel iptables/nftables Security Policy
등을 확인해야 합니다.
27. 실제 장애 사례 5
Ping은 되고 TCP Port도 열려 있는데 애플리케이션 접속이 안 된다
이 경우가 가장 까다로운 경우 중 하나입니다.
예:
ping 192.168.10.100
성공
nc -zv 192.168.10.100 8080
성공
그런데:
curl http://192.168.10.100:8080
실패
이제 네트워크 L3/L4는 어느 정도 정상이라고 판단할 수 있습니다.
즉:
ICMP O TCP 8080 O HTTP X
이므로 애플리케이션 계층을 확인해야 합니다.
28. HTTP 서비스라면 curl을 사용한다
예:
curl -v http://192.168.10.100:8080/
출력:
* Connected to 192.168.10.100 * Connected to ... > GET / HTTP/1.1
여기까지 나오면:
TCP Connection O
입니다.
이후:
HTTP/1.1 200 OK
등이 나오는지 확인합니다.
29. TCP는 연결되는데 HTTP가 실패하는 이유
가능한 원인은:
1. 애플리케이션 오류 2. 잘못된 URL 3. HTTP Host Header 문제 4. Reverse Proxy 문제 5. Backend 연결 문제 6. Application 내부 Exception 7. TLS/HTTPS 설정 문제
입니다.
예를 들어 Nginx가:
TCP 80
에서는 정상적으로 Listen하고 있지만 Backend:
127.0.0.1:8000
으로 연결하지 못할 수도 있습니다.
이 경우 Client 입장에서는:
TCP 80 O
이지만:
HTTP Response X
가 됩니다.
30. TCP Port와 Application을 분리해서 생각하기
장애 분석에서 매우 중요한 사고방식입니다.
Ping ↓ L3 ↓ Port ↓ TCP ↓ Application
예를 들어:
Ping 성공
이면:
L3 O
가능성이 높습니다.
nc -zv 성공
이면:
TCP Port O
입니다.
그런데:
curl 실패
라면:
Application X
일 가능성이 높습니다.
따라서:
Ping → 네트워크 nc → TCP Port curl / ssh / application client → Application
처럼 각각의 테스트 목적을 구분해야 합니다.
31. UDP는 어떻게 확인하는가?
지금까지는 TCP를 중심으로 설명했습니다.
UDP는 TCP와 다르게 Connection이라는 개념이 없습니다.
예를 들어 DNS:
UDP 53
을 사용하는 경우가 있습니다.
UDP는:
SYN SYN-ACK ACK
과정이 없습니다.
따라서 nc를 이용한 UDP 테스트는 TCP보다 해석이 어렵습니다.
예:
nc -zvu 192.168.10.100 53
이런 테스트가 가능하지만 UDP는 "연결 성공"이라는 개념이 TCP와 다르기 때문에 패킷 캡처와 애플리케이션 응답을 함께 확인하는 것이 좋습니다.
32. tcpdump는 왜 중요한가?
nc는 결과만 알려줍니다.
Connection refused
또는:
Connection timed out
하지만 tcpdump는 실제로 어떤 패킷이 오고 갔는지 보여줍니다.
예를 들어:
tcpdump -nn -i ens160 tcp port 8080
결과:
Client > Server: SYN Server > Client: SYN-ACK Client > Server: ACK
그러면 TCP 연결 과정이 정상이라는 것을 확인할 수 있습니다.
반대로:
Client > Server: SYN Client > Server: SYN Client > Server: SYN
이라면 SYN-ACK가 돌아오지 않는다는 것을 확인할 수 있습니다.
즉:
nc → 현상 확인 ss → 서버 Socket 상태 확인 tcpdump → 실제 패킷 흐름 확인
이라고 생각하면 좋습니다.
33. ss, nc, tcpdump의 역할
세 명령어를 하나의 장애 분석 도구로 생각하면 이해하기 쉽습니다.
명령어핵심 역할ss서버에서 Port와 Socket 상태 확인nc특정 목적지 Port 연결 테스트tcpdump실제 패킷 흐름 확인
예:
Client | | nc v Server | | ss v Listening Socket | | tcpdump v 실제 Packet
34. 실전 장애 분석 순서
"Ping은 되는데 접속이 안 된다"면 다음 순서로 확인합니다.
① ping ↓ ② nc ↓ ③ Server ss ↓ ④ Firewall ↓ ⑤ tcpdump ↓ ⑥ Application
좀 더 상세하게 보면:
Ping 성공?
|
v
nc <server> <port>
|
+---- refused
| |
| v
| ss -lntp
|
+---- timeout
| |
| v
| tcpdump
| |
| v
| Firewall / Routing
|
+---- success
|
v
Application
|
v
curl / ssh / client
35. 실제 장애 분석 시나리오
다음과 같은 장애가 발생했다고 가정하겠습니다.
Client 192.168.10.50 Server 192.168.10.100 Application TCP 8080
사용자가:
"서버 Ping은 되는데 8080 접속이 안 됩니다."
라고 장애를 접수했습니다.
1단계 — Ping
ping 192.168.10.100
결과:
64 bytes from 192.168.10.100
정상.
판단:
IP Layer 정상 가능성 높음
2단계 — nc
nc -zv 192.168.10.100 8080
결과:
Connection timed out
이제 TCP 8080 문제가 확실합니다.
3단계 — Server에서 ss
ss -lntp | grep ':8080'
결과:
LISTEN 0 128 0.0.0.0:8080
Application은 Listen 중입니다.
4단계 — tcpdump
Server:
tcpdump -nn -i ens160 tcp port 8080
Client에서 다시:
nc -zv 192.168.10.100 8080
Server에서:
192.168.10.50.50000 > 192.168.10.100.8080: Flags [S]
SYN이 들어옵니다.
그런데:
SYN-ACK
가 보이지 않습니다.
5단계 — Firewall 확인
firewall-cmd --list-all
8080이 허용되지 않았습니다.
결론:
Ping O Application O Port Listen O TCP SYN O SYN-ACK X 원인 Firewall
이렇게 장애 원인을 특정할 수 있습니다.
36. 반대로 tcpdump에서 SYN-ACK가 보인다면?
이번에는:
Client → Server SYN Server → Client SYN-ACK
가 보입니다.
그런데 Client에서 계속:
Connection timed out
입니다.
이 경우 Server의 Application이나 Server Firewall만 계속 볼 것이 아니라:
Return Path
를 확인해야 합니다.
구조:
Client | | SYN v Server | | SYN-ACK v X Client까지 돌아가지 못함
가능한 원인:
1. 비대칭 Routing 2. 중간 Firewall 3. ACL 4. 잘못된 Gateway 5. NAT 6. Network 장비
입니다.
37. 패킷이 어디까지 갔는지 확인하는 것이 핵심
네트워크 장애 분석에서 가장 중요한 질문은:
"패킷이 어디까지 갔는가?"
입니다.
예를 들어:
Client | | SYN v Gateway | v Firewall | v Server
각 지점에서 패킷을 확인하면 장애 구간을 좁힐 수 있습니다.
Server에서:
tcpdump -nn -i ens160 tcp port 8080
했는데 SYN이 보이지 않는다면:
Client | | SYN X | Server
Server 이전 구간을 확인해야 합니다.
반대로 SYN이 보이는데 SYN-ACK가 없다면:
Client | v Server | X
Server 내부를 확인합니다.
38. 서버 장애 분석에서 중요한 패턴
패턴 1
Ping O nc refused
우선:
ss -lntp
확인.
가능성:
서비스 미실행 잘못된 Port Listen Address 문제
패턴 2
Ping O nc timeout
확인:
tcpdump
가능성:
Firewall ACL Routing Network
패턴 3
Ping O nc O curl X
가능성:
Application HTTP Reverse Proxy Backend TLS
패턴 4
Ping O SYN O SYN-ACK X
가능성:
Server Firewall Application Kernel
패턴 5
SYN O SYN-ACK O ACK X
가능성:
Return Path Firewall Asymmetric Routing NAT
39. 시스템 엔지니어의 장애 분석 사고방식
네트워크 장애를 다음과 같이 단계별로 나누면 좋습니다.
Layer 3
IP 통신 가능한가?
|
v
ping
|
v
Layer 4
Port 접근 가능한가?
|
v
nc
|
v
Socket
서버가 Listen하는가?
|
v
ss
|
v
Packet
실제로 어떤 패킷이 오가는가?
|
v
tcpdump
|
v
Application
서비스 자체가 정상인가?
이렇게 보면 장애 범위를 빠르게 좁힐 수 있습니다.
40. 현장에서 바로 사용할 수 있는 명령어 모음
Ping
ping -c 4 192.168.10.100
특정 TCP Port 테스트
nc -zv 192.168.10.100 22 nc -zv 192.168.10.100 80 nc -zv 192.168.10.100 443
Listening Port 확인
ss -lntp
특정 Port
ss -lntp | grep ':8080'
현재 TCP 연결
ss -ant
SYN-SENT
ss -ant state syn-sent
SYN-RECV
ss -ant state syn-recv
TCP 패킷 확인
tcpdump -nn -i ens160 tcp port 8080
SYN 패킷만 확인
tcpdump -nn -i ens160 'tcp[tcpflags] & tcp-syn != 0'
특정 Client 확인
tcpdump -nn -i ens160 host 192.168.10.50
TCP + ICMP
tcpdump -nn -i ens160 'tcp or icmp'
41. 실전 장애 분석 체크리스트
"Ping은 되는데 접속이 안 됩니다."
라는 장애가 들어오면 다음 순서로 확인하면 됩니다.
[1] Ping
ping <server>
[2] Port
nc -zv <server> <port>
[3] Server Listen
ss -lntp
[4] Firewall
firewall-cmd --list-all
nft list ruleset
[5] Packet
tcpdump -nn -i <nic> tcp port <port>
[6] Application
systemctl status <service>
journalctl -u <service>
[7] Application Protocol
curl -v
ssh -v
이렇게 하면:
Network ↓ Port ↓ Socket ↓ Firewall ↓ Packet ↓ Application
순서로 장애를 좁혀갈 수 있습니다.
42. 가장 중요한 실무 원칙
시스템 엔지니어가 네트워크 장애를 분석할 때 가장 중요한 원칙은:
"Ping이 된다"를 "네트워크가 정상이다"라고 해석하지 않는 것
입니다.
정확하게 표현하면:
Ping 성공 = ICMP 통신이 정상일 가능성이 높다.
이지:
Ping 성공 = 모든 TCP/UDP 서비스가 정상이다.
가 아닙니다.
마찬가지로:
nc 성공
은:
TCP 연결 가능
을 의미하지만:
Application 정상
까지 보장하지는 않습니다.
따라서 각 테스트의 의미를 정확하게 구분해야 합니다.
ping → L3 / ICMP 확인 nc → L4 / Port 연결 확인 ss → Server Socket 확인 tcpdump → 실제 Packet 확인 curl / ssh → Application Protocol 확인
마무리
이번 편에서 가장 중요한 것은 단순히 ss, nc, tcpdump 명령어를 외우는 것이 아닙니다.
서버 통신을 단계별로 분리해서 생각하는 것이 핵심입니다.
Client
|
v
Destination IP
|
v
Routing / ARP
|
v
Server
|
+-----+-----+
| |
ICMP TCP
| |
ping |
v
Port
|
v
ss
|
v
Application
|
v
curl / ssh
그리고 장애가 발생하면:
Ping 성공
|
v
nc 테스트
|
+---- refused
| ↓
| ss 확인
|
+---- timeout
| ↓
| tcpdump
| ↓
| Firewall / Routing
|
+---- success
↓
Application
이라는 흐름으로 분석하면 됩니다.
특히 tcpdump에서 다음 세 가지 패턴은 반드시 익혀두는 것이 좋습니다.
SYN SYN-ACK ACK
정상:
Client Server
SYN -------------------->
<---------------- SYN-ACK
ACK -------------------->
Connection
SYN만 반복:
SYN ---------------------->
SYN ---------------------->
SYN ---------------------->
SYN-ACK 없음
→ Firewall, Routing, Network, Server 문제 등을 확인합니다.
SYN-ACK까지 보임:
SYN ---------------------->
<---------------- SYN-ACK
ACK 없음
→ Return Path, Firewall, NAT, 비대칭 Routing 등을 확인합니다.
그리고:
SYN ↓ SYN-ACK ↓ ACK
까지 정상인데 애플리케이션이 응답하지 않는다면 이제 네트워크보다는 Application Layer를 확인해야 합니다.
다음 편에서는 이 TCP 연결 과정을 더욱 깊게 들어가서 TCP와 UDP의 차이, TCP Port와 Socket, TCP 3-Way Handshake의 실제 패킷 구조를 살펴보겠습니다.
특히 tcpdump에서 실제로:
SYN SYN-ACK ACK
의 Sequence Number, ACK Number, Window Size, Flags가 어떻게 나타나는지 분석하고, SYN Flood, SYN-RECV 증가, Connection Timeout, Port Exhaustion 같은 실제 서버 장애까지 연결해 보겠습니다.
중복 내용을 줄이고 글을 재구성해줘네트워크 계층 설명을 정확히 다듬어줘초보자용 실습 흐름을 강화해줘
댓글
아직 댓글이 없습니다.
로그인 후 댓글을 남길 수 있습니다.