우분투 실전 명령어 | tcpdump로 네트워크 패킷 점검

Last updated on 

서버에서 "왜 연결이 안 되지?" 같은 이슈가 생기면 애플리케이션 로그만 봐서는 원인이 안 잡힐 때가 많습니다. 이럴 때 tcpdump로 실제 패킷이 오가는지부터 확인하면 문제 구간이 빠르게 좁혀집니다. 방화벽, 로드밸런서, 잘못된 포트, DNS 오해 같은 문제를 분리할 때 특히 유용합니다.

바로 쓰는 명령어

# 1) 인터페이스 확인 후 특정 포트 트래픽만 보기 (예: 443)
ip -brief link
sudo tcpdump -i eth0 -nn tcp port 443

# 패킷 수 제한해서 짧게 확인
sudo tcpdump -i eth0 -nn tcp port 443 -c 30

# 2) 원격지 IP + 포트 조건으로 캡처 파일 저장
sudo tcpdump -i eth0 -nn host 10.0.2.15 and tcp port 8443 -w /tmp/8443-debug.pcap

# 저장 파일 읽기(재생)
sudo tcpdump -nn -r /tmp/8443-debug.pcap

핵심 옵션/패턴

  • -i <iface>: 캡처 인터페이스 지정. 헷갈리면 ip -brief link로 이름부터 확인하세요.
  • -nn: DNS/서비스명 역해석 비활성화. 숫자로 바로 보여줘서 분석 속도가 빨라집니다.
  • -c <N>: N개 패킷만 캡처하고 종료. 점검 자동화나 짧은 확인에 안전합니다.
  • -w <file> / -r <file>: 캡처 저장/재읽기. 실시간 분석이 어려우면 파일로 먼저 확보해 두는 게 좋습니다.
  • 필터는 BPF 문법으로 조합합니다.
    • host 1.2.3.4
    • tcp port 443
    • src host 10.0.0.10 and dst port 5432

자주 하는 실수

  • 인터페이스를 잘못 선택해서 "패킷이 없다"고 판단하는 실수
    • 클라우드 환경에서는 eth0가 아닐 수 있습니다. 인터페이스 확인부터 하세요.
  • -n/-nn 없이 실행해서 역해석 지연 때문에 느리다고 오해하는 경우
  • 조건 없이 전체 트래픽을 오래 캡처해서 디스크를 과도하게 쓰는 문제
    • 운영 서버에서는 -c, 포트/호스트 필터, 짧은 캡처 구간을 같이 쓰는 게 안전합니다.
  • 암호화 트래픽(HTTPS) 내용이 안 보이는데 tcpdump가 "고장" 났다고 판단하는 실수
    • tcpdump는 패킷 메타데이터/헤더 중심 확인 도구입니다.

검증 방법 (결과 확인 명령어)

# tcpdump 설치/실행 가능 여부
which tcpdump
tcpdump --version

# 실제 캡처 건수 확인(예: 20개만 캡처)
sudo tcpdump -i eth0 -nn tcp port 22 -c 20

# 저장된 pcap 파일 크기/요약 확인
ls -lh /tmp/8443-debug.pcap
sudo tcpdump -nn -r /tmp/8443-debug.pcap | head -n 20

운영 팁

  • 장애 재현이 짧게 일어나는 서비스라면 -w로 먼저 저장하고, 분석은 사후에 하는 방식이 안정적입니다.
  • 개인정보/민감 데이터가 포함될 수 있으니 캡처 파일 보관 경로와 권한을 반드시 제한하세요.
  • 팀 운영 시에는 "어떤 포트/호스트를 몇 초간 캡처했는지"를 장애 기록에 같이 남기면 재현성이 좋아집니다.

출처

  • tcpdump man page
  • Ubuntu Server Guide
  • Wireshark Foundation Documentation