패킷 분석

지금까지 ping, traceroute, curl 같은 도구로 네트워크 상태를 확인했습니다.

이 도구들은 연결이 되는가, 응답이 오는가를 알려주지만, 실제로 어떤 패킷이 오가는지는 보여주지 않습니다.

패킷 분석은 캡처된 프레임과 프로토콜 필드를 기준으로 통신 흐름을 직접 확인하는 진단 방법입니다.

tcpdump — 커맨드라인 패킷 캡처

tcpdump는 Linux/macOS에서 사용하는 커맨드라인 패킷 캡처 도구입니다.

# 80번 포트의 모든 트래픽 캡처
sudo tcpdump -i eth0 port 80

# 특정 호스트와의 통신만 캡처
sudo tcpdump -i eth0 host 192.168.1.100

# 캡처 내용을 파일로 저장 (Wireshark로 열기 가능)
sudo tcpdump -i eth0 -w capture.pcap port 443

# 저장된 파일 읽기
tcpdump -r capture.pcap

유용한 필터 조합들이 있습니다.

# SYN 플래그가 켜진 패킷 캡처 (SYN, SYN-ACK 모두 포함)
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

# ACK 없이 SYN만 있는 패킷 (ECN 플래그가 붙어도 최초 연결 시도에 가까움)
sudo tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

# DNS 관련 53번 트래픽 캡처 (질의와 응답 모두 포함)
sudo tcpdump -i eth0 port 53

# UDP DNS 질의 방향만 좁혀 보기
sudo tcpdump -i eth0 'udp dst port 53'

# 특정 서브넷의 트래픽만 캡처
sudo tcpdump -i eth0 net 10.0.0.0/24

# RST 패킷 캡처 (연결 거부/리셋)
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'

# 패킷 내용을 ASCII로 표시 (HTTP 디버깅)
sudo tcpdump -i eth0 -A port 80

# 패킷 내용을 헥스+ASCII로 표시
sudo tcpdump -i eth0 -X port 80

Wireshark — GUI 패킷 분석

Wireshark는 세계에서 가장 널리 사용되는 패킷 분석 도구입니다.

capture filter는 캡처 단계에서 저장할 패킷을 줄이고, display filter는 저장된 패킷 중 화면에 보일 항목을 고릅니다. Wireshark도 capture filter를 지원하며, tcpdump의 필터는 -r로 파일을 읽을 때도 적용할 수 있습니다. 두 문법을 섞지 않아야 합니다.

디스플레이 필터로 원하는 패킷만 골라볼 수 있습니다.

실전 패킷 분석 예시

HTTP 요청 추적: 평문 HTTP/1.x 연결에서 "Follow → TCP Stream"으로 양방향 바이트 내용을 따라갈 수 있습니다. 개별 패킷의 재전송·정확한 시각은 패킷 목록에서 따로 확인합니다. HTTP/2·QUIC은 해당 프로토콜의 Follow 기능과 하위 스트림 선택을 사용해야 여러 스트림을 구분하기 쉽습니다.

단, HTTPS 트래픽은 복호화 키가 없으면 HTTP 본문이 아니라 TLS 레코드만 보입니다.

TLS 문제 진단: HTTPS는 암호화되어 있어 내용을 볼 수 없지만, TLS 핸드셰이크의 일부 메타데이터는 볼 수 있습니다.

Client Hello의 지원 버전과 암호 스위트, SNI(단 ECH가 없을 때), Server Hello의 선택 결과를 확인할 수 있습니다.

TLS 1.3에서는 인증서 메시지도 핸드셰이크 보호 구간에 들어가므로, 모든 인증서 내용이 항상 평문으로 보인다고 생각하면 안 됩니다.

반복 SYN을 한 관측 위치에서 읽기

아래 표는 실제 캡처 관측이 아닌 학습용 가정 trace입니다. trace는 패킷을 시각 순서로 적은 기록을 뜻합니다. 클라이언트 C(192.0.2.10:50000)와 상대 TCP 끝점 S(198.51.100.20:443) 사이에서 한 번의 연결을 시도한다고 가정합니다. 주소는 문서 예시용이며, 모든 행은 C의 같은 네트워크 인터페이스에서 송신·수신 양방향을 보았다는 설정입니다. 0초는 첫 SYN이고 시각과 재전송 간격은 설명을 위해 정한 값입니다. 실제 OS의 재전송 타이머나 횟수를 측정한 결과가 아닙니다.

