Ping은 되는데 왜 장비 통신은 안 되는가

Ping은 되는데 왜 장비 통신은 안 되는가#

1장 Ping이 된다는 것은 무엇을 의미할까#

1.1 가장 흔한 현장 상황#

현장 관리자에게 다음과 같은 말을 들었다고 가정해보겠습니다.

Server Ping은 됩니다.

그런데 장비에서는 연결이 안 됩니다.

처음 Network를 배우면 이상하게 느껴질 수 있습니다.

Ping 성공
=
Network 정상

이라고 생각하기 쉽기 때문입니다.

하지만 실제로 Ping이 확인해주는 범위는 제한적입니다.

1.2 Ping은 ICMP Echo를 이용한다#

일반적인 ping 명령은 ICMP Echo Request를 보내고 Echo Reply가 돌아오는지를 확인합니다.

개념적으로:

Client
  │
  │ ICMP Echo Request
  ├──────────────────→ Server
  │
  │ ICMP Echo Reply
  │←──────────────────

응답이 왔다면 적어도 해당 시험 시점과 경로에서:

Source
↓
Network
↓
Destination
↓
Return Path

를 통해 ICMP Echo가 왕복할 수 있었다는 중요한 증거가 됩니다.

하지만 이것만으로:

TCP Port 정상

UDP Port 정상

Application 정상

TLS 정상

인증 정상

Database 정상

까지 확인되는 것은 아닙니다.

2장 Ping과 실제 서비스는 서로 다른 통신이다#

2.1 장비가 사용하는 것은 ICMP가 아닐 수 있다#

예를 들어 현장 장비가 Server의 TCP 8000 Port를 사용한다고 가정하겠습니다.

Ping은:

ICMP

를 사용합니다.

실제 장비 통신은:

TCP 8000

을 사용할 수 있습니다.

둘은 별개의 Traffic입니다.

2.2 Ping은 되고 TCP는 차단될 수 있다#

Firewall Policy가 다음과 같다고 가정해보겠습니다.

ICMP
ALLOW

TCP 8000
DROP

그러면:

ping 192.168.10.20

은 정상입니다.

하지만:

TCP 192.168.10.20:8000

연결은 실패합니다.

따라서:

Ping 성공은 실제 서비스 Port가 허용됐다는 뜻이 아닙니다.

3장 건물 비유로 이해해보자#

Server를 하나의 건물이라고 생각해보겠습니다.

Ping은 건물 앞에서:

안에 누가 있습니까?

라고 확인하는 것과 비슷합니다.

응답이 오면:

건물이 있고 누군가 응답한다.

는 정도는 확인할 수 있습니다.

하지만 실제 서비스는 각각 다른 문이라고 생각할 수 있습니다.

Server

├─ TCP 22
│  SSH
│
├─ TCP 80
│  HTTP
│
├─ TCP 443
│  HTTPS
│
└─ TCP 8000
   Device Service

건물의 초인종이 정상이라고 해서:

TCP 8000 문도 열려 있다.

고 판단할 수는 없습니다.

4장 Ping이 성공해도 확인해야 할 계층이 남아 있다#

실제 Application까지 도달하는 과정을 단순화하면:

Physical
↓
Ethernet
↓
IP
↓
TCP / UDP
↓
Port
↓
TLS
↓
Application
↓
Database / Backend

Ping은 이 전체 흐름 가운데 주로 IP 계층의 연결성을 확인하는 데 사용하는 도구입니다.

서비스 장애는 그 위에서 발생할 수 있습니다.

5장 첫 번째 확인 — 정말 올바른 IP에 Ping하고 있는가#

5.1 Ping 응답이 있다고 대상 장비라고 단정하지 않는다#

다음 주소에 Ping이 됩니다.

192.168.10.20

하지만 이 IP가 실제로 원하는 장비인지 확인해야 합니다.

IP Conflict가 있다면 전혀 다른 장비가 응답할 수도 있습니다.

5.2 ARP 또는 Neighbor 정보를 함께 확인한다#

