패킷 캡처를 읽는 법 (개념)

한 줄 요약

패킷 캡처는 "누가 거짓말을 하고 있는가" 를 가리는 마지막 심판이다. 다만 이 실습 환경에서는 캡처 권한이 없으므로, 읽는 법을 개념으로 익혀 두고 실습은 ss 와 /proc/net 으로 대신한다.

왜 이게 필요했나

로그는 애플리케이션의 주장이고, ss 는 커널의 요약이다. 둘 다 "패킷이 실제로 어떻게 오갔는가" 를 직접 보여 주지는 않는다. 그래서 다음 세 상황에서는 결국 캡처가 필요하다.

1. 양쪽 로그가 서로 다른 이야기를 할 때 (클라이언트는 보냈다고, 서버는 못 받았다고)
2. 재전송·프래그멘테이션처럼 커널 안에서만 일어나는 일을 봐야 할 때
3. 중간 장비(프록시, LB, NAT)가 무언가를 고치고 있는지 확인해야 할 때

어떻게 동작하나

tcpdump 의 필수 옵션은 손에 꼽는다.

tcpdump -nn -i any 'host 10.0.3.11 and tcp port 8080'tcpdump -nn -i any 'icmp[icmptype] == 3 and icmp[icmpcode] == 4'tcpdump -nn -i any -w /tmp/cap.pcap -c 2000

• -nn 은 호스트 이름과 포트 이름을 해석하지 않는다. 캡처 중 DNS 조회가 다시 나가는 사고를 막는다.
• -i any 는 모든 인터페이스. 컨테이너 환경에서 특히 유용하다.
• -w 로 파일에 저장해 Wireshark 로 열어 본다. 화면에서 읽는 것은 대략의 흐름만.

읽는 요령의 핵심은 TCP 플래그 표기다.

| 표기 | 뜻 | 이때 벌어진 일 |
| --- | --- | --- |
| [S] | SYN | 연결 시도 |
| [S.] | SYN+ACK | 상대가 받아들임 |
| [.] | ACK | 데이터 확인 |
| [P.] | PSH+ACK | 데이터 전송 |
| [F.] | FIN+ACK | 정상 종료 시작 |
| [R] / [R.] | RST | 거절 또는 강제 종료 |

이 표만 있으면 두 가지 실패가 한눈에 갈린다.

• refused: [S] 하나 나가고 [R.] 하나 돌아오고 끝. 두 줄이면 끝난다.
• timeout: 같은 시퀀스의 [S] 가 1초, 2초, 4초 간격으로 반복되고 응답 줄이 아예 없다.

MTU 블랙홀 진단에는 ICMP 타입 3 코드 4(Fragmentation needed)를 잡아 본다. "보안을 위해 ICMP 는 전부 막는다" 는 정책이 그 자체로 장애 요인이 되는 이유가 여기 있다. 막아도 되는 것은 echo request/reply 정도이고, 타입 3 코드 4 는 반드시 통과시켜야 한다. IPv6 에서는 Packet Too Big(타입 2)이 같은 역할을 하며 여기서는 선택의 여지조차 없다.

현장에서 만나는 모습

컨테이너에서는 캡처가 어렵다. 이 실습 환경처럼 capability 가 제거되면 tcpdump 는 소켓을 열지 못한다. 쿠버네티스라면 임시 컨테이너(kubectl debug)로 같은 네트워크 네임스페이스에 진단 파드를 붙이는 것이 표준 우회로다. 노드에 들어갈 수 있다면 노드에서 파드의 veth 를 지정해 캡처한다.

그래서 실무 순서는 이렇게 굳는다. ss 와 curl -w 로 최대한 좁히고, 그래도 두 주장이 갈릴 때만 캡처를 연다. 캡처는 강력하지만 비싸다.

다음에서 할 것

이 코스의 실습은 전부 캡처 없이 진행된다. 대신 /proc/net/tcp 를 직접 읽어 커널이 들고 있는 소켓 상태를 확인하는 단계가 들어 있다 — 캡처 없이 커널의 진실에 가장 가까이 가는 방법이다.