표의 Seq는 순서 번호, Ack는 상대에게 다음으로 기대하는 순서 번호입니다. 각 행의 TCP 데이터 길이는 0이며 옵션은 생략했습니다. ACK 플래그가 없는 행의 Ack는 해석하지 않으므로 —로 적었습니다.

이 입력에서는 2·3행을 같은 SYN을 다시 보내는 상황으로 정했습니다. 1–3행을 먼저 읽으면 C 쪽 기록에 응답이 없지만, 4행에서는 C에 도착한 SYN+ACK이 나타납니다. SYN은 순서 번호 하나를 차지하므로 Ack 1001은 Seq 1000의 SYN을 확인하는 값입니다. 세 SYN의 Seq가 같아서 이 Ack만으로 어느 시도에 응답했는지는 구분할 수 없습니다. 5행은 C 쪽에 ACK가 나타난 것이며, 그 ACK가 S에 도착한 모습이나 이후 TLS·HTTP 응답까지 보여 주지는 않습니다.

앞의 표시 필터를 이 표에 대입해 보세요. tcp.flags.syn == 1이면 SYN+ACK도 포함해 1–4행이고, ACK가 없는 SYN만 고르면 1–3행입니다. SYN만 보이는 목록으로 4·5행의 응답 여부를 판단하면 연결이 계속 멈춘 것으로 읽기 쉽습니다. 먼저 필터를 풀어 같은 주소·포트의 양방향 목록에서 후속 응답까지 살펴야 합니다. 이는 가정 표에서 조건을 비교한 것이며 실제 Wireshark 실행 결과가 아닙니다.

초기 응답이 없었던 이유는 아직 둘 이상으로 설명할 수 있습니다.

• 가설 1: 초기 SYN이 S 관측 위치까지 도달하지 못했다. 다음에 필요한 증거는 같은 연결의 첫 두 SYN이 S의 수신 방향에 나타나는지입니다. C에서 송신 방향 패킷이 보였다는 사실만으로 S 도착을 확정할 수 없습니다.
• 가설 2: 초기 SYN은 S에 도달했지만 응답이 C까지 돌아오지 못했다. S의 수신 방향에 SYN이 있고 송신 방향에 SYN+ACK도 있는지, 그 응답이 C의 수신 방향에는 있는지를 대조하면 앞 가설과 구분하는 데 도움이 됩니다. S에 SYN만 보이면 응답 생성 여부를 더 확인해야 하며 귀환 경로 문제로 바로 확정할 수 없습니다.

두 관측 위치를 대조할 때도 시간대·시계 차이, 인터페이스와 방향, 필터, 캡처 손실을 먼저 맞춰야 합니다. NAT가 있으면 변환 전후 주소·포트의 대응도 필요합니다. TCP를 끝내는 프록시가 있다면 프록시 앞뒤는 다른 연결입니다. 해당 위치에 행이 없다는 사실만으로 방화벽 DROP을 확정할 수 없고, 이 가정 입력에는 그런 원인을 판정할 실제 증거가 없습니다.

자주 만나는 문제 사례

네트워크 트러블슈팅의 핵심은 추측하지 않고 확인하는 것입니다.

아마 방화벽 문제일 거야라는 추측에 머물지 않고, 패킷을 캡처하여 SYN이 나갔는데 응답이 없으니 방화벽 DROP, 라우팅 문제, 호스트 다운, 반환 경로 문제를 순서대로 의심해야 한다고 판단하는 것입니다.

캡처는 인터페이스·방향·시각·필터·손실 통계를 함께 기록해야 비교할 수 있습니다. 암호화된 페이로드나 캡처 지점 밖의 사건을 추정과 섞지 말고, 공유 파일에 인증 정보·개인 데이터가 포함됐는지도 확인합니다.