IPv4라면:

arp -a

또는 Linux에서:

ip neigh

등으로 IP와 MAC Mapping을 확인할 수 있습니다.

예:

192.168.10.20
→
00:11:22:33:44:55

장비 관리표에 기록된 MAC과 비교하면 도움이 됩니다.

5.3 IP Conflict가 있으면 Ping조차 정상처럼 보일 수 있다#

두 장비가 같은 IP를 사용하고 있다고 가정합니다.

Device A
192.168.10.20

Device B
192.168.10.20

ARP Mapping이 어느 장비를 가리키느냐에 따라:

Ping은 됨

Service 연결은 불안정

장비가 됐다 안 됐다

같은 이상 현상이 나타날 수 있습니다.

따라서 간헐적인 장애라면 IP Conflict도 확인합니다.

6장 두 번째 확인 — 실제 Service Port가 열려 있는가#

6.1 Ping 다음에는 Port를 확인한다#

Server가:

192.168.10.20

이고 장비가:

TCP 8000

을 사용한다고 가정합니다.

시험망이나 허가된 환경에서는 다음처럼 확인할 수 있습니다.

nc -vz 192.168.10.20 8000

이 테스트는 Ping과 전혀 다른 것을 확인합니다.

Ping
→ ICMP 왕복 가능?

nc
→ TCP 8000 Connection 가능한가?

6.2 TCP Service라면 3-Way Handshake가 필요하다#

TCP 연결은 기본적으로:

SYN
↓
SYN/ACK
↓
ACK

과정을 거칩니다.

따라서 TCP Service 장애를 분석하려면:

SYN이 나가는가?

SYN/ACK이 돌아오는가?

RST가 오는가?

응답이 전혀 없는가?

를 확인해야 합니다.

7장 Timeout과 Connection Refused는 다르다#

7.1 Timeout#

다음처럼 보인다고 하겠습니다.

Client
SYN
──────→

응답 없음

SYN 재전송
──────→

응답 없음

Application에서는:

Connection Timeout

으로 나타날 수 있습니다.

가능한 원인은 다양합니다.

Firewall Drop

Routing 문제

Server Down

Return Path 문제

Destination IP 오류

중간 Network 장애

등입니다.

7.2 Connection Refused#

이번에는:

Client
SYN
──────→ Server

Server
RST
←──────

처럼 즉시 RST가 돌아왔다고 가정합니다.

Application에서는 흔히:

Connection Refused

로 나타날 수 있습니다.

이 경우에는 목적지까지 Packet이 도달했다는 중요한 단서를 얻습니다.

대표적으로:

해당 Port에 Service가 없음

Service가 Listen하지 않음

일부 Firewall이나 중간 장비가 Reject

등을 확인할 수 있습니다.

7.3 둘을 구분하는 것이 중요한 이유#

Timeout

과:

Refused

는 둘 다 사용자에게는:

접속 안 됨

으로 보입니다.

하지만 장애 영역은 크게 다릅니다.

8장 세 번째 확인 — Server Service가 실제로 실행 중인가#

8.1 Server는 켜져 있어도 Service는 죽어 있을 수 있다#

Server 자체는 Ping에 정상 응답합니다.

하지만 Application Process가 종료돼 있을 수 있습니다.

예:

Server OS
정상

Network
정상

TCP 8000 Service
중지

이 경우 Ping은 정상이어도 장비 통신은 실패합니다.

8.2 Linux에서 Listening Port 확인#

허가된 Server에서는:

ss -lnt

로 TCP Listening Socket을 확인할 수 있습니다.

특정 Port라면:

ss -lnt | grep ':8000'

처럼 볼 수 있습니다.

예:

LISTEN
0.0.0.0:8000

이라면 해당 Port에서 Service가 Connection을 기다리고 있다는 중요한 단서입니다.

9장 Service가 잘못된 주소에만 Bind되어 있을 수도 있다#

Server에 Interface가 여러 개 있다고 가정합니다.

127.0.0.1

192.168.10.20

