TCP 3-Way Handshake를 Packet으로 직접 분석하기

TCP 3-Way Handshake를 Packet으로 직접 분석하기#

1장 TCP 연결은 어디에서 시작될까#

1.1 Connection Timeout이라는 한 줄만으로는 원인을 알 수 없다#

주차관제 현장에서 결제단말이 중앙 Server에 연결되지 않는다고 가정해보겠습니다.

Application Log에는 다음과 같이 기록되어 있습니다.

2026-09-24 10:31:04
Connection Timeout
Server: 192.168.100.20:8000

이 정보만으로는 원인을 판단하기 어렵습니다.

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

장비 Application 문제

잘못된 Server IP

잘못된 TCP Port

VLAN 문제

Default Gateway 오류

Routing 문제

Firewall 차단

Server Down

Server에서 Service 미실행

Return Path 문제

이때 Packet Capture를 보면 중요한 질문에 답할 수 있습니다.

SYN은 실제로 나갔는가?

Server까지 도착했는가?

SYN/ACK가 돌아왔는가?

Client가 ACK를 보냈는가?

누군가 RST를 보냈는가?

TCP 연결 장애는 바로 이 세 개의 Packet에서 시작해 범위를 좁힐 수 있습니다.

1.2 정상적인 TCP 연결은 세 단계로 시작한다#

TCP Client가 Server에 연결할 때 일반적인 흐름은 다음과 같습니다.

Client                         Server

  │                              │
  │ SYN                          │
  ├─────────────────────────────→│
  │                              │
  │                     SYN, ACK │
  │←─────────────────────────────┤
  │                              │
  │ ACK                          │
  ├─────────────────────────────→│
  │                              │
  │       ESTABLISHED            │

이를 TCP 3-Way Handshake라고 합니다.

세 Packet은 단순한 인사말이 아닙니다.

양쪽 TCP Stack이:

Connection을 시작하고

각 방향의 Sequence Number를 동기화하고

TCP Option을 교환하고

상대방과 양방향 통신이 가능한지 확인하는

과정입니다.

2장 첫 번째 Packet — SYN#

2.1 Client가 Connection을 시작한다#

다음 환경을 가정해보겠습니다.

RFID Reader
10.0.0.5

Server
192.168.1.100

Server TCP Port
8000

Client가 Connection을 시작하면 첫 번째 TCP Segment에 SYN Flag가 설정됩니다.

10.0.0.5:50123
        ↓
192.168.1.100:8000

SYN

여기에서:

10.0.0.5
→ Source IP

50123
→ Source Port

192.168.1.100
→ Destination IP

8000
→ Destination Port

입니다.

2.2 Source Port와 Destination Port의 의미#

Server는 일반적으로 특정 Port에서 Client의 연결을 기다립니다.

예:

Server

TCP 8000
LISTEN

Client는 보통 임시 Source Port를 사용합니다.

예:

50123

따라서 하나의 연결을 보면:

10.0.0.5:50123
        ↕
192.168.1.100:8000

처럼 표현할 수 있습니다.

현장에서 Packet을 분석할 때는 IP만 보지 말고 Port까지 함께 확인하는 습관이 중요합니다.

2.3 SYN에는 Initial Sequence Number가 들어간다#

TCP는 Byte Stream의 위치를 관리하기 위해 Sequence Number를 사용합니다.

Connection을 시작할 때 Client는 자신의 Initial Sequence Number, 즉 ISN을 선택합니다.

설명을 단순화하기 위해 다음 값을 사용해보겠습니다.

Client ISN
1000

그러면 첫 번째 SYN은:

SYN
Seq = 1000

처럼 볼 수 있습니다.

실제 운영체제의 ISN은 이런 작은 숫자를 순서대로 단순 증가시키는 방식으로 이해하면 안 됩니다.

Packet 분석 도구 역시 사람이 보기 쉽게 Relative Sequence Number를 표시하는 경우가 많습니다.

3장 두 번째 Packet — SYN/ACK#

3.1 Server가 Client의 SYN을 받는다#

Server의 TCP Port 8000에서 정상적으로 Service가 대기 중이고 연결을 받아들일 수 있다면 Server가 응답합니다.

Client                         Server

SYN
Seq=1000
─────────────────────────────→

                         SYN,ACK
←─────────────────────────────

Server도 자신의 Initial Sequence Number를 선택합니다.

예:

Server ISN
3000

3.2 ACK 번호는 왜 Client ISN + 1일까#

Server의 Packet을 단순화하면 다음과 같습니다.

SYN = 1
ACK = 1

Seq = 3000
Ack = 1001

