[Network] 26. 패킷을 직접 보면 모든 원인을 알 수 있을까?

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 8. 편지가 멈춘 곳을 찾는 법

ㅁ 들어가며

장애가 생기면 Wireshark를 열고 Packet부터 보고 싶어진다.

Packet은 추측보다 강한 증거다.

SYN을 실제로 보냈다.
SYN-ACK이 실제로 돌아왔다.
DNS가 NXDOMAIN을 응답했다.
Router가 ICMP Unreachable을 보냈다.
같은 TCP Sequence가 재전송됐다.

 

하지만 Capture 화면은 Network 전체를 내려다보는 CCTV가 아니다.

어느 Host의
어느 Interface에서
어느 방향을
어느 시간 동안
어떤 Filter와 크기로
수집했는가?

 

이 조건 안에서 보인 Packet만 기록한다.

Client Capture에 SYN이 없다고 Server가 받지 않았음을 증명하는 것이 아니다.

잘못된 Interface를 봤거나 Capture가 늦게 시작됐거나 BPF Filter가 제외했을 수 있다.

SYN이 보인다고 NIC를 떠나 Wire에 실렸다는 뜻도 아닐 수 있다.

Capture 위치가 NIC Offload 이전일 수 있기 때문이다.

Packet Capture는 답을 자동으로 주는 도구가 아니라 가설을 관찰 가능한 사건으로 바꾸는 도구다.

 

이번 글에서는 ip, dig, ping, traceroute, nc, curl, openssl, tcpdump, Wireshark와 Log를

계층별 질문에 연결하고 Multi-point Capture로 원인 범위를 줄이는 방법을 정리한다.

---

ㅁ 도구를 열기 전에 어떤 질문을 써야 할까?

“Network가 안 된다”는 질문은 너무 크다.

다음처럼 관찰 가능한 질문으로 나눈다.

Hostname이 어느 Address로 해석되는가?
Kernel은 어느 Route와 Source Address를 선택하는가?
Next-Hop MAC Address를 알고 있는가?
TCP SYN이 Host를 떠나는가?
SYN-ACK 또는 RST가 돌아오는가?
TLS ClientHello 뒤에 ServerHello가 오는가?
HTTP Request가 Server Process까지 도착하는가?
Server가 Reply를 만들고 어느 Route로 보내는가?

질문이 달라지면 필요한 증거와 Capture 지점도 달라진다.

DNS 질문에 TCP Retransmission Filter만 봄
→ 필요한 증거를 놓침

Application 500 오류에 ARP만 봄
→ 계층이 맞지 않음

도구보다 질문을 먼저 정하면 수많은 Packet에서 무엇을 찾아야 하는지 분명해진다.

---

ㅁ Packet Capture는 어떤 문장으로 읽어야 할까?

다음 두 문장은 범위가 다르다.

Packet이 없다.

10:30:00부터 10:30:15까지 Client의 eth0 Ingress와 Egress를
Snaplen 0, TCP 443 Filter로 Capture했지만
198.51.100.20을 향한 SYN을 관찰하지 못했다.

 

두 번째 문장은 다음 확인점을 남긴다.

• 시간 범위가 맞는가?
• 실제 Traffic이 eth0을 사용했는가?
• IPv4와 IPv6 Address가 맞는가?
• Port가 정말 443인가?
• Capture Process가 Packet을 Drop하지 않았는가?

Capture의 부재는 정의한 관찰 창 안에서 보이지 않았다는 뜻이다.

관찰 조건을 기록하지 않은 “없음”은 약한 증거다.

---

ㅁ 가장 먼저 Packet을 잡아야 할까?

Packet Capture 전에 Local State를 확인하면 더 빠르게 범위를 줄일 수 있다.

Interface가 Down
Route 없음
잘못된 DNS Answer
Service가 Listen하지 않음

이런 상태는 Packet 수천 개를 읽지 않고도 확인할 수 있다.

일반적인 순서는 다음과 같다.

1. 증상과 시간, Source·Destination 정의
2. Local Interface와 Address 확인
3. Route와 Neighbor 확인
4. DNS Answer 확인
5. 실제 Transport와 Application Probe
6. 필요한 지점에서 Packet Capture
7. Firewall Counter, Conntrack와 Application Log 대조

순서는 고정된 의식이 아니다. 이미 장애 시간의 PCAP만 남았다면 Capture부터 볼 수 있다.

핵심은 한 도구의 결과를 전체 원인처럼 확대하지 않는 것이다.

---

ㅁ ip link는 무엇을 묻는가?

Linux에서 Interface 상태와 Counter를 확인한다.

ip -s link

 

확인할 항목은 다음과 같다.

Interface UP / DOWN
Carrier 상태
MTU
RX / TX Packet과 Byte
Error와 Drop Counter

 

Interface가 UP이라고 Cable, Switch Port, VLAN, Routing과 Remote Host가 모두 정상이라는 뜻은 아니다.

반대로 RX Drop Counter가 증가해도 곧바로 Network 손실 원인을 확정할 수 없다.

Driver Queue, Buffer, Offload와 Counter 정의를 확인해야 한다.

ip link 증거
→ Local Interface 상태와 Counter

증명하지 않는 것
→ End-to-End Service 정상

---

ㅁ ip addr는 무엇을 확인할까?

ip addr show

 

다음 질문에 답한다.

• 기대한 IPv4 또는 IPv6 Address가 있는가?
• Prefix Length가 맞는가?
• 어느 Interface에 연결되어 있는가?
• Address가 Tentative, Deprecated 같은 상태인가?

Address가 있다고 해당 Source로 Packet이 나간다고 보장할 수는 없다.

Route Selection이 다른 Interface와 Source를 선택할 수 있다.

Container, Pod, VRF와 Network Namespace마다 별도 Address와 Interface가 있으므로

실제 Application의 Network Context에서 실행한다.

---

ㅁ ip route get은 왜 유용할까?

Routing Table 전체를 보는 것보다 특정 Destination에 대한 Kernel의 결정을 직접 묻는다.