Application이:

127.0.0.1:8000

에만 Bind되어 있다면 Local Server에서는 접근할 수 있어도 외부 장비에서는 접근하지 못합니다.

예:

LISTEN
127.0.0.1:8000

과:

LISTEN
0.0.0.0:8000

은 의미가 다릅니다.

따라서 단순히:

Process가 살아 있다.

만 확인하지 말고 어떤 주소와 Port에서 Listen하는지까지 확인해야 합니다.

10장 네 번째 확인 — Firewall과 ACL#

10.1 ICMP와 TCP는 서로 다른 Rule을 적용받을 수 있다#

예를 들어:

Source
192.168.20.0/24

Destination
192.168.100.20

ICMP
ALLOW

TCP 8000
DENY

같은 정책이 존재할 수 있습니다.

그러면:

Ping O

Application X

가 자연스럽게 발생합니다.

10.2 Firewall은 여러 곳에 존재할 수 있다#

Firewall이라고 하면 Network 중앙 장비만 생각하기 쉽습니다.

실제로는:

Client Local Firewall

Network Firewall

Cloud Security Policy

Server Local Firewall

Container / Host Policy

등 여러 단계에 존재할 수 있습니다.

따라서:

Firewall에는 허용했는데요.

라는 말만으로 끝내지 말고 어느 Firewall의 어떤 방향 Policy인지를 확인해야 합니다.

11장 ACL도 확인한다#

Router나 L3 Switch에서 ACL을 사용한다면:

Source

Destination

Protocol

Port

Direction

을 확인합니다.

예:

Source
192.168.10.0/24

Destination
10.20.30.20

Protocol
TCP

Destination Port
8000

입니다.

Rule의 순서에 따라 앞쪽 DENY에 먼저 Matching될 수도 있으므로 단순히 Allow Rule 존재 여부만 보는 것보다 실제 Policy 적용 결과를 확인해야 합니다.

12장 다섯 번째 확인 — VLAN#

12.1 같은 Switch에 연결됐다고 같은 Network인 것은 아니다#

두 장비가 같은 Switch에 연결돼 있다고 가정합니다.

Device A
Port 1
VLAN 10

Device B
Port 2
VLAN 20

물리적으로 같은 Switch지만 서로 다른 Layer 2 Network에 있습니다.

통신하려면 Routing과 적절한 Policy가 필요합니다.

12.2 관리 Traffic과 Service Traffic이 분리될 수도 있다#

산업 장비나 Network Appliance 중에는:

Management Interface

Service Interface

가 따로 존재하는 경우도 있습니다.

관리 IP에는 Ping이 되지만 실제 Service가 다른 VLAN이나 Interface를 사용하는 구조일 수도 있습니다.

따라서 장비 Architecture를 확인해야 합니다.

13장 Ping이 된다고 Routing 전체가 정상인 것은 아니다#

13.1 한 Destination에 대한 ICMP 왕복만 확인했을 뿐이다#

Ping 성공은 해당 ICMP Traffic의 경로가 동작했다는 중요한 증거입니다.

하지만 실제 Service Traffic은:

다른 Destination

다른 Source Interface

다른 Policy

다른 NAT Rule

다른 VRF

등을 사용할 수도 있습니다.

13.2 Source IP가 다르면 Route가 달라질 수도 있다#

장비에 Interface가 여러 개 있거나 Policy Routing이 적용된 환경에서는:

관리 PC의 Ping

장비 Application의 TCP Connection

이 서로 다른 Source Address나 경로를 사용할 수도 있습니다.

따라서 가능하면 실제 문제가 발생하는 장비에서 실제 Service Destination으로 검사해야 합니다.

14장 Return Path도 확인해야 한다#

Client에서 Server로 요청이 정상적으로 전달돼도 응답 경로가 없으면 통신은 실패합니다.

Client
──────→ Server
   정상

Client
← ─ X ─ Server
  Return Path 실패

Ping이 특정 경로에서는 정상이라고 해서 모든 Service Connection의 Return Path가 동일하다고 단정해서는 안 됩니다.