Client가 보낸 SYN의 Sequence Number가 1000이었기 때문에 Server는:

ACK = 1001

을 보냅니다.

TCP에서는 SYN 자체도 Sequence Number 공간에서 하나를 소비합니다.

따라서:

Client SYN
Seq 1000

Server
Ack 1001

이 되는 것입니다.

4장 세 번째 Packet — ACK#

4.1 Client가 Server의 SYN을 확인한다#

Client는 Server가 보낸:

SYN
Seq = 3000

을 확인합니다.

그리고 다음과 같이 ACK를 보냅니다.

ACK = 3001

전체 흐름을 다시 보면:

Client                               Server

SYN
Seq=1000
───────────────────────────────────→

                             SYN, ACK
                   Seq=3000 Ack=1001
←───────────────────────────────────

ACK
Ack=3001
───────────────────────────────────→

이 과정을 통해 양쪽이 서로의 Sequence Number 공간을 확인합니다.

4.2 언제 ESTABLISHED가 되는가#

TCP 내부 상태는 두 Endpoint에서 완전히 같은 순간에 바뀌는 것은 아닙니다.

일반적으로 Server는 마지막 ACK를 정상적으로 수신한 뒤 ESTABLISHED 상태로 들어가고, Client는 SYN/ACK을 확인하고 마지막 ACK를 보내면서 연결이 성립한 상태로 전환합니다.

사용자가 실제로 보는 수준에서는 다음처럼 이해해도 충분합니다.

SYN
↓
SYN/ACK
↓
ACK
↓
TCP Connection Established

이제 Application Data를 주고받을 수 있습니다.

5장 실제 Packet Capture를 읽어보자#

5.1 tcpdump에서 정상 Handshake#

다음은 이해를 위해 단순화한 예입니다.

10:00:00.000000
10.0.0.5.50123 > 192.168.1.100.8000
Flags [S]
seq 1000
win 64240
length 0

10:00:00.010000
192.168.1.100.8000 > 10.0.0.5.50123
Flags [S.]
seq 3000
ack 1001
win 28960
length 0

10:00:00.020000
10.0.0.5.50123 > 192.168.1.100.8000
Flags [.]
ack 3001
win 64240
length 0

tcpdump에서 Flag 표기를 읽으면:

[S]
→ SYN

[S.]
→ SYN + ACK

[.]
→ ACK

로 이해할 수 있습니다.

5.2 세 줄만 보고도 확인할 수 있는 정보#

첫 번째 Packet:

10.0.0.5.50123
→
192.168.1.100.8000

SYN

Client가 Server의 TCP 8000 Port로 연결을 시도했습니다.

두 번째 Packet:

192.168.1.100.8000
→
10.0.0.5.50123

SYN + ACK

Server가 SYN을 받았고 응답했습니다.

세 번째 Packet:

10.0.0.5.50123
→
192.168.1.100.8000

ACK

Client 역시 Server의 응답을 받았습니다.

따라서 적어도 Packet Capture 위치에서 보면:

양방향 IP 통신
+
TCP 8000 연결
+
3-Way Handshake

가 성립했다고 볼 수 있습니다.

6장 Wireshark에서 Handshake를 찾는 방법#

6.1 특정 TCP Port만 보고 싶을 때#

Wireshark Display Filter에서:

tcp.port == 8000

처럼 사용할 수 있습니다.

해당 Port와 관련된 TCP Traffic을 확인할 수 있습니다.

6.2 SYN Packet만 확인하고 싶을 때#

예를 들어 초기 SYN을 찾을 때는 상황에 맞는 TCP Flag Filter를 사용할 수 있습니다.

개념적으로 확인해야 하는 것은:

SYN = 1

ACK = 0

인 Packet입니다.

Wireshark UI에서는 TCP Header를 펼쳐 다음 Field를 직접 확인할 수도 있습니다.

Source Port

Destination Port

Sequence Number

Acknowledgment Number

Flags

Window

TCP Options

6.3 Relative Sequence Number에 주의한다#

Wireshark는 기본 설정에서 Sequence Number를 사람이 읽기 쉽게 상대적인 값으로 보여줄 수 있습니다.

실제 Wire상 Sequence Number가:

2841938721

이더라도 화면에서는:

Seq = 0

처럼 보일 수 있습니다.

이후 데이터는:

Seq = 1
Seq = 501
Seq = 1001

등으로 표시될 수 있습니다.

따라서:

왜 실제 Sequence Number가 항상 0이나 1부터 시작하지?

라고 오해하지 않아야 합니다.

실제 값과 Relative Sequence Number를 구분해야 합니다.

7장 SYN Packet에서는 TCP Option도 확인한다#