ip route get 198.51.100.20

 

환경에 따라 다음 정보가 보일 수 있다.

Selected Route
Next Hop
Outgoing Interface
Preferred Source Address
Route Table과 Metric 관련 정보

 

Source를 지정해 Policy Routing 차이를 볼 수도 있다.

ip route get 198.51.100.20 from 10.0.0.10

 

ip route get 결과는 현재 Kernel Route Lookup의 증거다.

Packet이 이후 Firewall, Tunnel과 Neighbor Resolution을 모두 통과했다는 증거는 아니다.

Policy Routing을 사용하면 다음도 함께 본다.

ip rule show
ip route show table all

---

ㅁ ip neigh는 어느 단계의 장부일까?

같은 Link의 Destination이나 Default Gateway로 Frame을 보내려면 Next-Hop IP에 대응하는 MAC Address가 필요하다.

ip neigh show

 

Neighbor Entry는 다음 상태를 가질 수 있다.

REACHABLE
STALE
DELAY
PROBE
INCOMPLETE
FAILED

 

INCOMPLETE나 FAILED가 반복되면 ARP Request 또는 IPv6 Neighbor Solicitation에 응답이 없는 이유를 조사한다.

VLAN 불일치
Switch Port 문제
잘못된 Subnet
Gateway Down
L2 Security Policy

 

STALE은 곧 장애라는 뜻이 아니다.

필요할 때 다시 Reachability를 확인할 수 있는 정상 상태다.

---

ㅁ macOS와 다른 운영체제에서는 무엇을 사용할까?

명령 이름은 달라도 질문은 같다.

Interface와 Address
→ ifconfig, ipconfig 등

Route
→ route, netstat, Get-NetRoute 등

Neighbor
→ arp, ndp, Get-NetNeighbor 등

 

출력 Field와 State 의미는 운영체제마다 다르다.

Linux 명령을 외우는 것보다 “현재 Source에서 어느 Interface와 Next Hop을 선택했는가?”라는 질문을 유지한다.

---

ㅁ dig는 무엇을 분리해 줄까?

Hostname 장애는 Network 연결 전에 시작될 수 있다.

dig server.example A
dig server.example AAAA

 

특정 Resolver에 직접 물어 비교한다.

dig @192.0.2.53 server.example A +time=2 +tries=1

 

응답을 다음처럼 구분한다.

NOERROR + Answer
→ 해당 Resolver가 Address Answer를 제공

NXDOMAIN
→ 이름이 존재하지 않는다는 DNS 응답

SERVFAIL
→ Resolver가 질의를 완료하지 못함

Timeout
→ 정해진 시간 안에 DNS 응답을 관찰하지 못함

 

dig가 받은 Answer는 Cache에서 왔을 수도 있다.

Authoritative Server의 현재 Zone을 직접 읽었다고 자동으로 가정하지 않는다.

DNSSEC 검증, Search Suffix와 Application 내부 Resolver처럼

실제 Application과 dig의 조회 경로가 다를 수도 있다.

---

ㅁ DNS Packet은 어디에서 확인할까?

sudo tcpdump -nn -i eth0 -s 0 \
  'port 53'

다음 흐름을 확인한다.

Query가 Host를 떠나는가?
어느 Resolver로 보내는가?
UDP인가 TCP인가?
Response가 돌아오는가?
Transaction ID와 질문이 맞는가?
Response Code와 Answer는 무엇인가?

DoH와 DoT를 사용하는 Application은 일반 UDP/TCP 53 Filter에 DNS 이름이 보이지 않을 수 있다.

port 53에 Packet 없음
≠ Application이 DNS를 전혀 사용하지 않음

실제 Resolver 경로와 암호화 방식을 확인해야 한다.

---

ㅁ nc는 어떤 범위까지 시험할까?

TCP Port 연결 가능성을 빠르게 시험할 수 있다.

nc -v -w 3 198.51.100.20 443

 

성공하면 해당 Source에서 TCP Handshake가 완료되었다는 단서를 얻는다.

nc TCP 연결 성공
≠ TLS 성공
≠ HTTP 정상
≠ 업무 처리 성공

 

실패 모습도 나눈다.

Timeout
→ SYN 또는 Reply Drop, 경로, Policy 등 여러 가능성

Connection Refused
→ RST를 받음, Listener 부재 또는 중간 장비 Reject 가능

 

nc Option은 구현마다 다르며 UDP Mode는 TCP처럼 Handshake 성공을 확인하지 못한다.

---

ㅁ curl은 어느 계층까지 올라갈까?

curl -v --connect-timeout 3 https://server.example/

 

Verbose 출력에서 다음 단계를 나눌 수 있다.

DNS Address 선택
TCP Connection
TLS Handshake와 Certificate 검증
HTTP Request
HTTP Status와 Header
Response Body

 

curl 성공은 실행한 URL과 Method, 해당 시점의 Response에 대한 증거다.

다른 API, 사용자 권한, Backend와 전체 Service가 정상이라는 뜻은 아니다.

-k로 Certificate 검증을 끄면 TLS Identity 문제를 숨길 수 있으므로 진단의 기본 해결책으로 사용하지 않는다.

 

---

ㅁ openssl s_client는 무엇을 보여줄까?

openssl s_client \
  -connect server.example:443 \
  -servername server.example \
  -verify_hostname server.example \
  -verify_return_error

 

다음 정보를 확인할 수 있다.

TLS Version과 Cipher
Server Certificate Chain
Hostname과 Trust 검증 결과
ALPN 협상
TLS Alert

 

-servername을 빠뜨리면 Virtual Host가 다른 Certificate를 보낼 수 있다.

TCP 연결 Timeout과 Certificate Verification Error를 같은 “TLS 실패”로 묶지 않는다.

---

ㅁ tcpdump를 시작할 때 무엇을 정해야 할까?

설명용 Capture 명령은 다음과 같다.

sudo tcpdump \
  -nn \
  -i eth0 \
  -s 0 \
  -B 4096 \
  -w incident-20260715.pcap \
  'host 198.51.100.20 and tcp port 443'