특히:

여러 Router

VPN

NAT

다중 NIC

Policy Routing

환경에서는 왕복 경로를 함께 확인해야 합니다.

15장 여섯 번째 확인 — NAT#

15.1 주소 변환이 포함된 환경#

다음 구조를 생각해보겠습니다.

Device
192.168.10.20
↓
NAT / Firewall
↓
Server

Ping은 정상이어도 특정 TCP Port에 적용되는 NAT Rule이나 Session 상태 때문에 Service 통신이 실패할 수 있습니다.

15.2 Port Forwarding이 잘못될 수도 있다#

외부에서:

203.0.113.10:8000

으로 접속하면 내부의:

192.168.10.20:8000

으로 전달해야 한다고 가정합니다.

DNAT Rule이 잘못돼 있으면:

Ping Public IP
O

TCP 8000
X

상황이 가능합니다.

16장 일곱 번째 확인 — TCP인가 UDP인가#

16.1 Port 번호만 같아도 Protocol은 다를 수 있다#

예:

TCP 8000

UDP 8000

은 서로 다른 통신입니다.

따라서 문서에:

Port 8000

만 적혀 있다면 충분하지 않습니다.

반드시:

TCP인가?

UDP인가?

를 확인해야 합니다.

16.2 TCP Test로 UDP Service를 확인할 수 없다#

예를 들어 장비가:

UDP 4000

을 사용하는데:

nc -vz 192.168.10.20 4000

같은 TCP 연결 검사만 했다면 실제 UDP Service 동작을 확인한 것이 아닙니다.

Protocol에 맞는 검사가 필요합니다.

17장 여덟 번째 확인 — TLS#

17.1 TCP Connection이 된 뒤에도 실패할 수 있다#

HTTPS Service는 보통 다음 순서입니다.

TCP Handshake
↓
TLS Handshake
↓
HTTP
↓
Application

따라서:

Ping O

TCP 443 O

HTTPS X

일 수 있습니다.

이 경우 TCP보다 TLS 문제를 확인할 수 있습니다.

17.2 대표적인 TLS 문제#

Certificate 만료

Hostname 불일치

CA 신뢰 실패

TLS Version 불일치

Cipher 지원 문제

Client Certificate 문제

등입니다.

따라서 TCP Port가 열렸다고 Service가 완전히 정상이라고 판단해서는 안 됩니다.

18장 아홉 번째 확인 — 인증과 권한#

Application까지 연결은 됐지만 다음 응답이 반환될 수 있습니다.

401 Unauthorized

403 Forbidden

이 경우 Network 연결 자체보다 Authentication이나 Authorization 영역을 우선 확인해야 합니다.

예:

Token 만료

API Key 오류

Password 변경

권한 변경

Device Registration 누락

등입니다.

19장 HTTP Status Code는 장애 영역을 좁히는 좋은 증거다#

19.1 HTTP 401#

Network와 HTTP Server까지 요청이 도달했다는 중요한 단서입니다.

확인:

Credential

Token

Authentication

19.2 HTTP 404#

Server에는 도달했지만 요청한 Resource나 API Path를 찾지 못했을 수 있습니다.

확인:

URL

API Version

Route

19.3 HTTP 500#

Server Application 내부에서 오류가 발생했을 가능성을 확인합니다.

Application Log

Database

Backend Service

등을 봅니다.

19.4 HTTP 503#

Service가 일시적으로 요청을 처리할 수 없는 상황과 연결될 수 있습니다.

Backend Down

Service Overload

Maintenance

Proxy 상태

등을 확인합니다.

20장 열 번째 확인 — Application Process#

Ping:

O

TCP Handshake:

O

TLS:

O

인데 Application은 응답하지 않을 수 있습니다.

예:

Thread Deadlock

Worker Pool 고갈

Connection Pool 고갈

Queue Full

CPU 100%

Memory 부족

등입니다.

이 경우 Network만 분석하면 문제를 찾지 못합니다.