7.1 MSS#

MSS는 Maximum Segment Size입니다.

상대방에게:

나는 하나의 TCP Segment에서 이 정도 크기의 TCP Payload까지 받을 수 있다.

는 정보를 알려줍니다.

예:

MSS = 1460

Ethernet MTU 1500 환경에서 IPv4와 기본 TCP Header를 사용하는 전형적인 상황에서 자주 볼 수 있는 값입니다.

하지만 IPv6, TCP Option, Tunnel, 다른 MTU 환경에서는 조건이 달라질 수 있습니다.

7.2 Window Scale#

TCP Header의 기본 Window Field만으로 표현할 수 있는 범위를 확장하기 위한 Option입니다.

고속·고지연 Network에서는 큰 Receive Window가 필요할 수 있기 때문에 Window Scaling이 중요해질 수 있습니다.

Handshake 시 협상되는 Option이므로 연결된 뒤 갑자기 새로 활성화하는 방식으로 이해하면 안 됩니다.

7.3 SACK Permitted#

Selective Acknowledgment를 사용할 수 있다는 사실을 상대방에게 알립니다.

SACK Permitted

가 Handshake 과정에서 교환되었다면 이후 Packet Loss가 발생했을 때 Receiver가 자신이 받은 특정 데이터 범위를 더 구체적으로 알려주는 데 사용할 수 있습니다.

7.4 Timestamp#

TCP Timestamp Option을 사용하는 환경도 있습니다.

Packet Capture에서는:

TSval
TSecr

같은 Field를 볼 수 있습니다.

RTT 측정 등 여러 TCP 기능에 활용될 수 있습니다.

모든 TCP Connection이 동일한 Option을 사용하는 것은 아닙니다.

8장 Handshake를 볼 때 가장 먼저 확인해야 하는 것#

Packet을 열자마자 Sequence Number부터 볼 필요는 없습니다.

현장에서는 더 단순한 순서가 효과적입니다.

8.1 IP가 맞는가#

Source IP

Destination IP

를 확인합니다.

잘못된 Server IP로 연결하고 있는 경우 의외로 많습니다.

8.2 Port가 맞는가#

Source Port

Destination Port

를 봅니다.

특히 Server Port가 중요합니다.

예:

설정
Server Port 8000

실제 Service
TCP 8080

이라면 Network가 정상이어도 연결되지 않습니다.

8.3 SYN이 실제로 나가는가#

Application Log에는:

Connecting...

이라고 나오는데 Packet Capture에는 SYN이 전혀 없을 수도 있습니다.

이 경우 Network 밖보다 먼저:

Application 설정

Local Firewall

Routing Table

Socket 생성 오류

등 Client 내부를 확인해야 합니다.

9장 실패 패턴 1 — SYN만 반복된다#

9.1 Packet Capture#

다음과 같이 보인다고 하겠습니다.

10:00:00 SYN
10:00:01 SYN
10:00:03 SYN
10:00:07 SYN
...

SYN은 반복되지만 SYN/ACK이 없습니다.

9.2 무엇을 의미할까#

현재 Capture 위치에서는:

Client가 SYN을 전송하고 있다.

그러나 SYN/ACK은 관찰되지 않는다.

라는 사실까지만 확실히 말할 수 있습니다.

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

Server Down

Server IP 오류

Routing 문제

Firewall Drop

VLAN 문제

Return Route 문제

Server까지 SYN이 도착하지 않음

Server 응답이 중간에서 손실됨

따라서:

SYN만 보인다
=
Firewall 문제

라고 단정하면 안 됩니다.

10장 Capture 위치를 바꾸면 장애 지점을 좁힐 수 있다#

10.1 Client에서 SYN은 보인다#

첫 번째 확인:

Client Capture

SYN
O

SYN/ACK
X

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

10.2 Server에서도 Capture한다#

Server에서:

SYN
X

라면:

Client
↓
Network
↓
Server

사이에서 문제가 발생했습니다.

확인 영역은:

VLAN
Routing
Firewall
ACL
VPN
WAN

등으로 좁혀집니다.

10.3 Server에서는 SYN이 보인다#

Server Capture:

SYN
O

인데 Server가 SYN/ACK을 보내지 않는다면:

Service 상태

Listening Port

Server Firewall

TCP Stack

Server Resource

등을 확인할 수 있습니다.

이렇게 양쪽 Capture를 비교하는 것이 매우 강력한 진단 방법입니다.

11장 실패 패턴 2 — Server가 RST를 보낸다#

다음과 같은 Packet 흐름을 생각해보겠습니다.

Client                         Server

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

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