Option의 목적을 나누어 보자.

-nn
→ Hostname과 Service Name 변환을 하지 않고 숫자로 표시

-i eth0
→ Capture할 Interface 선택

-s 0
→ 구현이 허용하는 전체 Packet을 자르지 않고 저장

-B 4096
→ Capture Buffer 크기 지정

-w file.pcap
→ 화면 해석 대신 원본 Packet을 파일로 저장

BPF 표현식
→ 수집할 Traffic 범위를 Capture 단계에서 제한

Option 의미와 단위는 tcpdump Version과 운영체제에 따라 확인한다.

Capture 파일 이름에는 시간, Host와 Interface 같은 Context를 넣으면 여러 지점 자료를 맞추기 쉽다.

---

ㅁ Capture Filter와 Display Filter는 같은 문법일까?

같지 않다.

Capture Filter는 Packet을 저장하기 전에 어떤 Traffic을 수집할지 정한다.

tcpdump와 Wireshark Capture 단계에서 BPF 문법을 사용할 수 있다.

host 198.51.100.20 and tcp port 443

 

Display Filter는 이미 Capture된 Packet 중 화면에 무엇을 보여 줄지 정한다.

ip.addr == 198.51.100.20 && tcp.port == 443

 

차이는 중요하다.

Capture Filter에서 제외
→ PCAP에 저장되지 않음, 나중에 복구 불가

Display Filter에서 숨김
→ PCAP에는 남아 있어 Filter를 바꾸면 다시 볼 수 있음

 

원인을 아직 모를 때 Capture Filter를 지나치게 좁히면 ARP, DNS, ICMP 오류와 다른 Address Family를 놓칠 수 있다.

Storage와 Privacy를 고려하면서 가설에 필요한 범위를 잡는다.

---

ㅁ BPF Filter는 어떻게 조합할까?

대표적인 Capture Filter는 다음과 같다.

특정 Host
host 198.51.100.20

특정 방향
src host 10.0.0.10 and dst host 198.51.100.20

특정 Network
net 10.0.0.0/8

TCP Service
tcp port 443

DNS와 ICMP
port 53 or icmp or icmp6

복합 조건
host 198.51.100.20 and (tcp port 443 or icmp)

 

and, or, not의 우선순위를 오해하지 않도록 괄호를 사용한다.

Filter를 본 Capture 전에 작은 Sample로 검증한다.

sudo tcpdump -nn -i eth0 -c 10 \
  'host 198.51.100.20 and (tcp port 443 or icmp)'

 

Capture Filter가 실제 장애 Traffic의 IPv4·IPv6, NAT 전후 Tuple과 Port를 포함하는지 확인한다.

---

ㅁ Snaplen이 작으면 무엇을 잃을까?

Snapshot Length(Snaplen)는 Packet마다 저장할 최대 Byte 수다.

Snaplen이 Header보다 충분히 크지만 Payload보다 작으면 주소와 Port는 볼 수 있어도 Application Data 뒤는 잘린다.

Wire Packet 1500바이트
Snaplen 96바이트
→ 앞 96바이트만 PCAP에 저장

 

Wireshark는 Packet size limited during capture 같은 표시를 할 수 있다.

잘린 Byte는 Display Filter나 재분석으로 되살릴 수 없다.

전체 Payload가 필요한지, Header만으로 충분한지와 민감 정보 수집 위험을 함께 고려한다.

-s 0은 분석에는 편리하지만 Password, Cookie와 개인정보까지 저장할 수 있다.

---

ㅁ Capture Process도 Packet을 놓칠 수 있을까?

Traffic 속도가 Disk, CPU와 Buffer 처리 능력보다 빠르면 Capture Tool이 Packet을 Drop할 수 있다.

tcpdump 종료 통계에는 환경에 따라 다음 Counter가 보일 수 있다.

packets captured
packets received by filter
packets dropped by kernel

 

dropped by kernel이 증가했다면 PCAP의 Packet 부재를 Network Drop으로 해석하기 전에 Capture 누락을 고려한다.

완화 방법은 다음과 같다.

• BPF로 필요한 Traffic 범위 제한
• Capture Buffer 조정
• 빠른 Storage 사용
• 화면 출력 대신 -w로 저장
• 여러 CPU Queue와 전용 Capture 장비 사용
• Ring Buffer로 파일 Rotation

Capture Drop Counter 자체도 플랫폼별 정의를 확인해야 한다.

---

ㅁ 긴 장애를 파일 하나에 계속 저장해도 될까?

오래 기다려야 재현되는 장애는 PCAP가 매우 커질 수 있다.

tcpdump는 크기나 시간 기준으로 파일을 나눌 수 있다.

 

설명용 예시는 다음과 같다.

sudo tcpdump -nn -i eth0 -s 0 \
  -C 100 -W 10 \
  -w incident.pcap \
  'host 198.51.100.20'

일반적인 tcpdump에서 -C 100은 파일이 약 100 million bytes에 도달하기 전에 다음 파일로 전환하고, -W 10은 파일 수를 제한하는 데 사용된다. 정확한 단위와 이름 규칙은 해당 Version의 Manual을 확인한다.

Ring Buffer는 Disk 고갈을 막지만 오래된 증거를 덮어쓴다.

Alarm 시각과 보존 범위를 맞추고 필요한 PCAP를 즉시 별도 보관한다.

---

ㅁ Promiscuous Mode면 Switch의 모든 Packet이 보일까?

Promiscuous Mode는 NIC가 자신에게 전달된 Frame 중

Destination MAC이 자신의 것이 아닌 Frame도 Host에 넘기도록 할 수 있다.

그러나 Switch가 해당 Port로 Frame을 보내지 않았다면 NIC가 받을 수 없다.

다른 두 Host의 Unicast Traffic
→ Switch가 그 둘의 Port로만 Forward
→ 내 Capture Port에는 도착하지 않음

 

다른 Link의 Traffic을 관찰하려면 다음 같은 구성이 필요할 수 있다.