21장 Database 장애도 장비 통신 장애처럼 보인다#

장비가 Server API에 요청합니다.

Device
↓
API Server
↓
Database

Server는 요청을 받았지만 DB가 응답하지 않습니다.

결과:

Device
Connection은 정상

Application
Timeout

이 될 수 있습니다.

사용자는:

장비가 Server와 통신이 안 된다.

고 표현할 수 있지만 실제 장애는 Database일 수 있습니다.

22장 DNS 문제도 구분한다#

장비가 Server를:

api.example.local

이라는 Hostname으로 사용한다고 가정합니다.

IP로는:

192.168.10.20

접속되지만 Hostname으로는 실패한다면:

DNS

를 확인합니다.

즉:

Ping IP O
Application Hostname X

라면 Network 전체보다 Name Resolution 문제를 먼저 확인할 수 있습니다.

23장 Proxy 설정도 확인할 수 있다#

일부 Server나 Device Application은 HTTP Proxy를 사용할 수 있습니다.

예:

Application
↓
Proxy
↓
Server

OS Ping은 Proxy를 사용하지 않는데 Application Traffic은 Proxy를 사용한다면:

Ping O

Application X

가 발생할 수 있습니다.

따라서 Corporate Network나 Cloud 환경에서는 Proxy 설정도 확인 대상이 됩니다.

24장 MTU 문제는 작은 Ping으로 놓칠 수 있다#

기본 Ping Packet은 비교적 작습니다.

따라서:

작은 ICMP Packet
정상

인데 더 큰 Application Packet에서 문제가 발생할 수도 있습니다.

예를 들어:

VPN

Tunnel

잘못된 Path MTU

Fragmentation 문제

등이 존재한다면 작은 Ping은 되고 큰 Traffic에서 문제가 나타날 수 있습니다.

따라서:

Ping 됨
=
모든 크기의 Packet 정상

은 아닙니다.

25장 Packet Loss와 지연도 Ping 한두 번으로 판단하지 않는다#

다음처럼:

Reply
Reply
Reply
Reply

가 네 번 왔다고 해서 장시간 Network 품질이 완벽하다고 볼 수 없습니다.

간헐적인:

Packet Loss

Jitter

Latency Spike

가 있을 수 있습니다.

특히 지속 연결이나 실시간 장비에서는 짧은 Ping 검사보다 장시간 Monitoring과 실제 Service Traffic 분석이 더 중요할 수 있습니다.

26장 실제 현장 사례 — Ping은 되지만 TCP 연결이 Timeout#

구성:

Device
192.168.20.30

Server
192.168.100.20:8000

Device에서:

ping 192.168.100.20

정상입니다.

하지만 Application은:

Connection Timeout

입니다.

26.1 Client Capture#

SYN
SYN Retransmission
SYN Retransmission

SYN/ACK은 없습니다.

26.2 Server Capture#

Server에서는 SYN이 보이지 않습니다.

문제 범위는:

Device
↓
Network
↓
Server 이전

으로 좁혀집니다.

26.3 Firewall Log#

Source
192.168.20.30

Destination
192.168.100.20

TCP
8000

Action
DROP

이 발견됐다고 가정합니다.

이제:

Ping O
TCP 8000 X

의 원인을 설명할 수 있습니다.

ICMP와 TCP가 서로 다른 Policy를 적용받고 있었던 것입니다.

27장 실제 현장 사례 — Ping은 되고 Connection Refused#

이번에는:

ping
O

이고:

TCP Connection
Connection Refused

입니다.

Packet Capture:

SYN
↓
RST

Server에서 확인:

TCP 8000
LISTEN 없음

원인은 Network보다 Server Service였습니다.

28장 실제 현장 사례 — TCP 연결은 되는데 인증 실패#

흐름:

Ping
O

TCP 443
O

TLS
O

HTTP
401

입니다.

이 경우:

Network 장애

라고 보기 어렵습니다.

확인할 것은:

Token

Credential

Device Registration

Permission

입니다.

