Connection Refused·Timeout·Reset은 무엇이 다른가

Connection Refused·Timeout·Reset은 무엇이 다른가#

1장 “연결이 안 됩니다”는 세 가지가 전혀 다르다#

1.1 사용자에게는 모두 같은 증상으로 보인다#

현장 장비가 Server에 연결되지 않는다고 가정해보겠습니다.

사용자는 보통 다음과 같이 말합니다.

장비가 연결되지 않습니다.

하지만 Application Log에는 서로 다른 오류가 나타날 수 있습니다.

Connection Refused

Connection Timeout

Connection Reset

겉으로는 모두:

연결 실패

이지만 TCP 관점에서는 전혀 다른 사건입니다.

1.2 오류 문구보다 Packet 흐름을 봐야 한다#

세 가지를 매우 단순화하면 다음과 같습니다.

Connection Refused
→ 연결 요청에 즉시 거부 응답

Connection Timeout
→ 기다렸지만 필요한 응답이 오지 않음

Connection Reset
→ RST로 연결이 강제로 종료됨

따라서 장애 분석에서는:

어떤 Error Message가 떴는가?

와 함께:

실제 Packet에서는 무엇이 오갔는가?

를 확인해야 합니다.

2장 정상 TCP 연결부터 다시 보자#

2.1 TCP 연결의 기본 흐름#

정상적인 TCP Connection은 일반적으로 다음 과정으로 시작합니다.

Client                         Server

SYN
─────────────────────────────→

                         SYN/ACK
←─────────────────────────────

ACK
─────────────────────────────→

        ESTABLISHED

이것이 3-Way Handshake입니다.

따라서 연결 장애를 분석할 때 가장 먼저 보는 것은:

SYN은 나갔는가?

Server까지 도착했는가?

SYN/ACK이 돌아왔는가?

RST가 왔는가?

아무 응답도 없는가?

입니다.

3장 Connection Refused는 무엇인가#

3.1 연결 요청이 즉시 거부된 상황#

다음 흐름을 생각해보겠습니다.

Client                         Server

SYN
─────────────────────────────→

                         RST
←─────────────────────────────

Client는 Server까지 연결을 시도했습니다.

그리고 상대방으로부터 즉시 연결을 받아들일 수 없다는 응답을 받았습니다.

Application에서는 흔히:

Connection refused

와 같은 오류로 나타납니다.

3.2 가장 흔한 원인 — Port가 열려 있지 않다#

예를 들어 Client가:

192.168.10.100:8000

으로 연결을 시도합니다.

하지만 Server에서:

TCP 8000
LISTEN 없음

이라면 운영체제가 RST를 반환할 수 있습니다.

즉:

SYN
↓
Destination Host 도착
↓
해당 Port를 받는 Socket 없음
↓
RST

입니다.

3.3 그래서 Refused는 오히려 중요한 단서다#

Connection Refused가 발생했다는 것은 많은 경우:

아예 아무것도 안 갔다.

보다 더 많은 정보를 줍니다.

예를 들어 다음 가능성이 높아집니다.

Destination까지 Packet이 도달했다.

상대 TCP Stack 또는 중간 장비가 응답했다.

따라서 우선 확인할 것은:

Service Process

Listening Port

Bind Address

Server Firewall

중간 장비 Reject Policy

입니다.

4장 Connection Refused와 RST는 어떤 관계인가#

4.1 Refused는 사용자에게 보이는 결과다#

TCP Packet에는:

Connection Refused

라는 Flag가 존재하지 않습니다.

실제로 Packet에서 보는 것은:

RST

입니다.

즉 일반적인 경우:

SYN
↓
RST
↓
Application
"Connection Refused"

같은 관계가 만들어집니다.

4.2 모든 RST가 Connection Refused는 아니다#

중요합니다.

RST는 이미 연결된 TCP Session에서도 나타날 수 있습니다.

예:

SYN
↓
SYN/ACK
↓
ACK
↓
Data
↓
RST

이런 경우에는:

Connection Reset

으로 보일 수 있습니다.

따라서:

RST는 TCP Reset Packet이고, Refused와 Reset은 그것이 어떤 상황에서 발생했는지를 Application에서 표현한 결과라고 이해하면 좋습니다.

5장 Connection Timeout은 무엇인가#

5.1 기다렸지만 응답이 오지 않는 상황#

다음 흐름을 생각해보겠습니다.

Client                         Server

SYN
─────────────────────────────→

        아무 응답 없음

SYN Retransmission
─────────────────────────────→

        아무 응답 없음

SYN Retransmission
─────────────────────────────→

        Timeout

Client는 연결을 시도했지만 필요한 응답을 받지 못했습니다.

결국 일정 시간 후:

Connection Timeout

으로 실패합니다.

5.2 Timeout은 원인이 아니라 결과다#

Timeout이 발생했다고 다음과 같이 단정하면 안 됩니다.

Server가 죽었다.

가능한 원인은 매우 많습니다.

잘못된 Destination IP

Routing 오류

VLAN 문제

Firewall DROP

ACL DROP

Server Down

Return Path 문제

Packet Loss

Network 장애

등입니다.

Timeout은 단지:

정해진 시간 안에 필요한 응답을 받지 못했다.

라는 결과입니다.

6장 DROP과 REJECT는 다르다#

6.1 DROP#

Firewall이 Packet을 조용히 버린다고 가정합니다.

Client
SYN
──────→ Firewall

          DROP

Server에는 전달되지 않음

Client는 아무 응답도 받지 못합니다.

결과:

SYN 재전송
↓
대기
↓
Timeout

이 될 수 있습니다.

6.2 REJECT#

Firewall이 요청을 명시적으로 거부하도록 설정되어 있다면 조건에 따라 TCP RST 같은 응답을 생성할 수도 있습니다.

Client
SYN
──────→ Firewall

Firewall
RST
←──────

이 경우 Client는 Timeout까지 기다리지 않고 빠르게 실패할 수 있습니다.

6.3 현장에서는 둘을 구분해야 한다#

따라서:

연결이 안 된다.

고 할 때 다음을 봅니다.

아무 응답이 없는가?

RST가 오는가?

ICMP 오류가 오는가?

이 차이가 장애 범위를 크게 줄여줍니다.

7장 Connection Reset은 무엇인가#

7.1 연결이 강제로 중단된 상황#

예를 들어 정상적으로 TCP Connection이 만들어졌다고 하겠습니다.

SYN
↓
SYN/ACK
↓
ACK
↓
ESTABLISHED

이후 Data를 주고받다가:

RST

가 발생합니다.

Application에서는 흔히:

Connection reset by peer

같은 오류를 볼 수 있습니다.

7.2 FIN과 RST는 다르다#

정상적인 TCP 종료는 일반적으로 FIN을 사용합니다.

FIN
↓
ACK
↓
FIN
↓
ACK

RST는 다릅니다.

RST
↓
Connection 즉시 중단

입니다.

즉:

FIN
→ 정상적인 종료 절차

RST
→ 즉각적인 Reset

으로 이해할 수 있습니다.

8장 RST는 누가 보냈는지가 중요하다#

Packet Capture에서 RST를 발견했다고 가정합니다.

가장 먼저:

Source IP가 누구인가?

를 봅니다.

가능한 Sender는:

Client

Server

Firewall

Load Balancer

Proxy

기타 중간 Network 장비

일 수 있습니다.

따라서:

RST 발견
=
Server Application 문제

라고 바로 판단하면 안 됩니다.

9장 Server가 RST를 보낼 수 있는 상황#

9.1 닫힌 Port#

가장 대표적인 경우입니다.

Client
SYN
──────→ Server:8000

Server
TCP 8000 LISTEN 없음

RST
←──────

9.2 Application이 연결을 강제 종료#

Application이나 OS의 Socket 처리 방식에 따라 Connection을 정상 FIN이 아닌 RST로 종료할 수도 있습니다.

9.3 존재하지 않는 Connection에 Packet이 도착#

TCP Stack이 유효한 Connection으로 인식할 수 없는 Segment를 받았을 때 조건에 따라 RST를 보낼 수 있습니다.