• Switch SPAN 또는 Port Mirroring
• Network TAP
• Router·Firewall 자체 Capture
• Virtual Switch Mirror
• Endpoint Capture

SPAN Port도 과부하되면 Packet을 놓치거나 Timing 특성이 바뀔 수 있다.

TAP과 Mirror의 방향, VLAN Tag 보존과 Capacity를 확인한다.

---

ㅁ any Interface에서 같은 Packet이 두 번 보일 수 있을까?

Linux의 tcpdump -i any는 여러 Interface를 함께 관찰한다.

Router가 Packet을 한 Interface로 받고 다른 Interface로 내보내면

같은 논리적 Packet이 Ingress와 Egress에서 각각 Capture될 수 있다.

eth0 Ingress  → Packet 한 번 관찰
eth1 Egress   → 같은 Packet 다시 관찰

Bridge, veth, Container와 Host Capture를 겹치면 더 많은 복사본처럼 보일 수 있다.

이를 실제 Network Duplicate로 단정하지 않는다.

Capture Interface ID, Direction, TTL 변화, MAC Header와 Timestamp를 비교한다.

---

ㅁ Checksum이 Bad라고 정말 Wire에서 손상됐을까?

TX Checksum Offload가 활성화된 Host에서는

Kernel Capture 시점에 TCP·UDP Checksum 계산이 아직 NIC에 맡겨진 상태일 수 있다.

Kernel이 Packet을 Capture
→ Checksum이 아직 완성되지 않음
→ NIC가 Wire 전송 전에 계산

Host Capture에서는 Bad Checksum처럼 보여도 실제 Wire Packet은 정상일 수 있다.

반대로 RX Offload와 Capture 위치도 해석에 영향을 준다.

Sender Host에서만 Bad Checksum
수신 Host에서는 정상 수신
→ TX Offload 가능성

다른 지점 Capture와 NIC Offload 설정을 함께 확인한다.

Checksum 경고 한 줄만으로 Link 손상을 확정하지 않는다.

---

ㅁ MTU보다 큰 TCP Packet이 보이면 Jumbo Frame일까?

TSO와 GSO는 Host 내부에서 큰 TCP Data 단위를 NIC나 하위 계층에 넘긴 뒤 실제 Wire 크기로 나눌 수 있다.

GRO와 LRO는 받은 여러 Packet을 Host 내부에서 합쳐 큰 단위로 상위 계층에 전달할 수 있다.

TSO / GSO
→ 분할 전 큰 Packet처럼 Capture 가능

GRO / LRO
→ 병합 후 큰 Packet처럼 Capture 가능

Host PCAP에서 32KB TCP Packet이 보였다고 Wire에 32KB Ethernet Frame 하나가 존재했다고 단정할 수 없다.

Capture 지점과 Offload 전후를 구분하고 필요하면 SPAN/TAP에서 Wire Traffic을 확인한다.

---

ㅁ VLAN Tag가 안 보이면 Untagged였을까?

NIC가 VLAN Tag를 Hardware에서 제거한 뒤 Kernel에 Metadata로 전달할 수 있다.

Host Capture 위치에 따라 Packet Byte에는 802.1Q Header가 보이지 않을 수 있다.

반대로 Trunk SPAN에서는 VLAN Tag가 보일 수 있다.

Host Capture에서 Tag 없음
≠ Wire에서 반드시 Untagged

NIC Offload, Driver와 Mirror 설정을 확인한다.

VLAN 문제는 Switch Port의 Access/Trunk Policy와 양쪽 Capture를 함께 봐야 한다.

---

ㅁ Wireshark의 분석 표시는 Packet Header일까?

Wireshark는 Packet Header뿐 아니라 Capture 순서와 시간 관계를 분석해 편리한 표시를 만든다.

tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.duplicate_ack
tcp.analysis.out_of_order
tcp.analysis.zero_window

이 값은 Wire에 들어 있는 독립적인 TCP Flag가 아니다.

Capture가 연결 중간부터 시작되거나 한 방향 Packet이 빠졌거나 Capture Drop이 있으면 분석 결과도 달라질 수 있다.

Wireshark가 Retransmission으로 표시
→ Capture 관점에서 같은 Sequence 범위를 다시 관찰
→ 왜 원본이 확인되지 않았는지는 별도 조사

편리한 Expert Info를 결론이 아니라 가설 생성 도구로 사용한다.

---

ㅁ Display Filter로 대화를 어떻게 좁힐까?

이미 저장한 PCAP에서 다음처럼 범위를 줄일 수 있다.

특정 Address
ip.addr == 198.51.100.20

특정 TCP Port
tcp.port == 443

특정 TCP Stream
tcp.stream eq 3

SYN
tcp.flags.syn == 1

RST
tcp.flags.reset == 1

DNS
dns

ICMP 오류
icmp || icmpv6

재전송 분석
tcp.analysis.retransmission

tcp.stream 번호는 해당 Capture 파일에서 Wireshark가 부여한 분석 번호다.

다른 PCAP의 같은 실제 Flow가 같은 번호를 갖는 것은 아니다.

NAT 양쪽에서는 5-Tuple이 달라지므로 Sequence Number, 시간과 변환 Table을 이용해 연결한다.

---

ㅁ TCP SYN만 반복되면 어디가 문제일까?

Client Capture에서 다음 흐름이 보인다고 하자.

Client → Server : SYN
Client → Server : SYN Retransmission
Client → Server : SYN Retransmission

이 Capture 하나로 알 수 있는 것은 다음이다.

Client TCP가 SYN을 만들었다.
Client Capture 지점에서 SYN을 관찰했다.
Client가 SYN-ACK 또는 유효한 응답을 받지 못해 재전송했다.

다음은 아직 모른다.

원래 SYN이 Wire를 떠났는가?
Forward Path 어디에서 Drop됐는가?
Server가 SYN을 받았는가?
Server가 SYN-ACK을 보냈는가?
SYN-ACK이 Return Path에서 Drop됐는가?

Client PCAP의 SYN Retransmission은 손실의 존재를 암시하지만 Drop 위치를 알려 주지 않는다.

---