이 경우 SYN이 Server까지 도달했다는 중요한 정보를 얻을 수 있습니다.

11.1 대표적인 원인#

예를 들어 해당 Port에 아무 Service도 Listen하고 있지 않을 수 있습니다.

Server IP
정상

TCP Port
8000

Service
없음

이때 운영체제가 연결을 거부할 수 있습니다.

Application에서는 흔히:

Connection Refused

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

11.2 Timeout과 Refused는 큰 차이가 있다#

다음 두 상황을 구분해야 합니다.

SYN
↓
아무 응답 없음
↓
Timeout

과:

SYN
↓
RST
↓
Connection Refused

입니다.

두 번째 경우는 목적지 Host까지 Packet이 도착했다는 중요한 단서를 제공합니다.

따라서 Server Process와 Listening Port를 우선 확인할 수 있습니다.

12장 실패 패턴 3 — SYN/ACK이 중간까지만 온다#

조금 더 복잡한 경우입니다.

Server Capture에서는:

Client SYN
O

Server SYN/ACK
O

입니다.

하지만 Client Capture에서는:

SYN
O

SYN/ACK
X

입니다.

이 경우 Server가 응답을 만들었다는 사실은 확인됐습니다.

문제 범위는 Return Path 쪽으로 좁혀집니다.

Server
↓
Router
↓
Firewall
↓
WAN
↓
Client

확인 대상은:

Return Route

Firewall

ACL

NAT 상태

VPN

중간 Network

등입니다.

13장 실패 패턴 4 — SYN/ACK은 Client까지 왔는데 마지막 ACK가 없다#

Client Capture에서:

SYN
O

SYN/ACK
O

마지막 ACK
X

라면 Client가 SYN/ACK까지 받았다는 의미입니다.

이제 다음을 확인합니다.

Client TCP Stack

Local Firewall

Client Application 상태

Capture 누락 가능성

Client Resource

단순히 Return Route 문제라고 할 수는 없습니다.

SYN/ACK이 Client에 도착했다면 Return Path가 적어도 그 Packet에 대해서는 동작한 것입니다.

14장 실패 패턴 5 — 3-Way Handshake는 성공했는데 Application이 실패한다#

가장 중요한 현장 패턴 중 하나입니다.

SYN
↓
SYN/ACK
↓
ACK
↓
ESTABLISHED

까지 정상입니다.

그런데 관제 프로그램에서는:

Login Failed

Authentication Timeout

Invalid Protocol

No Response

등이 나타납니다.

이 경우 TCP 연결 자체보다 Application Layer를 확인해야 합니다.

14.1 확인해야 할 항목#

Application Protocol

TLS Handshake

Authentication

API Path

Protocol Version

Device ID

Application Timeout

Server Log

등입니다.

즉:

TCP Connection 성공
≠
Application 정상

입니다.

15장 TLS를 사용하는 경우 Handshake가 두 번처럼 보일 수 있다#

HTTPS 같은 서비스를 사용하는 경우:

TCP 3-Way Handshake
↓
TLS Handshake
↓
HTTP

순서로 진행됩니다.

따라서:

TCP Handshake 성공

하지만 HTTPS 연결 실패

라면 TCP보다 TLS 단계에서 문제가 발생했을 수도 있습니다.

예:

Certificate 오류

TLS Version 불일치

Cipher Suite 문제

SNI 문제

Application 인증 실패

등입니다.

Network 담당자와 Application 담당자가 서로:

Network는 정상입니다.

그런데 연결이 안 됩니다.

라고 말하는 상황이 여기에서 자주 발생합니다.

TCP와 TLS, Application을 구분해야 합니다.

16장 NAT가 있는 환경에서는 무엇을 확인해야 할까#

16.1 Source 정보가 바뀔 수 있다#

Client 내부에서는:

192.168.10.20:50123

으로 보낸 Connection이 NAT 장비 밖에서는:

203.0.113.10:43001

처럼 보일 수 있습니다.

따라서 내부와 외부 Capture를 비교할 때는 IP와 Port가 동일하지 않을 수 있습니다.

16.2 NAT 환경의 Handshake#

개념적으로:

Client
192.168.10.20:50123
        ↓
       NAT
        ↓
203.0.113.10:43001
        ↓
      Server

Server는 내부 Client 주소가 아니라 NAT 이후의 Source Address를 보게 될 수 있습니다.

장애 분석에서는:

NAT Rule

Session Table

Source Translation

Return Traffic

까지 확인할 수 있습니다.

17장 Firewall은 Drop과 Reject가 다를 수 있다#

17.1 Drop#