10장 중간 Network 장비가 RST를 만들 수도 있다#

Stateful Firewall이나 Load Balancer가 Connection 상태를 관리한다고 가정합니다.

Client
↓
Firewall
↓
Server

Firewall Policy나 Session 상태에 따라 중간 장비가 TCP Reset을 생성할 수도 있습니다.

예:

Session Timeout

Security Policy

Protocol Validation

Load Balancer 정책

등입니다.

따라서 Packet Capture 위치도 중요합니다.

11장 세 오류를 Packet으로 비교하자#

11.1 정상#

SYN
→

←
SYN/ACK

ACK
→

11.2 Connection Refused의 대표적인 패턴#

SYN
→

←
RST

11.3 Connection Timeout의 대표적인 패턴#

SYN
→

응답 없음

SYN
→

응답 없음

11.4 Connection Reset의 대표적인 패턴#

SYN
→

←
SYN/ACK

ACK
→

DATA
→

←
RST

이 패턴을 이해하면 Application Error Message를 훨씬 쉽게 해석할 수 있습니다.

12장 Connection Refused가 발생하면 어디부터 볼까#

12.1 Server Listening Port#

Linux에서는:

ss -lnt

특정 Port:

ss -lnt | grep ':8000'

처럼 확인할 수 있습니다.

예:

LISTEN
0.0.0.0:8000

이면 해당 Port가 Listening 중이라는 중요한 증거입니다.

12.2 Bind Address도 확인한다#

다음은 다릅니다.

127.0.0.1:8000

과:

0.0.0.0:8000

Application이 127.0.0.1에만 Bind되어 있으면 외부 장비에서는 접속할 수 없습니다.

따라서:

Port가 LISTEN이다.

만 보지 말고:

어느 IP에서 LISTEN하는가?

까지 봐야 합니다.

13장 Process가 실행 중이라고 Service가 정상인 것은 아니다#

Application Process가 살아 있다고 가정합니다.

process running

하지만 Port는:

LISTEN 없음

일 수 있습니다.

가능한 원인:

Application 초기화 실패

Bind 실패

Port 설정 오류

다른 Process의 Port 선점

Application 내부 오류

등입니다.

따라서:

Process 상태

와:

Socket 상태

를 별도로 확인해야 합니다.

14장 Timeout이면 Capture 위치를 바꿔가며 본다#

14.1 Client에서는 SYN이 보인다#

Client Capture

SYN
O

SYN/ACK
X

이 사실만으로 Server가 SYN을 받았는지는 알 수 없습니다.

14.2 Server에서 SYN이 안 보인다#

Server Capture

SYN
X

이라면 문제 범위는:

Client
↓
Switch
↓
Router
↓
Firewall
↓
Server

사이입니다.

확인 대상:

VLAN

Routing

Firewall

ACL

NAT

VPN

등입니다.

14.3 Server에서는 SYN이 보인다#

Server Capture:

SYN
O

인데 SYN/ACK이 나가지 않는다면:

Listening Service

Server Firewall

TCP Stack

Server Resource

등을 확인합니다.

15장 Server에서 SYN/ACK이 나갔는데 Client에 안 온다면#

Server Capture:

SYN
O

SYN/ACK
O

Client Capture:

SYN
O

SYN/ACK
X

이라면 Return Path 영역을 확인해야 합니다.

Server
↓
Firewall
↓
Router
↓
Client

확인:

Return Route

Stateful Firewall

NAT

VPN

중간 ACL

등입니다.

16장 Timeout은 MTU 문제 하나로 설명하면 안 된다#

원문처럼 Timeout 원인을:

MTU 불일치

부터 우선적으로 보는 것은 적절하지 않습니다.

TCP Connection 자체의 SYN에 응답이 없는 상황이라면 보통:

Route

Firewall

Server 상태

Return Path

Destination 오류

같은 항목을 먼저 확인합니다.

MTU·Path MTU 문제는 Connection 이후 특정 크기의 데이터에서 이상이 발생할 때 더 관련성이 높을 수 있습니다.