ㅁ RST가 보이면 원인을 확정할 수 있을까?

SYN 뒤에 RST가 돌아오면 Silent Timeout보다 정보가 많다.

Client → Server : SYN
Server → Client : RST, ACK

Destination Host의 닫힌 Port가 RST를 보냈을 수 있다.

하지만 Firewall, Load Balancer와 Proxy가 Reject Policy로 RST를 생성할 수도 있다.

RST의 Source Address, TTL, Sequence와 Capture 지점을 비교한다.

Server Capture에 SYN이 없는데 Client가 RST를 받았다면 중간 장비가 생성했을 가능성을 조사한다.

RST 수신
→ 누군가 TCP 연결을 명시적으로 거절
→ 누가 생성했는지는 추가 증거 필요

---

ㅁ 3-Way Handshake 뒤 Data가 멈추면 무엇을 볼까?

SYN
SYN-ACK
ACK
Client Data
Client Data Retransmission

 

TCP 연결은 성립했지만 Data나 ACK가 진행하지 않는다.

다음 항목을 확인한다.

• Data Packet 크기와 DF, ICMP Too Big 여부
• Server Capture에 Data가 도착하는가?
• Server가 ACK를 보내는가?
• ACK가 Client에 도착하는가?
• Advertised Window가 0인가?
• TLS ClientHello 뒤 응답이 있는가?
• Application Process가 Socket을 읽는가?

Handshake 성공만으로 큰 Data, TLS와 Application까지 정상이라고 판단하지 않는다.

---

ㅁ TLS Capture에서 평문이 없으면 분석할 수 없을까?

TLS 1.3 PCAP을 Session Key 없이 보면 ClientHello와 ServerHello 이후

대부분의 Handshake와 Application Payload가 암호화되어 있다.

 

내용을 읽지 못해도 다음은 관찰할 수 있다.

TCP Handshake 성공 여부
ClientHello 전송 여부
ServerHello 또는 Alert 존재 여부
Record 크기와 방향
Retransmission과 Timeout
Connection 종료 시점

그러나 HTTP URL, Header와 Body는 보이지 않을 수 있다.

TLS Key Log로 Lab Traffic을 복호화할 수 있는 환경도 있지만 Key Log는 보호된 평문을 드러낼 수 있는 민감 정보다.

Production에서 임의로 수집하거나 공유하지 않는다.

암호화된 Payload 문제는 Endpoint의 TLS Log와 Application Log가 더 강한 증거가 될 수 있다.

---

ㅁ Server Capture에 Request가 보이면 Application도 받았을까?

Server NIC 근처 Capture에 TCP Data가 보였다고 Application의 read()가 성공했다는 뜻은 아니다.

NIC / Driver
→ IP Stack
→ Host Firewall
→ TCP Reassembly
→ Socket Receive Buffer
→ Application read()

중간 단계에서 Checksum 검증, Firewall, Socket 상태와 Buffer 문제가 생길 수 있다.

TCP ACK가 돌아왔다면 Server TCP Stack이 Byte를 수신했다는 강한 단서지만 Application 업무 처리 완료는 아니다.

Application Access Log, Error Log와 Trace ID를 함께 봐야 한다.

---

ㅁ Application Log만 보면 Network는 알 수 없을까?

Application Log도 중요한 관찰 지점이다.

Packet Capture
→ Network와 Transport에서 무엇이 오갔는가?

Application Log
→ Process가 어떤 요청을 해석하고 어떤 결과를 만들었는가?

Server Access Log에 Request가 없다면 다음 가능성이 남는다.

• Request가 Network에서 도착하지 않음
• TLS Proxy나 Load Balancer에서 종료됨
• Host Firewall 또는 Kernel에서 Drop
• Application Log 조건에서 제외
• Log Buffer와 수집 Pipeline 문제

Log 부재도 Capture 부재처럼 관찰 조건을 확인해야 한다.

Packet, Conntrack, Proxy Log와 Application Trace를 동일한 시간축과 Request ID로 연결한다.

---

ㅁ 두 Capture의 Clock이 다르면 무엇이 꼬일까?

Client와 Server PCAP를 비교할 때 Timestamp가 정확해야 한다.

Client Clock가 실제보다 500ms 빠름
Server Clock가 실제보다 300ms 느림

화면상 차이 800ms
→ Network Delay로 오해 가능

NTP나 PTP로 Clock을 동기화하고 Capture Host의 Timestamp Source와 정밀도를 기록한다.

동기화가 완벽하지 않다면 TCP Sequence, IP ID, Payload Length와 사건 순서로 상대적인 Offset을 추정할 수 있다.

정확한 One-Way Delay를 주장하려면 Capture Timestamp 정확도와 Clock Error 범위를 함께 제시한다.

---

ㅁ Multi-point Capture는 무엇을 추가할까?

같은 Flow를 여러 지점에서 동시에 관찰한다.

Client
  │ Capture A
  ▼
Firewall Ingress
  │ Capture B
Firewall Egress
  │ Capture C
  ▼
Server
  │ Capture D

SYN의 관찰 결과를 비교하면 Drop 범위를 좁힐 수 있다.

Client Egress	Firewall Ingress	Firewall Egress	Server Ingress	해석 가능한 범위
보임	안 보임	안 보임	안 보임	Client Capture 이후와 Firewall Ingress 사이 또는 Capture 누락
보임	보임	안 보임	안 보임	Firewall 내부 Policy·Routing·Processing 범위 우선 확인
보임	보임	보임	안 보임	Firewall Egress 이후와 Server Ingress 사이 또는 Capture 누락
보임	보임	보임	보임	Forward SYN 전달 확인, Server Host와 Reply 생성·Return Path 조사

 

표의 어느 행도 단일 원인을 자동 확정하지 않는다.

Firewall Ingress에는 보이고 Egress에는 없더라도

Rule Drop, Local Routing, Inspection, Queue Drop와 Capture 설정이 후보로 남는다.

Rule Counter, Drop Log와 장비 내부 Trace로 한 단계 더 좁힌다.

---

