서비스에 장애가 발생할 때 로그 분석과 함께 가장 먼저 해봐야 할 것이 네트워크 패킷 분석이다. 회사나 개인 프로젝트를 진행하면서 발생할 장애 상황들에 대비하여 네트워크 패킷 분석에 익숙해지기 위해 이 글을 작성한다.
네트워크 패킷 분석이란?
네트워크 패킷 분석이란, 네트워크 상에서 주고받는 데이터(패킷)를 캡처하고 그 내용을 분석하여 통신 흐름이나 이상 징후를 파악하는 작업이다. 주로 장애 분석, 보안 침해 탐지, 성능 개선 등을 목적으로 수행된다.
패킷(packet) 개념
패킷(packet)은 네트워크 상에서 전달되는 데이터의 최소 단위다. 우리가 메시지를 보내거나 파일을 다운로드할 때, 이 데이터는 여러 개의 패킷으로 잘게 나뉘어 전송되고, 수신 측에서 이를 재조립한다.
패킷은 다음과 같이 크게 두 부분으로 구성된다.
- 헤더(Header): 발신자/수신자의 IP 주소, 포트 번호, 프로토콜 종류(TCP/UDP 등), 패킷 순서 등 메타정보를 포함.
- 페이로드(Payload): 실제 전송하고자 하는 데이터 내용 (예: HTTP 요청/응답 본문).
패킷 분석 도구
- tcpdump
- 리눅스 환경에서 주로 사용하는 텍스트 기반 패킷 캡처 도구다. 실시간 분석과 스크립트 자동화에 유리하다.
- Wireshark
- GUI 기반 도구로, 시각적으로 프로토콜을 분해하고 확인할 수 있다. 다양한 필터 기능과 컬러링 룰, 통계 기능까지 지원하여 상세 분석에 적합하다.
Tcpdump 사용법
주요 사용법은 다음과 같다. CLI로 동작하기 때문에 주요 옵션들만 이해하면 간단히 사용할 수 있다.
sudo tcpdump [옵션] [필터 조건]
1. 옵션 설명
| -i <interface> | 캡처할 네트워크 인터페이스 지정 (예: eth0, en0, ens5 등) |
| -n | DNS 이름 해석 비활성화 (IP로 바로 보여줌) |
| -nn | 포트 번호도 이름 대신 숫자로 표시 (예: http → 80) |
| -v, -vv, -vvv | 출력 정보 상세 수준 조절 |
| -c <숫자> | 지정한 수만큼 패킷 캡처 후 종료 |
| -w <파일> | 패킷을 .pcap 파일로 저장 (Wireshark에서 열 수 있음) |
| -r <파일> | .pcap 파일 읽어서 분석 |
| -s <숫자> | 캡처할 패킷의 바이트 수 (기본 262144, -s 0은 전체 캡처) |
2. 필터 예시
| 특정 IP만 보기 | host 192.168.0.1 |
| 송신 또는 수신 IP 지정 | src 192.168.0.1 / dst 192.168.0.1 |
| 포트 필터링 | port 80, src port 22, dst port 443 |
| 특정 프로토콜만 보기 (tcp/udp) | tcp, udp, icmp |
| AND / OR 조합 | 'host 1.1.1.1 and port 22' |
3. 주요 예시
| en0 인터페이스에서 모든 패킷 보기 | sudo tcpdump -i en0 |
| IP 13.209.x.x 와의 모든 통신 보기 | sudo tcpdump -i en0 host 13.209.x.x |
| 22번 포트와의 통신만 보기 | sudo tcpdump -i en0 port 22 |
| 결과를 pcap 파일로 저장 | sudo tcpdump -i en0 -w result.pcap |
| 저장된 pcap 파일 분석 | tcpdump -nnr result.pcap |
| 3-Way Handshake만 필터 | tcpdump 'tcp[tcpflags] & tcp-syn != 0' 등 활용 |
Wireshark 사용법
Wireshark를 실행하면 위와 같이 네트워크 인터페이스를 선택할 수 있는 화면이 나타난다.
여기서 본인 pc 환경에서 사용하고 있는 네트워크 인터페이스를 선택하면 된다. 참고로 윈도우는 터미널 창에서 ipconfig로 네트워크 인터페이스를 확인할 수 있고, 리눅스/유닉스 기반은 ifcinfig를 통해 확인할 수 있다.
MAC 환경 기준으로 en1은 무선 환경(WIFI), en0는 유선 환경(Ethernet)을 의미한다. 현재 나는 랜선을 연결해서 사용하고 있으므로 en0를 선택하였다.
인터페이스를 선택하면 아래와 같은 화면이 나오게 된다.
화면은 총 6개의 영역으로 나눠져 있으며, 영역 별로 기능이 분리되어 있다.
1. Main Toolbar
주로 사용되는 기능들을 제공하는 툴바이다. 캡처 시작/중지, 파일 열기/저장, 재시작, 통계 보기 등 기능을 제공하는 도구들을 제공한다.
맨 왼쪽부터 기능은 다음과 같다.
- 캡처 시작
- 캡처 중지
- 캡처 재시작
- 캡처 옵션
- 파일(Pcap) 열기
- 패킷 데이터 저장
- 캡처 내용 제거
- 새로고침
- 패킷 검색
- 이전 패킷
- 다음 패킷
- n번째 패킷
- 첫번째 패킷
- 마지막 패킷
- Live 캡처 시 현재 행 위치 고정 ON/OFF
- 각 행을 프로토콜 별로 색칠 ON/OFF
- 화면 확대
- 화면 축소
- 화면 크기 조기화
- 열 너비 재조정
- 창 레이아웃 변경
2. Filter Toolbar
특정 조건을 만족하는 패킷들만 필터링 하는 기능을 제공한다. 특정 IP, Port, Protocol 별로 검색을 할 수 있다.
ex. ip.addr == 13.209.x.x and tcp.port == 22
3. Packet List
캡처된 패킷 목록과 관련 상세정보들을 시간 순서대로 보여주는 영역이다. 각 항목들의 의미는 다음과 같다.
- NO. : 패킷 번호
- Time: 캡쳐된 시간(최초 수집된 패킷 기준)
- Source: 출발지 IP
- Destination: 도착지 IP
- Protocol: 프로토콜
- Length: 패킷 길이
- Info: 기타 정보 (패킷 상태, TCP 제어 플래그 등)
4. Packet Details
패킷 상세 해석 창이다. 선택한 패킷의 각 계층(프레임, Ethernet, IP, TCP 등)을 계층적으로 보여준다. HTTP 헤더 등도 이곳에서 확인 가능하다.
5. Packet Bytes
패킷의 정보를 Hex 값과 ASCII 코드로 출력하는 영역이다. 프로토콜 디코딩, 바이너리 구조 분석 등 고급 분석에 사용된다.
6. Status Bar
패킷 캡처 상태, 패킷 상태 등 Wireshark의 상태를 출력하는 영역이다.
이제 Wireshark를 활용하여 간단히 서버 간의 SSH 통신을 할 때 발생하는 TCP 3-Way Handshake(세션 연결)와 4-Way Handshake(세션 종료) 패킷을 살펴보도록 하자.
Wireshark를 이용한 TCP 3-way Handshake, 4-way Handshake 통신 과정 살펴보기
Wireshark를 통해 로컬 환경(Windows or MAC OS)에서 대상 서버와의 패킷들을 확인해보자.
테스트 환경 구성과 Wireshark 필터는 다음과 같다.
- Local Client: MAC OS (14.34.x.x)
- Remote Server: AWS EC2(13.209.x.x)
- Protocol: SSH(22)
- Wireshark Filter: ip.addr == 13.209.x.x and tcp.port == 22
1. TCP 3-Way Handshake 세션 연결 과정
위 사진은 TCP 3-Way Handshake 통신 과정이고, 아래 사진이 실제 MAC OS(Local)와 EC2(Server) 간에 SSH 연결이 수립될 때 발생한 3-Way Handshake 패킷 흐름을 Wireshark로 캡처한 결과다.
| ① | 14.34.x.x:60675 → 13.209.x.x:22 | SYN | 클라이언트가 서버에 연결 요청 |
| ② | 13.209.x.x:22 → 14.34.x.x:60675 | SYN, ACK | 서버가 연결 요청 수락 및 응답 |
| ③ | 14.34.x.x:60675 → 13.209.x.x:22 | ACK | 클라이언트가 최종 확인 응답, 연결 성립 완료 |
cf. 패킷에 나오는 60675는 클라이언트 쪽의 TCP 소스 포트(Source Port) 번호이다. 해당 포트는 운영체제가 랜덤한 포트번호(49152~65535) 중 하나를 자동으로 할당한다. -> 해당 임시 포트를 ephemeral port(일시적 포트)라고 칭한다.
2. TCP 4-Way Handshake 세션 종료 과정
마찬가지로, 세션 종료 과정도 위 사진의 과정이 아래와 같이 실제로 발생되는 것을 알 수 있다.
| ① | 14.34.x.x:61616 → 13.209.x.x:22 | FIN, ACK | 클라이언트가 연결 종료 요청 |
| ② | 13.209.x.x:22 → 14.34.x.x:61616 | ACK | 서버가 종료 요청 확인 |
| ③ | 13.209.x.x:22 → 14.34.x.x:61616 | FIN, ACK | 서버도 종료 요청 |
| ④ | 14.34.x.x:61616 → 13.209.x.x:22 | ACK | 클라이언트가 최종 확인, 연결 종료 완료 |
Tcpdump를 이용한 TCP 3-way Handshake, 4-way Handshake 통신 과정 살펴보기
로컬 환경(Windows or MAC OS)에서는 Wireshark를 통해 패킷을 분석하면 되지만, 리눅스/유닉스 기반의 서버에서는 tcpdump를 통해 패킷을 분석하는 것이 일반적이므로 tcpdump로도 패킷을 분석해보자.
테스트 환경 구성과 명령어는 다음과 같다.
- Client: AWS EC2(public: 13.209.x.x, private: 172.31.x.x)
- Remote Server: AWS EC2(public: 15.165.x.x, private: 172.31.x.x)
- Protocol: SSH(22)
- 명령어: sudo tcpdump -nni enX0 host 13.209.x.x and port 22
cf. sudo tcpdump -nni enX0 host 13.209.x.x and port 22 -w test.pcap 명령어를 통해 pcap 파일을 생성하고, 로컬 와이어샤크로 패킷을 분석할 수도 있다.
또는 리눅스/유닉스 서버 상에서 tcpdump -nnr test.pcap 명령어를 통해 직접 분석도 가능하다.
cf. scp -i <KEY> <USER>@<REMOTE_IP>:<REMOTE_PATH> <LOCAL_PATH> 명령어를 통해 원격 서버의 파일을 로컬 컴퓨터에 다운로드 할 수 있다.
1. TCP 3-Way Handshake 세션 연결 과정
위 사진의 내용이 아래와 같이 그대로 나와있는 것을 확인할 수 있다.
| ① | 13.209.x.x:59264 → 172.31.x.x:22 | S ([S]) | 클라이언트가 서버에 연결 요청 (SYN) |
| ② | 172.31.x.x:22 → 13.209.x.x:59264 | SYN, ACK ([S.]) | 서버가 연결 요청 수락 및 응답 |
| ③ | 13.209.x.x:59264 → 172.31.x.x:22 | ACK ([.]) | 클라이언트가 최종 응답, 연결 성립 완료 |
2. TCP 4-Way Handshake 세션 종료 과정
마찬가지로 사진의 내용이 아래와 같이 그대로 나와있는 것을 확인할 수 있다.
| ① | 13.209.x.x:48166 → 172.31.x.x:22 | FIN, ACK ([F.]) | 클라이언트가 연결 종료 요청 |
| ② | 172.31.x.x:22 → 13.209.x.x:48166 | ACK ([.]) | 서버가 종료 요청 수신 확인 |
| ③ | 172.31.x.x:22 → 13.209.x.x:48166 | FIN, ACK ([F.]) | 서버도 연결 종료 요청 |
| ④ | 13.209.x.x:48166 → 172.31.x.x:22 | ACK ([.]) | 클라이언트가 종료 확인 응답, 세션 종료 완료 |
마무리
지금까지 Wireshark와 tcpdump를 활용한 패킷 분석 방법을 살펴보았다. 이러한 도구들은 실제로 장애가 발생했을 때 원인을 빠르게 파악하고 문제를 해결하는 데 매우 유용하다.
장애 발생 시 가장 기본적인 접근은 로그 확인이지만, 네트워크 단의 트래픽이 정상적으로 흐르고 있는지를 확인하는 것도 중요하다. 패킷 분석을 통해 서비스가 실제로 도달하고 응답이 오가는지를 눈으로 확인해보자.