17장 Connection이 된 뒤 Timeout이 발생할 수도 있다#

Timeout은 Connection 수립 단계에만 발생하는 것은 아닙니다.

예:

TCP Connection
성공

Request
전송

Response
없음

Read Timeout

일 수도 있습니다.

이 경우 Network Connection은 만들어졌지만:

Server Application 응답 지연

Backend Timeout

Database Timeout

상대 Application 정지

중간 Session 문제

등을 확인해야 합니다.

18장 Connect Timeout과 Read Timeout을 구분하자#

18.1 Connect Timeout#

TCP Connection 자체를
정해진 시간 안에 만들지 못함

대표적으로:

SYN
↓
응답 없음

같은 상황과 관련됩니다.

18.2 Read Timeout#

Connection은 이미 만들어졌습니다.

ESTABLISHED
↓
Request
↓
Response 대기
↓
Timeout

입니다.

이 차이를 모르고:

Timeout
=
Network 장애

라고 하면 잘못된 방향으로 분석할 수 있습니다.

19장 Application Timeout도 따로 존재한다#

예를 들어 다음 구조입니다.

Client
↓
TCP 정상
↓
HTTP 정상
↓
Application
↓
Database

Database가 30초 동안 응답하지 않는다면 Application이:

DB Timeout

을 발생시킬 수 있습니다.

Client에서는:

HTTP 500

HTTP 504

Read Timeout

등으로 나타날 수도 있습니다.

따라서 Timeout이라는 단어만 보고 TCP 문제라고 판단하면 안 됩니다.

20장 CLOSE_WAIT는 무엇인가#

TCP 종료와 관련하여 많이 만나는 상태입니다.

상대방이 FIN을 보냈다고 가정합니다.

Remote
FIN
──────→ Local

Local TCP Stack은 이를 받고 ACK를 보냅니다.

이후 Local Socket은:

CLOSE_WAIT

상태에 있을 수 있습니다.

20.1 CLOSE_WAIT가 의미하는 것#

쉽게 말하면:

상대는 자신의 전송을 끝냈고, 이제 Local Application이 Socket을 닫기를 기다리는 상태

입니다.

따라서 CLOSE_WAIT가 장시간 계속 증가한다면:

Application Socket close 처리

를 우선 확인해야 합니다.

21장 CLOSE_WAIT가 많으면 Network부터 보지 않는다#

예:

10:00
CLOSE_WAIT 100

10:10
CLOSE_WAIT 500

10:20
CLOSE_WAIT 1500

처럼 계속 증가합니다.

동시에:

File Descriptor 증가

Memory 증가

새 Connection 실패

가 보인다면 Application Resource Leak 가능성을 확인해야 합니다.

Cable 교체나 VLAN 변경이 직접적인 해결책이 아닐 수 있습니다.

22장 TIME_WAIT는 무엇인가#

정상 TCP 종료 과정에서 Connection을 적극적으로 종료한 쪽은 일정 시간:

TIME_WAIT

상태를 유지할 수 있습니다.

이 상태는 TCP의 정상적인 안전장치입니다.

22.1 왜 TIME_WAIT가 필요한가#

대표적인 이유는:

마지막 ACK가 유실됐을 때 대응

이전 Connection의 지연된 Segment가
새 Connection에 섞이는 것 방지

등입니다.

따라서:

TIME_WAIT 존재
=
장애

는 아닙니다.

23장 TIME_WAIT가 많다고 Connection Leak이라고 하지 않는다#

짧은 TCP Connection이 매우 많이 생성되고 종료되는 Service라면 TIME_WAIT가 많이 나타날 수 있습니다.

확인해야 할 것은:

Connection 생성률

Ephemeral Port 사용

File Descriptor

Application 설계

Connection Pool

Persistent Connection 사용 여부

입니다.

TIME_WAIT 개수 하나만 보고 Kernel 설정부터 변경해서는 안 됩니다.

24장 Connection Leak은 무엇인가#

Connection Leak은 Application이 더 이상 필요하지 않은 Connection Resource를 적절히 정리하지 않는 문제입니다.

예:

Connection 생성
↓
사용
↓
Exception
↓
close() 누락
↓
Resource 남음

이런 상황이 반복될 수 있습니다.

대표적인 징후:

CLOSE_WAIT 지속 증가

File Descriptor 증가

Memory 증가

새 Connection 실패

등입니다.

25장 TIME_WAIT와 CLOSE_WAIT는 완전히 다르다#

상태 의미 우선 확인
TIME_WAIT 정상 종료 뒤 Connection 정보 유지 Connection 생성 패턴
CLOSE_WAIT 상대 FIN 수신 후 Local Application close 대기 Application Socket 종료
FIN_WAIT_1 FIN 전송 후 확인 대기 Packet·상대 상태
FIN_WAIT_2 FIN 확인 후 상대 FIN 대기 상대 Application 종료

특히:

TIME_WAIT 많음

과:

CLOSE_WAIT 많음

을 같은 의미로 보면 안 됩니다.

26장 Connection Reset이 반복되면 어디를 볼까#

26.1 누가 RST를 보내는지 확인#

가장 먼저:

RST Source

를 봅니다.

예:

Server → Client
RST

인지:

Firewall → Client
RST

인지 확인합니다.

26.2 발생 시점도 중요하다#

Handshake 시작 직후#

SYN
↓
RST

이라면 Port·Listening·Reject Policy를 봅니다.

Connection 성립 직후#

Handshake
↓
Data
↓
RST

이라면 Application Protocol이나 Policy를 확인합니다.

일정 Idle 시간 후#

ESTABLISHED
↓
오랫동안 Traffic 없음
↓
RST 또는 Connection 오류

라면:

Firewall Session Timeout

Load Balancer Timeout

Application Idle Timeout

등도 확인합니다.

27장 Protocol 오류도 RST의 원인이 될 수 있다#

예를 들어 특정 산업 장비가 정해진 Binary Protocol을 기대한다고 가정합니다.

Client가 잘못된 형식의 Payload를 전송합니다.

TCP Connection
O

Payload
Invalid

Application 정책에 따라 Connection을 즉시 닫거나 Reset할 수도 있습니다.

따라서 RST 발생 시:

Protocol Version

Payload Format

Authentication

Session 상태

도 확인합니다.

28장 HTTP Keep-Alive와 TCP Keepalive는 다르다#

이 두 용어는 이름 때문에 혼동하기 쉽습니다.

HTTP Keep-Alive#

여러 HTTP Request에서 하나의 TCP Connection을 재사용하는 것과 관련됩니다.

TCP Keepalive#

오랫동안 Traffic이 없는 TCP Connection에서 Peer 상태를 확인하기 위한 TCP Stack 기능입니다.

둘은 목적과 동작 계층이 다릅니다.

29장 Firewall Session Timeout도 확인한다#

장시간 연결되는 장비가 있다고 하겠습니다.

Controller
⇄
Server

양쪽 Application은 Connection이 살아 있다고 생각합니다.

그런데 중간 Firewall이:

Idle Session Timeout

으로 Connection 상태를 제거합니다.

나중에 Controller가 데이터를 전송하면 예상하지 못한:

Timeout

Reset

재연결

이 발생할 수 있습니다.

장시간 Persistent Connection을 사용하는 시스템에서는:

Client Timeout

Server Timeout

Firewall Timeout

Load Balancer Timeout

을 함께 비교해야 합니다.

30장 NAT도 Connection 상태와 연결된다#

NAT 환경:

Device
192.168.10.20
↓
NAT
↓
Server

NAT 장비는 TCP Session Mapping을 관리합니다.

따라서:

Session Timeout

Port Mapping

Return Traffic

문제가 연결 장애와 연결될 수 있습니다.

다만 무조건 NAT를 의심하기보다 Packet Capture와 Session Table을 통해 확인합니다.

31장 VLAN 장애와 Refused를 혼동하지 않는다#

예를 들어 Client의 SYN 자체가 잘못된 VLAN 때문에 Server에 도달하지 못한다면 일반적으로:

SYN
↓
응답 없음
↓
Timeout