Firewall이 Packet을 조용히 버리는 정책이라면 Client에서는 다음처럼 보일 수 있습니다.

SYN
↓
응답 없음
↓
SYN Retransmission
↓
Timeout

17.2 Reject#

환경과 정책에 따라 즉시 거부 응답을 돌려줄 수도 있습니다.

이 경우 Client가 Timeout까지 오래 기다리지 않고 빠르게 실패를 인식할 수 있습니다.

따라서 Packet Capture에서:

아무 응답이 없는가?

RST가 오는가?

ICMP 오류가 오는가?

를 구분하는 것이 중요합니다.

18장 주차관제 현장 사례 — 결제단말이 Server에 접속하지 못한다#

다음 구조를 가정하겠습니다.

Payment Terminal
10.20.10.30
       │
       │
     Switch
       │
       │
    Firewall
       │
       │
Parking Server
10.100.10.20:8000

Application Log:

Connection Timeout
10.100.10.20:8000

입니다.

18.1 첫 번째 Capture#

Terminal에서 Capture합니다.

10.20.10.30 → 10.100.10.20
SYN

10.20.10.30 → 10.100.10.20
SYN Retransmission

10.20.10.30 → 10.100.10.20
SYN Retransmission

SYN/ACK은 없습니다.

18.2 Server에서도 확인한다#

Server Capture에는 SYN 자체가 없습니다.

그러면:

Terminal
↓
Switch
↓
Gateway
↓
Firewall
↓
Server

중간 어딘가에서 SYN이 전달되지 않는 것입니다.

18.3 중간 장비의 기록을 비교한다#

Firewall Log에서:

Source      10.20.10.30
Destination 10.100.10.20
TCP Port    8000
Action      DROP

이 확인됐다고 가정해보겠습니다.

이제 원인은:

Server TCP 문제

가 아니라:

Firewall Policy

로 좁혀집니다.

이것이 Packet Capture의 가장 큰 장점입니다.

연결되지 않는다는 결과를 보고 추측하는 대신 Packet이 어디까지 갔는지 확인할 수 있습니다.

19장 반대로 Server까지 SYN이 도착한다면#

Server Capture:

10.20.10.30.50123
→
10.100.10.20.8000

SYN

이 정상적으로 보인다고 가정합니다.

하지만 Server에서 SYN/ACK이 없습니다.

이 경우 다음을 확인합니다.

TCP 8000 Service가 실행 중인가?

정확한 Interface에서 Listen하는가?

Server Firewall이 차단하는가?

Service의 Connection Queue에 문제가 있는가?

Server Resource가 고갈됐는가?

netstat, ss 같은 운영체제 도구를 이용해 Listening 상태를 확인할 수 있습니다.

Linux에서는 예를 들어:

ss -lnt

를 사용할 수 있습니다.

특정 Port는:

ss -lnt | grep ':8000'

처럼 확인할 수 있습니다.

20장 Packet Capture 위치가 중요한 이유#

20.1 한 지점에서 본 Packet이 전체 Network를 대표하지 않는다#

Client에서:

SYN 전송

이 보였다고 Server까지 도착했다는 뜻은 아닙니다.

Server에서:

SYN/ACK 전송

이 보였다고 Client까지 도착했다는 뜻도 아닙니다.

그래서 복잡한 장애에서는 여러 지점을 비교합니다.

Client

↓

Access Switch

↓

Firewall

↓

Router

↓

Server

20.2 장애 구간을 이분법적으로 좁힐 수 있다#

예를 들어:

Client Capture
SYN O

Firewall 내부 Capture
SYN O

Server Capture
SYN X

이면:

Firewall 이후
~
Server 이전

구간을 집중적으로 볼 수 있습니다.

Packet Capture는 단순히 Packet 내용을 읽는 도구가 아니라 장애 위치를 좁히는 도구이기도 합니다.

21장 Port Mirroring을 이용한 Capture#

직접 Client나 Server에서 Capture할 수 없는 산업 장비도 많습니다.

예:

Gate Controller

RFID Reader

Embedded Controller

IP Camera

이런 장비에서는 Switch의 Port Mirroring 기능을 사용할 수 있습니다.

개념적으로:

Controller
    │
    │
Switch Port 10
    │
    ├──────── 정상 Traffic
    │
    └──────── 복사
               ↓
          Monitor Port
               ↓
         Capture PC

제조사에 따라:

Port Mirroring

SPAN

Mirror Port

등의 이름을 사용할 수 있습니다.

22장 Port Mirroring에도 한계가 있다#

Mirror Port에 너무 많은 Traffic을 복사하면 Monitor Port의 처리 능력을 초과할 수 있습니다.

예:

여러 1Gbps Port Traffic
↓
하나의 1Gbps Monitor Port

라면 모든 Packet을 완벽하게 Capture하지 못할 수도 있습니다.

따라서:

Capture에서 Packet이 안 보인다
=
실제로 Packet이 없었다

라고 무조건 단정하면 안 됩니다.

Capture 구조와 Packet Loss 가능성도 확인해야 합니다.

23장 TCP State도 함께 이해하면 분석이 쉬워진다#

Handshake 과정에서 대표적으로 다음 상태를 볼 수 있습니다.

Client 측:

CLOSED
↓
SYN-SENT
↓
ESTABLISHED

Server 측:

LISTEN
↓
SYN-RECEIVED
↓
ESTABLISHED

이를 Packet과 연결하면:

Client SYN
→ SYN-SENT

Server SYN 수신
→ SYN-RECEIVED

마지막 ACK 완료
→ ESTABLISHED

처럼 이해할 수 있습니다.

24장 Server가 LISTEN 상태인지 확인한다#

TCP 연결을 받으려면 Server Application이 해당 Port에서 기다리고 있어야 합니다.

예:

TCP 8000
LISTEN

이어야 합니다.

Application이 실행되어 있어도 다른 Port를 Listen하고 있을 수 있습니다.

예상
8000

실제
8080

이 경우 Network는 정상이어도 연결되지 않습니다.

그래서 현장에서는:

Server Process가 실행 중인가?

와:

정확한 TCP Port를 LISTEN하고 있는가?

를 따로 확인해야 합니다.

25장 Handshake 시간도 중요한 정보다#

정상적인 LAN에서는 일반적으로 Handshake가 매우 빠르게 완료됩니다.

Packet Capture에서:

SYN       10:00:00.000

SYN/ACK   10:00:00.002

ACK       10:00:00.003

처럼 나타날 수 있습니다.

하지만 원격 WAN이나 VPN, 이동통신망 등에서는 RTT가 더 클 수 있습니다.

중요한 것은 절대적인 숫자 하나보다:

평소에는 얼마나 걸렸는가?

장애 시간에는 얼마나 증가했는가?

를 비교하는 것입니다.

26장 SYN Retransmission을 어떻게 볼까#

Client가 SYN을 보냈는데 응답이 없다면 SYN을 다시 보낼 수 있습니다.

SYN
↓
응답 없음
↓
SYN Retransmission
↓
응답 없음
↓
SYN Retransmission

Wireshark에서는 상황에 따라 이러한 Packet을 Retransmission으로 분석해서 표시할 수 있습니다.

반복되는 SYN은 다음 사실을 알려줍니다.

Client TCP Stack이
연결 시도를 계속하고 있다.

하지만 왜 응답이 없는지는 추가 분석이 필요합니다.

27장 Sequence Number가 이상해 보여도 바로 공격이라고 판단하지 않는다#

Packet Capture를 처음 보는 경우 Sequence Number가 크게 바뀌거나 예상과 달라 보이면:

Session Hijacking인가?

라고 생각할 수 있습니다.

하지만 먼저 확인해야 할 것이 많습니다.

Wireshark Relative Sequence Number

Capture 시작 위치

새로운 Connection인지

TCP Offloading

Retransmission

Out-of-Order Packet

Capture Loss

등입니다.

TCP Sequence Number만 보고 공격 여부를 판단해서는 안 됩니다.

보안 사고를 의심하려면 Network 구조, Endpoint Log, 인증 기록, Firewall Log 등의 추가 증거가 필요합니다.

28장 3-Way Handshake 성공 여부로 장애 범위를 나누자#

관찰 결과 의미 다음 확인
SYN 없음 Client가 실제 TCP 연결을 시작하지 않았을 가능성 Application·Routing·Local Firewall
SYN 반복, 응답 없음 Client는 요청 중이나 응답을 못 받음 VLAN·Routing·Firewall·Server
SYN 후 RST 목적지까지 도달했을 가능성이 높음 Server Port·Service·Firewall
SYN/ACK이 Server에서만 보임 Return Path에서 손실 가능 Routing·NAT·Firewall
SYN/ACK이 Client까지 도착, ACK 없음 Client 측 처리 확인 Client TCP Stack·Firewall·Capture
SYN→SYN/ACK→ACK 정상 TCP 연결 성립 TLS·Application Protocol
Handshake 직후 RST 연결 후 즉시 종료됨 Application·Protocol·Security Policy

29장 시험망에서 직접 Handshake를 만들어보자#

29.1 Server 준비#

격리된 테스트 환경의 Linux Server에서:

nc -l 8000