ㅁ Forward Path만 Capture하면 절반만 보는 이유

Request가 Server에 도착하고 Reply가 돌아오지 않는 장애가 있다.

Forward Path Capture: Request 정상
Return Path Capture : Reply가 중간에서 Drop

 

Forward 방향만 보면 Server나 Application을 의심하기 쉽다.

양방향 Filter와 Return Route를 확인한다.

Original Tuple
Client:53000 → Server:443

Reply Tuple
Server:443 → Client:53000

NAT가 있으면 Capture 지점마다 Tuple이 달라진다.

Stateful Firewall과 Load Balancer가 있다면 Return Packet이 같은 State Owner를 지나는지도 확인한다.

---

ㅁ Capture에서 Packet이 사라진 경계를 찾으면 원인이 끝날까?

Client와 Firewall Ingress에는 SYN이 있고 Firewall Egress에는 없다고 하자.

원인 범위는 Firewall 내부로 크게 줄었다.

하지만 정확한 이유는 여전히 여러 가지다.

Firewall Policy Drop
No Route 또는 Wrong VRF
NAT Resource Exhaustion
Inspection Engine Drop
State Table Full
Egress Queue Drop
Capture Hook 위치 차이

 

다음 증거를 이어 본다.

• Rule Hit Counter
• Drop Log와 Reason Code
• Routing/VRF Lookup
• NAT와 Conntrack Entry
• Interface Error/Drop Counter
• 장비 CPU와 Session Capacity

Multi-point Capture는 원인 위치 범위를 줄이고 장비 State가 원인 이유를 설명한다.

---

ㅁ SPAN Capture에서 Packet이 없으면 Source가 안 보냈을까?

SPAN 구성도 검증해야 한다.

올바른 Source Port 또는 VLAN을 Mirror했는가?
Ingress와 Egress 방향이 모두 포함됐는가?
SPAN Destination Port가 과부하되지 않았는가?
Encapsulation과 VLAN Tag를 보존했는가?

 

Mirror Traffic 합계가 Capture Port 용량을 넘으면 SPAN에서 Packet이 Drop될 수 있다.

SPAN PCAP의 부재를 실제 Data Plane 부재로 해석하기 전에 Mirror Counter와 구성을 확인한다.

---

ㅁ PCAP는 왜 민감한 정보일까?

Packet Capture에는 다음 정보가 들어갈 수 있다.

• 내부 IP와 Network 구조
• DNS Query
• 평문 HTTP Header와 Body
• Cookie와 Token
• Email, File과 개인정보
• TLS Handshake Metadata
• 취약한 Protocol의 Credential

장애 분석이라는 이유로 필요 이상 Traffic을 장시간 수집하면 새로운 보안 위험을 만든다.

최소 범위 Capture
접근 권한 제한
암호화된 저장과 전송
보존 기간과 안전한 삭제
공유 전 Redaction
감사 기록

Session Key Log와 복호화된 PCAP는 특히 더 엄격하게 다룬다.

Production Capture는 조직의 승인과 개인정보 정책을 따라야 한다.

---

ㅁ 좋은 장애 기록은 무엇을 포함할까?

다음 Context를 함께 남긴다.

Incident 시간과 Timezone
Source Host, Namespace, Address와 Port
Destination Name, Address와 Port
IPv4 또는 IPv6
실제 Application 요청과 Error
Capture Host, Interface, Direction
Capture 시작·종료 시각
Capture와 Display Filter
Snaplen과 Packet Drop Counter
Offload와 SPAN 구성
관련 Rule ID, Conntrack와 Log

PCAP 파일만 전달하면 다음 분석자가 관찰 범위를 다시 추측해야 한다.

증거를 재현 가능한 문장과 함께 전달한다.

---

ㅁ 계층별 질문과 도구를 연결하면

질문	먼저 볼 State·도구	Packet에서 찾을 증거	아직 증명하지 않는 것
Interface가 준비됐나?	ip -s link, ip addr	ARP/NDP와 실제 TX/RX	End-to-End Route
어느 길로 나가나?	ip route get, ip rule	Source, Next Hop, TTL	중간 Router의 전체 경로
Next Hop을 찾았나?	ip neigh	ARP Request/Reply, NDP	Remote Service 상태
이름이 맞나?	dig	DNS Query/Response, RCODE	선택된 Address의 Service
ICMP 왕복이 되나?	ping	Echo Request/Reply	TCP·TLS·Application
중간 응답은 어디까지인가?	traceroute	TTL Probe, Time Exceeded	고정된 전체 경로
TCP Port가 연결되나?	nc, ss	SYN/SYN-ACK/ACK 또는 RST	TLS와 업무 처리
TLS Identity가 맞나?	openssl, curl -v	ClientHello, ServerHello, Alert	Application Authorization
HTTP가 응답하나?	curl, Access Log	TLS Record와 Connection 종료	모든 API와 Backend Health
어디에서 Packet이 사라지나?	Multi-point tcpdump	동일 Flow의 지점별 존재	장비 내부 Drop Reason

 

도구 하나가 다음 계층의 질문까지 대신하지 않는다.

---

ㅁ 가설 기반 진단은 어떻게 반복할까?

1. 관찰된 증상을 한 문장으로 제한
2. 가능한 원인을 계층별로 나눔
3. 후보를 구분할 가장 싼 증거 선택
4. 명령 또는 Capture 실행
5. 결과가 증명한 범위 기록
6. 남은 후보로 다음 질문 이동

 

예를 들어 HTTPS Timeout을 보자.

가설 A: DNS가 잘못된 Address 반환
→ dig와 Application Resolver 결과 비교

가설 B: TCP SYN이 Drop
→ Client와 Firewall 양쪽 Capture

가설 C: TLS Certificate 문제
→ TCP 성공 후 openssl 검증 결과

가설 D: HTTP Backend 지연
→ TLS 성공, Access Log와 Trace 확인

 

처음부터 모든 Packet을 읽지 않고 각 증거가 후보를 어떻게 나누는지 설계한다.