형태로 나타날 가능성이 있습니다.

반면 Connection Refused는 대개 누군가 명시적인 거부 응답을 돌려줬다는 의미입니다.

따라서:

VLAN 문제
→ Connection Refused

라고 단순하게 연결하면 안 됩니다.

32장 Connection Refused 사례#

Client:

10.0.0.20

Server:

10.0.0.100:8000

Client Capture:

10:00:00.001
10.0.0.20:50100 → 10.0.0.100:8000
SYN

10:00:00.003
10.0.0.100:8000 → 10.0.0.20:50100
RST,ACK

Server 확인:

ss -lnt | grep ':8000'

결과 없음.

이 경우 Service가 해당 Port를 Listen하지 않는 것이 유력한 원인입니다.

33장 Connection Timeout 사례#

Client Capture:

10:00:00 SYN
10:00:01 SYN Retransmission
10:00:03 SYN Retransmission

Server Capture:

SYN 없음

Firewall Log:

SRC=10.0.0.20
DST=10.0.0.100
TCP DPT=8000
DROP

이라면 원인을 매우 명확하게 좁힐 수 있습니다.

34장 Connection Reset 사례#

정상 Handshake:

SYN
SYN/ACK
ACK

후:

Client → Server
Application Data

Server → Client
RST

가 관찰됩니다.

Server Application Log:

Invalid protocol version
Closing connection

이 있다면 Network보다 Application Protocol 영역을 확인해야 합니다.

35장 Packet Capture는 양쪽에서 보면 훨씬 강력하다#

Client에서:

SYN 보냄

을 확인했습니다.

Server에서는:

SYN 없음

입니다.

그러면 두 지점 사이에서 문제를 찾습니다.

반대로:

Server
SYN 수신

SYN/ACK 전송

인데 Client가 못 받으면 Return Path로 범위를 좁힙니다.

36장 tcpdump로 특정 TCP Flow 확인하기#

허가된 환경에서:

sudo tcpdump -n -i eth0 'host 10.0.0.5 and tcp port 8000'

처럼 범위를 제한할 수 있습니다.

확인할 것은:

SYN

SYN/ACK

ACK

RST

FIN

Retransmission 패턴

입니다.

37장 ss로 현재 TCP 상태 확인하기#

Linux:

ss -tan

특정 Port:

ss -tan | grep ':8000'

Process까지 볼 권한이 있다면:

ss -tanp

등을 사용할 수 있습니다.

37.1 상태 개수를 보는 것도 도움이 된다#

예:

ESTABLISHED 500

CLOSE_WAIT 2

TIME_WAIT 120

과:

ESTABLISHED 50

CLOSE_WAIT 3000

TIME_WAIT 20

은 의미가 크게 다릅니다.

단순 총 Socket 수보다 상태별 분포와 시간에 따른 변화를 봅니다.

38장 netstat를 사용할 수도 있다#

환경에 따라:

netstat -an

등을 사용할 수 있습니다.

Linux에서는 ss가 더 일반적인 최신 도구인 경우가 많지만 Windows나 오래된 시스템에서는 netstat가 여전히 유용합니다.

중요한 것은 명령 이름보다:

LISTEN

ESTABLISHED

TIME_WAIT

CLOSE_WAIT

상태를 해석하는 것입니다.

39장 실습 — DROP과 REJECT 차이 확인하기#

반드시 격리된 시험 환경에서 수행합니다.

예를 들어 Test Server의 TCP 8080을 대상으로 Firewall Rule을 만들어볼 수 있습니다.

DROP:

iptables -A INPUT -p tcp --dport 8080 -j DROP

개념적으로:

SYN
↓
Firewall에서 버림
↓
응답 없음
↓
Timeout

이 발생할 수 있습니다.

39.1 REJECT#

시험 환경에서:

iptables -A INPUT -p tcp --dport 8081 \
  -j REJECT --reject-with tcp-reset

처럼 TCP Reset을 반환하도록 설정할 수 있습니다.

개념적으로:

SYN
↓
RST
↓
빠른 실패

를 관찰할 수 있습니다.