29장 실제 현장 사례 — HTTP 500#

다음 흐름입니다.

Ping
O

TCP
O

TLS
O

HTTP Request
O

HTTP 500

Server Log:

Database Connection Timeout

입니다.

문제 위치는:

Device → Network

가 아니라:

Application → Database

영역입니다.

30장 서비스가 안 된다를 계층별로 표현하자#

다음 흐름이 유용합니다.

Link
↓
VLAN
↓
IP
↓
Routing
↓
TCP / UDP
↓
TLS
↓
Authentication
↓
Application
↓
Database
↓
업무 처리

장애 분석의 목적은 이 흐름에서:

마지막 정상 지점

과:

최초 실패 지점

을 찾는 것입니다.

31장 점검 순서 1 — Physical Link#

먼저:

Power

Cable

Connector

Link LED

Switch Port

를 확인합니다.

Ping이 되는 상황에서는 Physical Link가 완전히 끊어진 상태일 가능성은 낮지만 간헐적인 Link Flap이나 Error는 여전히 존재할 수 있습니다.

32장 점검 순서 2 — IP와 ARP#

확인:

IP Address

Subnet Mask

ARP / NDP

Duplicate IP

특히 응답한 장비가 실제 대상 장비인지 확인합니다.

33장 점검 순서 3 — Routing#

다른 Subnet이라면:

Default Gateway

Routing Table

Return Route

를 확인합니다.

34장 점검 순서 4 — TCP 또는 UDP#

TCP라면:

SYN

SYN/ACK

ACK

RST

Timeout

을 확인합니다.

UDP라면:

Datagram 송신

Receiver 도착

Port

Application 수신

을 봅니다.

35장 점검 순서 5 — Firewall과 ACL#

Source

Destination

Protocol

Port

Direction

Action

을 확인합니다.

가능하다면 추측보다 실제 Firewall Log를 봅니다.

36장 점검 순서 6 — Server Listening 상태#

TCP Service라면:

Process 실행?

Port LISTEN?

올바른 Interface Bind?

를 봅니다.

Linux 예:

ss -lnt

입니다.

37장 점검 순서 7 — TLS와 Application#

TCP Connection이 성공하면 다음으로:

TLS

Authentication

HTTP

API

Protocol

을 확인합니다.

38장 점검 순서 8 — Backend#

Application Request까지 정상적으로 들어왔다면:

Database

Cache

Message Queue

Storage

외부 API

등 Backend 의존성을 확인합니다.

39장 Ping 성공 이후의 진단 흐름#

실제 현장에서는 다음처럼 사용할 수 있습니다.

Ping 성공
↓
실제 대상 IP가 맞는가?
↓
Service Protocol은 TCP인가 UDP인가?
↓
Port는 맞는가?
↓
TCP라면 Handshake 성공?
↓
Firewall / ACL 허용?
↓
Server가 LISTEN?
↓
TLS 성공?
↓
Authentication 성공?
↓
Application 응답?
↓
Backend 정상?

이 흐름은 단순하지만 현장에서 매우 유용합니다.

40장 Linux에서 기본적으로 확인할 수 있는 명령#

Ping#

ping -c 4 192.168.10.20

ARP / Neighbor#

ip neigh

Route#

ip route

TCP Port Test#

nc -vz 192.168.10.20 8000

HTTPS 확인#

curl -v https://192.168.10.20/

인증서 문제까지 시험 목적으로 별도로 확인해야 하는 경우 curl Option을 사용할 수 있지만, 운영 환경에서는 인증서 검증을 무시하는 방식을 정상 설정으로 사용해서는 안 됩니다.

41장 Packet Capture로 확인해야 할 때#

명령 결과만으로 구분하기 어려우면 Packet Capture를 사용합니다.

예:

tcpdump -n -i eth0 'host 192.168.10.20'

특정 TCP Port라면:

tcpdump -n -i eth0 'host 192.168.10.20 and tcp port 8000'

처럼 범위를 좁힐 수 있습니다.