---

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 진단 State와 증거로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
우리 건물의 문과 주소 확인	Interface / Address State	Local Link와 IP 설정 확인
어떤 우체국에 맡길지 조회	Route Lookup	Next Hop, Interface와 Source 선택
옆 우체국의 실제 위치 장부	ARP / NDP Neighbor Table	Next-Hop IP를 Link Address에 연결
수신인 이름을 주소록에서 찾음	DNS Query	Name을 A·AAAA 등 Resource Record로 해석
창구가 열렸는지 시험	TCP Probe	SYN Handshake 또는 RST 관찰
봉인과 신분증을 확인	TLS Probe	Certificate, Hostname, Cipher와 Alert 검증
길목마다 설치한 관찰소	Multi-point Capture	같은 Flow의 지점별 Packet 존재 비교
관찰소가 기록한 봉투 일부	PCAP	특정 Interface·시간·Filter에서 수집한 Packet
우체국 내부 처리 장부	Firewall / Conntrack / Application Log	Packet 밖의 Policy와 Process State 제공
관찰 카메라 자체가 놓친 장면	Capture Drop	Buffer·CPU·SPAN 한계로 PCAP에서 누락
포장 전후 크기가 다르게 보임	NIC Offload	Capture 위치 때문에 Wire와 다른 Packet 표현
봉인된 편지의 겉면만 관찰	Encrypted Payload	Metadata는 보이지만 Application 평문은 숨겨짐

 

진단 흐름을 한 장면으로 모으면 다음과 같다.

Configuration State
ip link / addr / route / neigh
            ↓
Name과 Protocol Probe
dig / ping / traceroute / nc / curl / openssl
            ↓
Packet Evidence
Client ─ Firewall In ─ Firewall Out ─ Server
            ↓
Internal State와 의미
Rule Counter / Conntrack / TLS / Application Log
            ↓
가설 제거와 다음 관찰

---

ㅁ 격리된 Linux 환경에서 Multi-point Evidence를 만들기

다음 실습은 ip, iptables, tcpdump, python3, curl, timeout이 있는 개인 Linux VM에서 수행한다.

새 Network Namespace 안에서만 TCP 8080을 Drop한다.

cap-client                 cap-router                 cap-server
10.26.1.2 ────────── 10.26.1.1 | 10.26.2.1 ──────── 10.26.2.2

 

Namespace와 가상 Link를 만든다.

sudo ip netns add cap-client
sudo ip netns add cap-router
sudo ip netns add cap-server

sudo ip link add veth-cc type veth peer name veth-cri
sudo ip link add veth-cro type veth peer name veth-cs

sudo ip link set veth-cc netns cap-client
sudo ip link set veth-cri netns cap-router
sudo ip link set veth-cro netns cap-router
sudo ip link set veth-cs netns cap-server

 

Address와 Interface를 설정한다.

sudo ip -n cap-client addr add 10.26.1.2/24 dev veth-cc
sudo ip -n cap-router addr add 10.26.1.1/24 dev veth-cri
sudo ip -n cap-router addr add 10.26.2.1/24 dev veth-cro
sudo ip -n cap-server addr add 10.26.2.2/24 dev veth-cs

sudo ip -n cap-client link set lo up
sudo ip -n cap-router link set lo up
sudo ip -n cap-server link set lo up
sudo ip -n cap-client link set veth-cc up
sudo ip -n cap-router link set veth-cri up
sudo ip -n cap-router link set veth-cro up
sudo ip -n cap-server link set veth-cs up

 

Route와 IPv4 Forwarding을 설정한다.

sudo ip -n cap-client route add default via 10.26.1.1
sudo ip -n cap-server route add default via 10.26.2.1
sudo ip netns exec cap-router \
  sysctl -w net.ipv4.ip_forward=1

 

Server Terminal에서 HTTP Server를 실행한다.

sudo ip netns exec cap-server \
  python3 -m http.server 8080 --bind 10.26.2.2

 

Router가 Client에서 Server로 가는 TCP 8080을 Drop하게 한다.

sudo ip netns exec cap-router \
  iptables -I FORWARD 1 \
  -i veth-cri -o veth-cro \
  -p tcp --dport 8080 -j DROP

---

ㅁ 세 지점에서 동시에 Capture하기

각 명령을 별도 Terminal에서 시작한다. 15초 뒤 자동 종료되므로 모두 시작한 직후 Client 요청을 실행한다.

Client Capture:

sudo ip netns exec cap-client \
  timeout 15 tcpdump -nn -i veth-cc -s 0 \
  -w /tmp/cap-client-drop.pcap 'tcp port 8080'

 

Router Capture:

sudo ip netns exec cap-router \
  timeout 15 tcpdump -nn -i any -s 0 \
  -w /tmp/cap-router-drop.pcap 'tcp port 8080'

 

Server Capture:

sudo ip netns exec cap-server \
  timeout 15 tcpdump -nn -i veth-cs -s 0 \
  -w /tmp/cap-server-drop.pcap 'tcp port 8080'

 

Client에서 HTTP 요청을 보낸다.

sudo ip netns exec cap-client \
  curl --connect-timeout 3 http://10.26.2.2:8080/

 

예상 관찰은 다음과 같다.

Client PCAP
→ SYN과 Retransmission 보임

Router PCAP
→ veth-cri Ingress의 SYN 보임
→ veth-cro Egress에는 SYN 없음

Server PCAP
→ SYN 없음

 

Router Rule Counter를 확인한다.

sudo ip netns exec cap-router \
  iptables -L FORWARD -n -v --line-numbers

이 증거는 Router의 FORWARD Drop Rule과 Match했다는 범위까지 강하게 좁힌다.

PCAP만으로 Rule ID를 알게 된 것이 아니라 Rule Counter를 함께 확인했기 때문에 Policy 이유를 연결할 수 있다.

---

ㅁ 저장한 PCAP를 Command Line에서 비교하기

sudo tcpdump -nn -r /tmp/cap-client-drop.pcap 'tcp port 8080'
sudo tcpdump -nn -r /tmp/cap-router-drop.pcap 'tcp port 8080'
sudo tcpdump -nn -r /tmp/cap-server-drop.pcap 'tcp port 8080'