실험 후 Rule은 반드시 원상 복구합니다.

40장 실습에서는 Error Message와 Packet을 함께 기록한다#

단순히:

실패했다.

라고 기록하지 않습니다.

예:

Application
Connection timed out

Client Capture
SYN 3회
SYN/ACK 없음

Server Capture
SYN 없음

Firewall
DROP

처럼 기록합니다.

이렇게 하면:

Error Message
+
Packet
+
Device Log

의 관계를 이해할 수 있습니다.

41장 재부팅하기 전에 확보해야 할 것#

장비나 Server를 재부팅하면 일시적으로 정상화될 수도 있습니다.

하지만 동시에 중요한 증거가 사라질 수 있습니다.

재부팅 전 가능하다면:

Socket 상태

Application Log

Firewall Log

Packet Capture

Process 상태

Memory

CPU

Connection Count

등을 확보합니다.

42장 Connection Leak을 확인할 때 보는 자료#

Application Resource Leak을 의심한다면:

CLOSE_WAIT 수

File Descriptor 수

Process Memory

Thread 수

Connection 생성률

Connection 종료률

등을 같이 봅니다.

예:

CLOSE_WAIT 증가
+
FD 증가
+
Memory 증가

가 반복된다면 중요한 단서입니다.

43장 RST를 보안 공격으로 바로 판단하지 않는다#

TCP Reset Spoofing 같은 공격 기법이 존재하지만 현장에서 RST가 보인다는 이유만으로 공격을 의심해서는 안 됩니다.

일반적인 원인이 훨씬 많습니다.

Port Closed

Application Error

Protocol Error

Firewall Policy

Load Balancer

Session Timeout

등입니다.

보안 사고 판단에는 추가적인 증거가 필요합니다.

44장 안전과 개인정보를 함께 고려한다#

Packet Capture에는 다음 정보가 포함될 수 있습니다.

Device ID

차량번호

사용자 정보

Token

명령

내부 IP

따라서:

필요한 Host만

필요한 Port만

필요한 시간만

Capture하는 것이 좋습니다.

Capture File은 접근 권한과 보관 기간도 관리해야 합니다.

45장 장애별 우선 확인표#

현상 Packet에서 보일 수 있는 특징 우선 확인
Connection Refused SYN 후 RST LISTEN Port·Service·Reject Policy
Connect Timeout SYN 반복·응답 없음 Routing·Firewall DROP·Server·Return Path
Connection Reset 기존 연결에서 RST RST Sender·Application·Firewall
CLOSE_WAIT 증가 상대 FIN 수신 후 Local close 대기 Application Socket 처리
TIME_WAIT 증가 정상 종료 후 상태 유지 Connection 생성·종료 패턴
ESTABLISHED 장기 유지 Connection은 존재 실제 Traffic·Heartbeat·Timeout

46장 TCP 오류를 분석하는 기본 순서#

Application Error 확인
↓
Source / Destination IP 확인
↓
TCP Port 확인
↓
Client SYN 확인
↓
Server SYN 수신 확인
↓
SYN/ACK 또는 RST 확인
↓
Return Path 확인
↓
Handshake 이후 Data 확인
↓
FIN / RST 확인
↓
Socket State 확인
↓
Application Log 확인

이 흐름을 따르면 단순한 Error Message에서 실제 장애 구간으로 이동할 수 있습니다.

47장 자주 발생하는 오해#

47.1 Connection Refused면 Network가 끊긴 것이다?#

오히려 상대 또는 중간 장비가 명시적인 응답을 보낸 경우가 많습니다.

Service Listening 상태를 먼저 확인합니다.

47.2 Timeout이면 무조건 Firewall이다?#

아닙니다.

Routing, Server Down, Return Path, 잘못된 IP 등 다양한 원인이 있습니다.

47.3 Reset이면 Server가 죽었다?#

아닙니다.

Application이나 Firewall, Load Balancer 등이 RST를 생성할 수 있습니다.

47.4 CLOSE_WAIT가 많으면 TIME_WAIT 설정을 줄이면 된다?#

아닙니다.