처럼 간단한 TCP Listener를 만들 수 있습니다.

시스템에 설치된 nc 구현에 따라 Option 문법이 다를 수 있습니다.

29.2 Client 연결#

Client에서는:

nc 192.168.1.100 8000

처럼 연결합니다.

29.3 동시에 Packet Capture#

tcpdump -n -i eth0 'tcp port 8000'

을 실행합니다.

파일로 저장하려면:

tcpdump -n -i eth0 'tcp port 8000' -w handshake.pcap

처럼 사용할 수 있습니다.

29.4 관찰해야 할 것#

첫 번째 실습에서는 다음만 정확하게 찾으면 됩니다.

SYN

SYN/ACK

ACK

그다음:

Source IP

Destination IP

Source Port

Destination Port

Sequence Number

ACK Number

을 확인합니다.

마지막으로:

MSS

Window Scale

SACK Permitted

같은 Option을 확인합니다.

30장 장애 실습은 안전한 시험망에서 한다#

Handshake 장애를 이해한다고 운영 Network의 Firewall Rule을 임의로 변경해서는 안 됩니다.

실습 환경에서:

Client VM
↓
Test Firewall
↓
Server VM

구성을 만든 뒤 Rule을 변경하여:

정상 Handshake

SYN Drop

Server Port Closed

상태를 비교하는 것이 좋습니다.

실제 결제망이나 운영 중인 제어 Network에서 고의로 장애를 발생시키는 실습은 피해야 합니다.

31장 Packet Capture의 보안도 중요하다#

TCP Payload에는 상황에 따라 다음 정보가 들어갈 수 있습니다.

차량번호

Device ID

사용자 정보

인증 Token

결제 관련 데이터

관리 명령

TLS를 사용하지 않는 Protocol이라면 Packet Capture 파일에 Application Data가 그대로 남을 수도 있습니다.

따라서 Capture는:

필요한 Interface만

필요한 Host만

필요한 Port만

필요한 시간만

수집하는 것이 좋습니다.

31.1 Capture Filter로 범위를 줄인다#

예:

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

처럼 대상 Traffic을 줄일 수 있습니다.

Capture 파일은 일반 로그보다 훨씬 많은 Network 정보를 포함할 수 있으므로 접근 권한과 보관 정책도 필요합니다.

32장 현장에서는 Packet과 Log의 시간을 맞춘다#

Application Log:

10:31:04.120 Connection Timeout

Firewall Log:

10:31:00.100 TCP SYN DROP

Packet Capture:

10:31:00.098 SYN
10:31:01.100 SYN Retransmission
10:31:03.105 SYN Retransmission

처럼 시간을 맞추면 하나의 사건으로 연결할 수 있습니다.

그래서 장비마다 시간이 크게 다르면 장애 분석이 어려워집니다.

가능하다면 운영 장비의 시간 동기화 정책도 관리해야 합니다.

33장 Handshake 장애 진단의 기본 흐름#

연결이 되지 않는다면 다음 순서로 확인할 수 있습니다.

Application이 Connection을 시작했는가?
        ↓
SYN이 나가는가?
        ↓
SYN이 Server에 도착하는가?
        ↓
Server가 SYN/ACK을 보내는가?
        ↓
SYN/ACK이 Client에 도착하는가?
        ↓
Client가 ACK을 보내는가?
        ↓
Connection Established
        ↓
Application Data가 흐르는가?

그리고 그 아래에는 항상 기존 Network 계층이 있습니다.

Physical Link
↓
VLAN
↓
IP
↓
ARP / NDP
↓
Gateway
↓
Routing
↓
Firewall
↓
TCP
↓
Application

TCP Packet 분석만 잘한다고 아래 계층을 무시할 수 있는 것은 아닙니다.

34장 현장에서 자주 하는 잘못된 판단#

34.1 SYN이 나가면 Client는 정상이다?#

완전히 그렇지는 않습니다.

TCP 연결 시도는 하고 있다는 뜻이지만 잘못된 Destination IP나 Port로 SYN을 보낼 수도 있습니다.

34.2 SYN/ACK이 없으면 Server가 죽은 것이다?#

아닙니다.

중간 Firewall, Routing, VLAN, Return Path 등 다양한 원인이 있을 수 있습니다.

34.3 RST가 오면 Network가 끊긴 것이다?#

오히려 RST가 왔다는 것은 Network를 통해 어떤 응답이 돌아왔다는 중요한 단서입니다.

Service Port나 Application 상태를 확인해야 할 수 있습니다.

34.4 Handshake가 성공하면 Service가 정상이다?#

아닙니다.

TCP 위의:

TLS

