tcpdump로 pcap 파일을 떴다.
이제 Wireshark로 열어본다.
그런데 처음 보면 화면이 꽤 부담스럽다.
패킷은 수천 개가 있고
색깔은 여러 가지로 칠해져 있고
아래쪽에는 hex byte가 잔뜩 있고
TCP Retransmission 같은 메시지는 빨갛게 보인다처음부터 모든 필드를 해석하려고 하면 금방 지친다.
Wireshark 입문에서 중요한 건 “모든 패킷을 읽는 것”이 아니라,
지금 내가 봐야 할 흐름만 좁히고, 그 흐름에서 누가 무엇을 했는지 확인하는 것
이다.
이 글은 pcap을 처음 열었을 때 어디부터 봐야 하는지 정리한다.
화면 이미지는 설명을 위해 만든 예시다. 실제 장애 pcap을 그대로 캡처한 것이 아니라, 민감한 IP/payload 없이 분석 포인트만 보이도록 구성했다.
Wireshark 화면은 네 구역으로 나눠서 본다
처음에는 아래 네 구역만 기억하면 된다.
각 구역의 역할은 이렇다.
Display Filter
보고 싶은 패킷만 화면에 남기는 필터
Packet List
패킷들이 시간 순서대로 나열되는 곳
Packet Details
선택한 패킷의 Ethernet/IP/TCP/응용 프로토콜 필드를 펼쳐 보는 곳
Packet Bytes
실제 캡처된 byte를 hex/ascii로 보는 곳초보자는 보통 아래 순서로 보면 편하다.
Packet List에서 전체 흐름을 먼저 본다.- 이상해 보이는 패킷을 클릭한다.
Packet Details에서 TCP flag, port, sequence, window를 확인한다.- 필요할 때만
Packet Bytes에서 실제 byte를 본다.
처음부터 Packet Bytes를 붙잡고 있으면 어렵다.
대부분의 네트워크 장애 분석은 Packet List와 Packet Details만으로도 꽤 많이 좁혀진다.
Display Filter와 Capture Filter를 헷갈리지 말자
Wireshark에는 filter라는 말이 두 번 나온다.
Capture Filter
캡처할 때부터 저장할 패킷을 줄이는 필터
Display Filter
이미 캡처된 파일에서 화면에 보이는 패킷만 줄이는 필터초보자가 Wireshark에서 자주 쓰는 건 대부분 Display Filter다.
중요한 점은 이거다.
Display Filter는 pcap 파일을 지우거나 바꾸지 않는다. 화면에서 잠깐 숨길 뿐이다.
그래서 부담 없이 필터를 걸어도 된다.
필터를 지우면 다시 전체 패킷이 보인다.
먼저 쓸 만한 Display Filter
처음부터 복잡한 필터를 외울 필요는 없다.
아래 정도만 자주 써도 충분하다.
ip.addr == 192.168.0.10특정 IP가 출발지든 목적지든 포함된 패킷을 본다.
tcp.port == 443TCP 443번 포트가 출발지든 목적지든 포함된 패킷을 본다.
ip.addr == 192.168.0.10 && tcp.port == 443특정 IP와 특정 TCP port를 같이 본다.
tcp.stream eq 0특정 TCP 연결 하나만 본다.
tcp.analysis.retransmissionWireshark가 재전송으로 판단한 패킷만 본다.
tcp.flags.reset == 1RST 패킷만 본다.
tcp.window_size == 0TCP receive window가 0으로 광고된 패킷을 본다.
dnsDNS 패킷만 본다.
필터는 “좁히는 도구”다
Display Filter를 잘 쓰면 수천 개 패킷 중에서 내가 볼 것만 남길 수 있다.
예를 들어 특정 TCP stream에서 재전송만 보고 싶다면:
tcp.stream eq 3 && tcp.analysis.retransmission이런 식으로 볼 수 있다.
하지만 여기서 조심할 점이 있다.
필터를 너무 좁게 걸면 전후 맥락을 놓친다.
예를 들어 재전송만 보면:
[TCP Retransmission]
[TCP Retransmission]
[TCP Retransmission]만 보인다.
그런데 실제로 중요한 건 재전송 바로 앞뒤다.
재전송 직전에 ACK가 왔나?
Duplicate ACK가 반복됐나?
Window가 0으로 줄었나?
상대가 RST를 보냈나?그래서 나는 보통 이렇게 본다.
ip.addr == ... && tcp.port == ...로 큰 흐름을 먼저 본다.- 문제가 되는 패킷 번호를 찾는다.
- 그 근처 전후 10~20개 패킷을 같이 본다.
- 그 다음
tcp.analysis.retransmission,tcp.flags.reset == 1같은 필터로 좁힌다.
필터는 결론을 내리는 도구가 아니라, 볼 구간을 찾는 도구에 가깝다.
TCP stream 하나만 따라가기
한 서버와 여러 연결이 동시에 오가면 화면이 금방 복잡해진다.
이럴 때는 TCP stream 단위로 좁히면 좋다.
관심 있는 패킷 하나를 선택하고:
우클릭 -> Follow -> TCP Stream또는 필터를 직접 쓴다.
tcp.stream eq 0tcp.stream 번호는 Wireshark가 TCP 연결별로 붙여주는 번호라고 생각하면 된다.
한 TCP 연결만 보면 다음이 훨씬 잘 보인다.
- 3-way handshake가 성공했는지
- 데이터가 어느 방향으로 오갔는지
- 누가 FIN/RST를 먼저 보냈는지
- 재전송이 어느 시점부터 생겼는지
- 응답이 늦은 건지, 아예 안 온 건지
Follow TCP Stream은 “대화만 모아보기”다
Follow TCP Stream은 해당 TCP 연결의 payload를 한 창에 모아서 보여준다.
텍스트 기반 프로토콜이면 바로 읽기 좋다.
예를 들어 HTTP, Redis, SMTP 같은 프로토콜은 ASCII로 보면 흐름이 잘 보인다.
반대로 DoIP, SOME/IP, 자체 binary protocol처럼 바이너리 성격이 강하면 HEX Dump나 Raw가 낫다.
TLS/HTTPS는 주의해야 한다.
암호화된 payload는 복호화 키가 없으면 내용이 보이지 않는다.
그래도 볼 수 있는 정보는 있다.
- TCP 연결이 성립했는지
- TLS handshake가 어디까지 갔는지
- Server Name Indication(SNI)이 보이는지
- 인증서 교환이 있었는지
- 어느 방향에서 끊었는지
- 재전송/지연/윈도우 문제가 있는지
즉 HTTPS라고 해서 Wireshark가 쓸모없는 건 아니다.
payload 내용은 못 봐도, 연결과 타이밍 문제는 여전히 볼 수 있다.
TCP 문제를 볼 때 먼저 확인할 것
TCP 장애 분석은 보통 아래 순서로 보면 덜 헤맨다.
1. SYN이 나갔나
클라이언트가 서버로 SYN을 보내는지 본다.
client -> server [SYN]SYN이 안 보이면 애플리케이션이 실제로 연결을 시도했는지부터 봐야 한다.
2. SYN/ACK가 돌아왔나
서버가 응답하면 SYN/ACK가 보여야 한다.
server -> client [SYN, ACK]SYN만 반복되고 SYN/ACK가 없으면:
- 서버까지 안 갔거나
- 서버가 응답하지 않거나
- 방화벽/보안그룹/라우팅 문제일 수 있다
3. 누가 RST를 보냈나
RST는 강제 종료 신호다.
필터는 이렇게 볼 수 있다.
tcp.flags.reset == 1RST가 보이면 “RST를 누가 보냈는지”가 중요하다.
client -> server [RST]
server -> client [RST]방향을 보지 않고 “RST가 있다”만 보면 결론이 틀어지기 쉽다.
4. FIN인지 RST인지 구분한다
FIN은 정상 종료 흐름에서 자주 보인다.
RST는 더 급한 종료다.
FIN: 정상적으로 닫자
RST: 이 연결은 더 못 받겠다 / 상태가 없다 / 강제로 끊겠다둘 다 연결 종료와 관련 있지만 의미가 다르다.
5. Retransmission은 원인이 아니라 증상일 수 있다
TCP Retransmission이 보이면 패킷 손실일 수도 있고, ACK가 늦거나 안 온 것일 수도 있다.
하지만 재전송 자체가 원인은 아니다.
재전송을 보면 바로 앞뒤를 봐야 한다.
상대 ACK가 안 왔나?
Duplicate ACK가 반복됐나?
Window가 0으로 줄었나?
캡처 위치에서 한쪽 방향만 빠진 건 아닌가?Wireshark가 빨갛게 표시했다고 해서 무조건 네트워크 장비 문제는 아니다.
캡처 위치, 오프로딩, 캡처 누락 때문에 경고처럼 보일 수도 있다.
시간 기준을 바꾸면 보기 편하다
Wireshark의 시간 표시가 헷갈릴 때가 있다.
처음에는 absolute time보다 “캡처 시작 후 몇 초”가 편한 경우가 많다.
메뉴에서 바꿀 수 있다.
View -> Time Display Format -> Seconds Since Beginning of Capture이렇게 보면 장애 재현 시점과 맞추기 쉽다.
0.000000 SYN
0.018421 SYN/ACK
0.042031 Client Hello
2.146201 Retransmission로그에 장애 발생 2초 후 같은 힌트가 있으면 특히 좋다.
컬럼을 추가하면 분석이 빨라진다
자주 보는 필드는 컬럼으로 빼두면 편하다.
예를 들어 TCP stream 번호를 자주 보면:
- Packet Details에서
Transmission Control Protocol을 펼친다. Stream index같은 필드를 찾는다.- 우클릭해서
Apply as Column을 누른다.
그러면 Packet List에서 바로 stream 번호를 볼 수 있다.
초보자에게 특히 유용한 컬럼은 이런 것들이다.
- TCP stream index
- TCP length
- Window size
- Delta time
- Protocol
- Info
컬럼을 잘 세팅해두면 매번 Details를 펼치지 않아도 된다.
색깔을 너무 믿지 말자
Wireshark는 패킷에 색을 칠해준다.
빨간색, 검은색, 노란색이 보이면 뭔가 큰일 난 것처럼 느껴진다.
하지만 색깔은 힌트일 뿐이다.
예를 들어 TCP Retransmission은 실제 문제일 수도 있지만,
캡처 위치 때문에 그렇게 보일 수도 있다.
특히 이런 상황에서는 오해가 생길 수 있다.
- 한쪽 방향 패킷만 캡처됨
- NIC offload 때문에 checksum이 이상해 보임
- 캡처 시작 전에 이미 TCP 연결이 만들어져 있음
- SPAN/mirror 포트에서 일부 패킷이 드롭됨
색깔이 보이면 “왜 이런 색이 나왔지?”라고 질문해야지,
색깔만 보고 바로 결론을 내리면 위험하다.
초보자용 분석 순서
pcap을 처음 열면 이 순서로 보면 된다.
1. 대상 IP/port가 맞는지 확인
2. DNS가 필요한 경우 DNS query/response 확인
3. TCP 3-way handshake 확인
4. tcp.stream 하나로 좁히기
5. 누가 먼저 FIN/RST를 보냈는지 확인
6. retransmission/duplicate ACK/window zero가 있는지 확인
7. 문제가 된 패킷 앞뒤 10~20개를 같이 보기
8. 필요하면 Follow TCP Stream으로 payload 흐름 확인핵심 질문은 네 개다.
내가 보낸 패킷이 실제로 나갔나?
상대 응답이 돌아왔나?
어느 방향에서 먼저 끊었나?
패킷이 안 보이는 위치가 어디인가?이 질문에 답하면,
애플리케이션 문제인지, 서버 문제인지, 중간 네트워크 문제인지 꽤 많이 좁힐 수 있다.
tcpdump 글과 같이 보면 좋은 흐름
실무에서는 보통 이렇게 간다.
1. 서버에서 tcpdump로 pcap 저장
2. Wireshark에서 pcap 열기
3. Display Filter로 대상 IP/port 좁히기
4. tcp.stream 하나를 잡기
5. handshake, FIN/RST, retransmission, window를 확인
6. 필요하면 Follow TCP Stream으로 payload 보기즉 tcpdump는 “캡처하는 도구”,
Wireshark는 “분석하는 도구”로 보면 된다.
정리
Wireshark는 처음엔 복잡해 보이지만,
처음부터 다 볼 필요는 없다.
- Display Filter로 화면을 좁힌다.
- Packet List에서 시간 순서 흐름을 본다.
- Packet Details에서 TCP/IP 필드를 확인한다.
- Packet Bytes는 필요할 때만 본다.
- TCP stream 하나로 좁혀서 연결 단위로 본다.
- Follow TCP Stream으로 payload 흐름을 확인한다.
- 빨간색/경고는 결론이 아니라 힌트로 본다.
초보 단계에서 목표는 하나다.
“누가, 언제, 어떤 방향으로, 무엇을 보냈는지”를 pcap에서 확인하는 것
이 감각이 생기면 Wireshark는 훨씬 덜 무섭다.