CLOSE_WAIT는 Local Application의 Socket 종료 처리를 확인해야 합니다.

47.5 TIME_WAIT가 많으면 Connection Leak이다?#

아닙니다.

정상적인 TCP 종료에서도 발생합니다.

Connection 생성 패턴과 실제 Resource 사용량을 함께 봐야 합니다.

48장 현장 담당자에게 전달할 정보#

다음처럼 전달하면 좋습니다.

장애 시각
10:31:20

Client
10.0.0.20

Server
10.0.0.100

TCP Port
8000

오류
Connection Timeout

Client Capture
SYN 반복
SYN/ACK 없음

Server Capture
SYN 없음

Firewall Log
TCP 8000 DROP

반대로:

연결 안 됨

이라고만 전달하면 다시 처음부터 확인해야 합니다.

49장 자기 점검#

49.1 Connection Refused의 대표적인 Packet 흐름은 무엇인가#

Client의 SYN에 대해 RST가 빠르게 돌아오는 형태입니다.

가장 먼저 해당 Port의 Listening 상태와 Reject Policy를 확인합니다.

49.2 Timeout에서 SYN이 반복된다는 것은 무엇을 의미하는가#

Client가 Connection을 계속 시도하고 있지만 필요한 응답을 받지 못하고 있다는 의미입니다.

Server 도착 여부와 중간 경로를 추가로 확인해야 합니다.

49.3 Connection Reset에서는 가장 먼저 무엇을 볼까#

RST를 누가 보냈는지와 Connection의 어느 시점에서 RST가 발생했는지를 확인합니다.

49.4 CLOSE_WAIT가 지속적으로 증가하면 무엇을 볼까#

Local Application이 상대 FIN을 받은 뒤 Socket을 정상적으로 닫는지 확인합니다.

49.5 TIME_WAIT가 많이 보인다는 것만으로 장애라고 볼 수 있는가#

아닙니다.

짧은 Connection이 많이 생성되는 Service에서는 정상적으로 많이 보일 수 있습니다.

실제 Port·Resource 고갈 여부와 Connection 생성률을 함께 확인해야 합니다.

50장 이 글을 마치며#

Connection Refused, Timeout, Reset은 모두:

연결이 안 됩니다.

라는 하나의 사용자 증상으로 표현될 수 있습니다.

하지만 Packet 수준에서는 전혀 다른 사건입니다.

Connection Refused의 대표적인 흐름은:

SYN
↓
RST

입니다.

Timeout의 대표적인 흐름은:

SYN
↓
응답 없음
↓
SYN Retransmission
↓
Timeout

입니다.

Connection Reset은:

정상 Connection
↓
통신
↓
RST
↓
강제 종료

와 같은 모습으로 나타날 수 있습니다.

따라서 Error Message를 본 뒤 바로 원인을 결정해서는 안 됩니다.

다음 순서가 중요합니다.

오류 문구 확인
↓
Packet Capture
↓
누가 SYN을 보냈는가?
↓
SYN은 어디까지 도착했는가?
↓
SYN/ACK 또는 RST가 있는가?
↓
누가 RST를 보냈는가?
↓
Socket 상태는 무엇인가?
↓
Application Log는 무엇을 말하는가?

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

Connection Refused는 대개 상대나 중간 장비가 연결 요청을 명시적으로 거부했다는 중요한 단서입니다.

Timeout은 원인이 아니라 정해진 시간 안에 필요한 응답을 받지 못했다는 결과입니다.

Connection Reset은 RST에 의해 Connection이 강제로 중단된 상황이며, RST Sender와 발생 시점이 중요합니다.

CLOSE_WAIT와 TIME_WAIT는 이름이 비슷해 보여도 전혀 다른 TCP 상태이며, 동일한 문제로 취급해서는 안 됩니다.

결국 TCP 장애를 제대로 분석하는 가장 좋은 방법은 Error Message를 외우는 것이 아니라:

어떤 Packet을 보냈고
어떤 Packet이 돌아왔으며
어느 지점에서 흐름이 달라졌는가?

를 확인하는 것입니다.

이 페이지의 목차