Authentication

API

Application Protocol

등은 별도로 실패할 수 있습니다.

34.5 Packet Capture 하나만 보면 모든 것을 알 수 있다?#

아닙니다.

Capture 위치에 따라 볼 수 있는 Packet이 다릅니다.

필요하면 Client·Server·Firewall 등 여러 지점의 자료를 비교해야 합니다.

35장 핵심 개념 한눈에 정리하기#

개념 의미
SYN 새로운 TCP 연결 시작
SYN/ACK SYN 수신 확인과 Server 측 SYN
ACK 상대 Sequence 공간 확인
ISN Connection 시작 시 사용하는 Initial Sequence Number
3-Way Handshake TCP Connection 확립 과정
ESTABLISHED TCP Connection이 성립된 상태
LISTEN Server가 Connection을 기다리는 상태
SYN-SENT Client가 SYN을 보내고 응답을 기다리는 상태
SYN-RECEIVED SYN을 받고 SYN/ACK 이후 ACK를 기다리는 상태
RST TCP Connection의 즉시 Reset
MSS 수신 가능한 TCP Payload 크기 관련 Option
Window Scale Receive Window 표현 범위 확장
SACK Permitted Selective ACK 사용 가능 여부 협상

36장 자기 점검#

36.1 Client에서 SYN만 반복되고 SYN/ACK이 없다면 무엇을 알 수 있는가#

Client가 TCP 연결을 시도하고 있지만 Capture 지점에서는 응답이 관찰되지 않는다는 사실을 알 수 있습니다.

Server, Routing, Firewall, VLAN, Return Path 등을 추가로 확인해야 합니다.

36.2 SYN/ACK의 ACK Number가 Client ISN + 1인 이유는 무엇인가#

SYN이 TCP Sequence Number 공간에서 하나를 소비하기 때문입니다.

36.3 3-Way Handshake가 성공하면 Application도 정상인가#

아닙니다.

TCP Connection만 정상적으로 만들어졌다는 의미입니다. TLS, 인증, Application Protocol 등은 이후 별도로 실패할 수 있습니다.

36.4 SYN 다음에 바로 RST가 돌아온다면 무엇을 확인해야 하는가#

목적지 Server까지 Packet이 도달했을 가능성이 있으므로 해당 TCP Port에서 Service가 Listen 중인지, Server Firewall이나 Application이 연결을 거부하고 있는지 확인합니다.

36.5 Packet Capture 위치가 중요한 이유는 무엇인가#

어떤 Packet이 한 지점에서 관찰되었다고 해서 다음 지점까지 도착했다는 뜻은 아니기 때문입니다. 여러 지점의 Capture를 비교하면 장애가 발생한 구간을 좁힐 수 있습니다.

37장 이 글을 마치며#

TCP 3-Way Handshake는 세 개의 Packet만 보면 매우 단순해 보입니다.

SYN
↓
SYN/ACK
↓
ACK

하지만 실제 장애 분석에서는 이 세 Packet만으로도 많은 정보를 얻을 수 있습니다.

먼저:

Client가 SYN을 만들었는가?

를 확인합니다.

그다음:

Server까지 SYN이 도착했는가?

를 확인합니다.

Server가:

SYN/ACK을 만들었는가?

를 보고:

Client까지 SYN/ACK이 돌아왔는가?

를 확인합니다.

마지막으로:

Client가 ACK을 보냈는가?

를 확인합니다.

이 과정을 연결하면:

Application
↓
SYN 생성
↓
VLAN
↓
Routing
↓
Firewall
↓
Server
↓
SYN/ACK
↓
Return Path
↓
Client
↓
ACK
↓
ESTABLISHED

라는 전체 경로가 보입니다.

따라서 Connection Timeout이라는 한 줄을 봤을 때 바로:

Server 문제다.

Network 문제다.

Firewall 문제다.

라고 결론을 내리는 것이 아니라 Handshake가 정확히 어느 단계에서 멈췄는가를 먼저 확인하는 것이 중요합니다.

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

SYN은 Client가 실제 연결을 시작했는지 보여줍니다.

SYN/ACK은 Server가 SYN을 받고 응답할 수 있었는지를 보여주는 중요한 단서입니다.

마지막 ACK까지 확인되면 TCP Connection이 성립됐는지 판단할 수 있습니다.

3-Way Handshake가 성공했다고 Application까지 정상이라는 뜻은 아닙니다.

TCP Packet 분석의 핵심은 Flag를 외우는 것이 아니라 Packet이 어디까지 갔고, 어느 지점에서 다음 응답이 사라졌는지를 추적하는 것입니다.

이 페이지의 목차