다음 표를 직접 채운다.

관찰 지점	SYN	SYN-ACK	Retransmission	해석
Client	보임	없음	보임	응답을 받지 못해 재시도
Router Ingress	보임	없음	보임	Client에서 Router까지 도착
Router Egress	없음	없음	없음	Router 내부에서 전달되지 않음
Server	없음	없음	없음	Server 도착 전 범위에서 중단

any PCAP에서는 Interface ID를 확인해 Ingress와 Egress를 분리한다.

---

ㅁ Drop Rule을 제거한 뒤 성공 흐름과 비교하기

Drop Rule을 제거한다.

sudo ip netns exec cap-router \
  iptables -D FORWARD \
  -i veth-cri -o veth-cro \
  -p tcp --dport 8080 -j DROP

 

같은 세 Capture를 새 파일 이름으로 다시 실행한다.

/tmp/cap-client-ok.pcap
/tmp/cap-router-ok.pcap
/tmp/cap-server-ok.pcap

 

Client에서 curl을 다시 실행한다.

sudo ip netns exec cap-client \
  curl --connect-timeout 3 http://10.26.2.2:8080/

 

성공 PCAP에서는 다음 흐름을 기대할 수 있다.

SYN
SYN-ACK
ACK
HTTP Request Data
HTTP Response Data
FIN 또는 Connection 종료

 

실패와 성공 Capture를 비교하면 정상 기준선에서 사라진 첫 사건을 찾기 쉽다.

Server Terminal의 HTTP Server를 Ctrl+C로 종료한 뒤 Namespace를 삭제한다.

sudo ip netns del cap-client
sudo ip netns del cap-router
sudo ip netns del cap-server

 

timeout, iptables와 tcpdump Option은 Linux 배포판과 Version에 따라 다를 수 있다.

실제 Host Firewall을 실습용으로 바꾸지 않는다.

PCAP에는 HTTP Directory Listing 같은 Payload가 포함될 수 있으므로 /tmp 파일도 실습 후 조직 정책에 맞게 삭제한다.

---

ㅁ 핵심 정리

• Packet Capture는 특정 Host·Interface·방향·시간·Filter에서 관찰한 사실이며 Network 전체의 전지적 기록이 아니다.
• 도구를 열기 전에 Source, Destination, Protocol과 관찰할 사건을 질문으로 정의해야 한다.
• ip link, ip addr, ip route get, ip neigh는 Local Interface, Source·Route와 Next-Hop State를 Packet보다 먼저 확인한다.
• dig는 DNS Answer와 RCODE를, nc는 Transport 연결을, curl과 openssl은 TLS·Application 단계를 분리한다.
• Capture Filter는 저장 전 Packet을 제외하고 Display Filter는 저장된 Packet의 화면만 좁힌다.
• Snaplen, Capture Buffer, CPU·Disk와 SPAN Capacity 때문에 PCAP 자체에서 Packet이 누락될 수 있다.
• Promiscuous Mode는 Switch가 해당 Port로 보내지 않은 Unicast Traffic까지 가져오지 못한다.
• any Interface, Bridge와 veth Capture는 같은 논리적 Packet을 여러 번 보여 줄 수 있다.
• Checksum Offload는 Host Capture의 Bad Checksum을, TSO/GSO/GRO/LRO는 Wire와 다른 Packet 크기를 만들 수 있다.
• Wireshark의 tcp.analysis.*는 Header Flag가 아니라 Capture 관점의 분석 결과다.
• Client의 SYN Retransmission은 응답 부재를 보여 주지만 Forward Packet과 Return Reply 중 어디에서 Drop됐는지 말하지 않는다.
• Server NIC Capture에 Data가 보이는 것과 Application이 읽고 업무를 처리한 것은 다른 사건이다.
• Multi-point Capture는 Packet이 마지막으로 보인 지점과 처음 사라진 지점 사이로 위치 범위를 줄인다.
• 정확한 Drop 이유는 Rule Counter, Conntrack, Route, Interface Counter와 Application Log를 추가로 연결해야 한다.
• 여러 PCAP의 One-Way 시간을 비교하려면 Clock Synchronization과 Timestamp 정확도가 필요하다.
• PCAP와 TLS Key Log는 Credential과 개인정보를 포함할 수 있으므로 최소 수집, 접근 통제와 보존 정책이 필요하다.

 

핵심 용어: Evidence-Based Troubleshooting, Interface State, Route Lookup, Neighbor Table, dig, netcat, curl, openssl s_client, tcpdump, Wireshark, Packet Capture, PCAP, Capture Point, Capture Filter, Berkeley Packet Filter, BPF, Display Filter, Snaplen, Capture Drop, Promiscuous Mode, SPAN, Network TAP, Checksum Offload, TSO, GSO, GRO, LRO, Expert Info, Multi-point Capture, Clock Synchronization, NTP, PTP, Rule Counter, Conntrack, Application Log

 

Packet은 거짓말하지 않는다고 말하지만, Capture는 모든 Packet을 보지 않는다.
어느 지점에서 무엇을 보았고 무엇은 보지 못했는지 관찰 범위를 적을 때 PCAP는 추측을 줄이는 증거가 된다.

---

ㅁ 다음 이야기

이제 이름, Route, Neighbor, Transport, TLS와 Application을 계층별로 확인하고 Packet이 사라진 구간을 증거로 좁힐 수 있다.

마지막으로 편지 한 통의 전체 여정을 처음부터 끝까지 다시 연결할 차례다.

Browser에 URL을 입력한 순간부터 DNS, ARP, Switch, Gateway, Routing, NAT, TCP, TLS와 HTTP Response까지 어떤 순서로 움직일까? 중간 한 단계가 빠지면 어떤 증거가 남을까?

다음 글에서는 「편지 한 통의 여정을 혼자 설명할 수 있을까?」라는 질문으로 지금까지의 기술을 하나의 Packet Journey와 진단 Checklist에 연결한다.