41.1 TCP에서 확인하는 순서#

SYN이 나갔는가?

SYN/ACK이 오는가?

RST가 오는가?

Handshake는 완료되는가?

Data가 나가는가?

Response가 오는가?

입니다.

42장 증상별 판단 기준#

증상 우선 확인
Ping도 안 됨 Link·VLAN·IP·Route·ICMP Policy
Ping O, TCP Timeout Firewall·Routing·Return Path·Server
Ping O, Connection Refused Service Port·LISTEN·Reject Policy
TCP O, TLS 실패 Certificate·TLS Version·SNI
TLS O, HTTP 401 인증 정보
HTTP 403 권한·정책
HTTP 404 API URL·Version
HTTP 500 Application·Backend
HTTP 503 Service·Backend·부하
IP 접속 O, Hostname X DNS
짧은 Ping O, 실서비스 불안정 Loss·Latency·MTU·Load

43장 Ping 결과를 과신하면 안 되는 이유#

43.1 Ping은 Service Port를 확인하지 않는다#

Ping O

TCP 8000 X

가능합니다.

43.2 Ping은 Application을 확인하지 않는다#

Ping O

TCP O

Application X

가능합니다.

43.3 Ping은 인증을 확인하지 않는다#

Ping O

HTTPS O

Authentication X

가능합니다.

43.4 Ping은 Backend를 확인하지 않는다#

Ping O

API Server O

Database X

가능합니다.

44장 자주 발생하는 잘못된 판단#

44.1 Ping이 되니까 Network는 정상이다#

너무 넓은 결론입니다.

더 정확하게는:

해당 ICMP Echo Traffic의 왕복 연결성이 확인됐다.

정도로 표현하는 것이 좋습니다.

44.2 SYN/ACK이 없으니 Server Service가 죽었다#

단정할 수 없습니다.

중간 Firewall, Route, Return Path 등의 문제일 수도 있습니다.

44.3 Connection Refused니까 Firewall이 막았다#

반드시 그렇지 않습니다.

Destination Host가 닫힌 Port에 대해 RST를 보낸 경우도 흔합니다.

44.4 TCP 연결이 됐으니 Application은 정상이다#

아닙니다.

TLS, Authentication, API, Database가 이후에 실패할 수 있습니다.

44.5 Port만 열어주면 해결된다#

Security Policy는 필요한 Source·Destination·Protocol·Port만 최소한으로 허용해야 합니다.

무작정 전체 Port를 개방하는 것은 올바른 장애 대응이 아닙니다.

45장 방화벽 문제를 확인할 때 좋은 접근#

잘못된 방식:

안 되니까 Firewall을 전부 해제해보자.

보다:

Source
192.168.20.30

Destination
192.168.100.20

Protocol
TCP

Port
8000

이라는 정확한 Flow를 정의합니다.

그다음:

이 Flow가 어느 Policy에 Matching되는가?

를 확인합니다.

장애 분석과 보안 모두에 더 좋은 방법입니다.

46장 재부팅 전에 현재 상태를 기록한다#

Server Service가 문제라고 의심되더라도 바로 재시작하지 않는 것이 좋습니다.

먼저:

Process 상태

Listening Port

Socket 상태

CPU

Memory

Log

현재 Connection

을 확인합니다.

재시작하면 중요한 증거가 사라질 수 있기 때문입니다.

47장 현장에서 담당자에게 전달해야 할 정보#

단순히:

Ping은 되는데 안 됩니다.

보다 다음처럼 전달하는 것이 좋습니다.

Device
DEVICE-01

Source IP
192.168.20.30

Destination
192.168.100.20

Protocol
TCP

Destination Port
8000

Ping
정상

TCP Test
Timeout

Client Capture
SYN 반복, SYN/ACK 없음

Server Capture
SYN 미수신

Firewall Log
TCP 8000 DROP

이 정도면 담당자가 훨씬 빠르게 문제를 이해할 수 있습니다.

48장 범용 현장 체크리스트#

