📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 175편
이전 글: 174. Next Hop · 다음 글: 176. NAT
Routing 경로 분석은 "이 통신이 실제로 어떤 장비들을 거쳐 갔는가(또는 가지 못했는가)"를 증거로 확인하는 작업입니다. 관제에서는 다음 질문에 답할 때 필요합니다.
TTL이 줄어드는 원리는 36. TTL과 네트워크 경로, traceroute의 동작 원리는 37. Traceroute의 동작 원리에서 다뤘습니다. 이 글은 도구와 장비 명령을 어떤 순서로 조합해 판단하는가에 집중합니다.
| 방법 | 보여 주는 것 | 한계 |
|---|---|---|
장비 테이블 조회 (ip route get, show ip route) | 각 장비가 지금 선택하는 경로 | 과거 시점은 알 수 없음 |
| traceroute / mtr | 현재 응답하는 홉의 순서와 지연 | ICMP를 막는 홉은 *, 복귀 경로는 안 보임 |
| 구간별 패킷 캡처 | 실제로 지나간 패킷, MAC·TTL 변화 | 캡처 지점을 미리 확보해야 함 |
| 보안장비·Flow 로그 | 과거 시점의 통과 기록 | 로그가 없는 장비 구간은 공백 |
경로 분석은 출발지에서 목적지로 한 홉씩, 그리고 다시 돌아오는 방향으로 진행합니다.
① 출발지 호스트: ip route get <목적지> → 첫 next hop·출구 확인
↓
② 첫 홉 장비: show ip route <목적지> / ip route get <목적지> → 다음 홉
↓ (목적지에 닿을 때까지 반복, 각 홉이 보안장비인지 표시)
③ 목적지 호스트: ip route get <출발지> → 복귀 첫 홉
↓
④ 복귀 경로를 같은 방식으로 추적
↓
⑤ 비교: 왕복 경로가 같은가? 방화벽이 양방향 모두에 있는가?
↓
⑥ traceroute·캡처·로그로 실제 통과 여부 교차 확인
③과 ④가 빠지기 쉬운 부분입니다. 라우팅 테이블은 가는 방향만 정하므로, 응답이 다른 길로 돌아오는 비대칭 라우팅이 생길 수 있습니다. 상태 기반 방화벽(185. Stateful Firewall)은 한쪽 방향만 보면 연결을 인식하지 못해 응답이나 후속 패킷을 차단할 수 있습니다.
경로 추적 도구의 기본 동작 차이입니다.
| 도구 | 기본 프로브 | 참고 옵션 |
|---|---|---|
traceroute (Linux) | UDP, 목적지 포트 33434부터 증가 | -I ICMP, -T -p 443 TCP SYN(root 필요), -n 이름 해석 생략 |
tracert (Windows) | ICMP Echo | -d 이름 해석 생략 |
tracepath (Linux) | UDP, 경로 MTU도 함께 표시 | root 권한 불필요 |
mtr | ICMP (옵션으로 UDP·TCP) | -r -c 10 보고서 모드, -n |
방화벽이 UDP 고포트나 ICMP를 막는 환경에서는 실제 서비스 포트로 TCP 프로브(traceroute -T -p 443)를 보내야 방화벽 뒤 경로가 보이는 경우가 많습니다. 도구마다 막히는 결과가 다르다는 것 자체가 방화벽 정책의 단서입니다.
증상별로 의심할 원인입니다.
| 증상 | 의심 원인 | 확인 방법 |
|---|---|---|
특정 홉 이후 계속 * * * | 경로 끊김 또는 이후 구간이 프로브 차단 | TCP 프로브로 재시도, 해당 장비 테이블 조회 |
| 같은 두 홉이 번갈아 반복 | 라우팅 루프 | 두 장비의 해당 목적지 경로 비교 |
| 첫 홉이 예상 게이트웨이가 아님 | 기본 경로·정적 경로 변경, 두 번째 NIC | ip route get, 인터페이스 목록 |
| traceroute는 성공, 서비스 접속은 실패 | 경로가 아니라 정책(ACL·방화벽) 차단 | 방화벽 차단 로그 |
| SYN은 나가는데 응답이 없음 | 복귀 경로 없음 또는 비대칭 | 목적지 측에서 출발지로의 경로 조회 |
실습 예시 — 사용자망 VM(192.168.10.20)에서 서버망(10.20.0.15)까지 경로를 분석합니다. traceroute·mtr가 없으면 설치합니다.
# 설치 — Rocky
sudo dnf install -y traceroute mtr
# 설치 — Ubuntu
sudo apt install -y traceroute mtr-tiny
ip route get 10.20.0.15
traceroute -n 10.20.0.15
sudo traceroute -n -T -p 443 10.20.0.15
mtr -n -r -c 10 10.20.0.15
출력 형식 예시(값은 환경마다 다름):
traceroute to 10.20.0.15 (10.20.0.15), 30 hops max, 60 byte packets
1 192.168.10.1 0.512 ms 0.433 ms 0.401 ms
2 10.0.12.2 1.102 ms 0.998 ms 1.051 ms
3 10.20.0.15 1.420 ms 1.388 ms 1.377 ms
첫 홉은 R1, 두 번째 홉은 R2입니다. 설계상 사용자망과 서버망 사이에 방화벽이 있어야 한다면, 방화벽 IP가 홉 목록에 없다는 점을 먼저 확인해야 합니다(단, 투명 모드 방화벽은 홉으로 나타나지 않으므로 구성도를 함께 봅니다).
실습 예시 — 각 홉 장비와 목적지에서의 확인입니다(Cisco IOS 계열 명령 포함, 출력 생략).
R1# show ip route 10.20.0.15
R1# show ip cef exact-route 192.168.10.20 10.20.0.15 ! 부하 분산 시 실제 선택 경로
R2# show ip route 192.168.10.20 ! 복귀 경로
# 목적지 서버에서 복귀 경로
ip route get 192.168.10.20
📷 [실습 화면 삽입 위치] 같은 목적지에 대해
traceroute -n(UDP)과traceroute -T -p 443(TCP) 결과를 나란히 놓아, 방화벽 이후 구간이 한쪽에서만* * *로 보이는 차이를 표시한 화면
| 흔적 | 경로 분석에서의 의미 |
|---|---|
| 방화벽 세션 로그 | 해당 통신이 방화벽을 통과했다는 증거 |
| NetFlow / IPFIX | 어느 라우터 인터페이스로 들어오고 나갔는가 |
| ICMP Time Exceeded(Type 11) 다량 | 경로 추적 시도 또는 라우팅 루프 |
| 한 방향 세션만 기록된 방화벽 로그 | 비대칭 라우팅 가능성 |
관제자가 확인할 질문
오탐 주의: 이중화·부하 분산 환경에서는 같은 목적지라도 홉이 번갈아 보일 수 있으며 루프가 아닙니다. 사건 분석에서는 현재 경로로 과거를 단정하지 말고, 사건 시각의 장비 로그로 확인합니다.
ip route get, show ip route <목적지>는 현재 선택 경로를, traceroute·mtr은 응답하는 홉 순서를 보여 줍니다.