단계 확인
1 올바른 대상 IP인가
2 ARP/NDP Mapping은 맞는가
3 IP 충돌은 없는가
4 실제 Protocol은 TCP인가 UDP인가
5 정확한 Port인가
6 TCP Handshake가 되는가
7 Firewall·ACL은 허용하는가
8 NAT는 정상인가
9 Service가 LISTEN하는가
10 올바른 Interface에 Bind되었는가
11 TLS는 정상인가
12 인증·권한은 정상인가
13 Application은 정상인가
14 Database·Backend는 정상인가
15 Log와 Packet Capture가 같은 사실을 보여주는가

49장 자기 점검#

49.1 Ping이 성공하면 무엇을 알 수 있는가#

해당 시점에 ICMP Echo Request와 Reply가 목적지와 왕복할 수 있었다는 중요한 연결성 정보를 얻을 수 있습니다.

TCP·UDP Service나 Application까지 정상이라는 뜻은 아닙니다.

49.2 Ping은 되는데 TCP Connection이 Timeout이라면 무엇을 볼까#

다음 항목을 확인합니다.

Destination Port

Firewall

ACL

Routing

Return Path

Server 상태

Packet Capture에서 SYN과 SYN/ACK의 위치를 확인하면 범위를 더 좁힐 수 있습니다.

49.3 Connection Refused가 발생하면 무엇을 먼저 볼까#

Server의 해당 Port에 Service가 Listen 중인지 확인합니다.

필요하면 Firewall이나 중간 장비가 Reject를 생성했는지도 함께 확인합니다.

49.4 TCP 443까지 연결되는데 HTTPS가 실패한다면 무엇을 볼까#

TLS Certificate, TLS Version, SNI, 인증, HTTP Application을 확인합니다.

49.5 HTTP 500이 돌아왔다면 Network부터 다시 확인해야 할까#

HTTP 응답이 실제 Server에서 돌아왔다면 Request가 상당 부분 정상적으로 전달됐다는 중요한 증거입니다.

우선 Application Log와 Backend 상태를 확인하는 것이 좋습니다.

50장 이 글을 마치며#

Ping은 되는데 장비 통신은 안 된다는 상황은 특별하거나 이상한 현상이 아닙니다.

두 통신이 확인하는 범위가 다르기 때문입니다.

Ping은:

ICMP Echo

를 확인합니다.

실제 Service는:

TCP 또는 UDP
↓
Port
↓
TLS
↓
Authentication
↓
Application
↓
Backend

같은 더 많은 단계를 통과할 수 있습니다.

따라서 다음과 같이 생각해야 합니다.

Ping 성공
↓
IP 연결성에 대한 하나의 증거 확보
↓
실제 Protocol 확인
↓
실제 Port 확인
↓
Firewall / ACL
↓
TCP / UDP 상태
↓
TLS
↓
Authentication
↓
Application
↓
Database / Backend

특히 다음 네 가지를 기억하면 됩니다.

Ping 성공은 해당 ICMP Traffic이 왕복했다는 의미이지 서비스 전체가 정상이라는 의미가 아닙니다.

TCP나 UDP는 ICMP와 별도의 Protocol이므로 서로 다른 Firewall·ACL 정책을 적용받을 수 있습니다.

TCP 연결이 성공해도 TLS·인증·Application·Database에서 장애가 발생할 수 있습니다.

장애 분석은 “Ping이 된다”에서 끝나는 것이 아니라 실제 업무 Traffic이 어느 단계까지 성공하는지 확인하는 과정입니다.

결국 현장에서 중요한 질문은:

Ping이 되는가?

하나가 아닙니다.

더 중요한 질문은:

실제 장비 Traffic이 마지막으로 정상 확인된 지점은 어디이고, 처음 실패하는 지점은 어디인가?

입니다.

이 질문을 기준으로 접근하면 Ping은 되는데 안 됩니다라는 모호한 장애를 Network, Transport, Security, Application, Backend 중 어느 영역의 문제인지 빠르게 좁힐 수 있습니다.

이 페이지의 목차