📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 175편
이전 글: 174. Next Hop · 다음 글: 176. NAT

1. 개념

Routing 경로 분석은 "이 통신이 실제로 어떤 장비들을 거쳐 갔는가(또는 가지 못했는가)"를 증거로 확인하는 작업입니다. 관제에서는 다음 질문에 답할 때 필요합니다.

  • 이 트래픽은 방화벽·IDS를 거쳤는가? 거쳤다면 로그가 있어야 합니다.
  • 통신 실패는 경로 문제인가, 정책 차단 문제인가?
  • 요청과 응답이 같은 길로 오갔는가?

TTL이 줄어드는 원리는 36. TTL과 네트워크 경로, traceroute의 동작 원리는 37. Traceroute의 동작 원리에서 다뤘습니다. 이 글은 도구와 장비 명령을 어떤 순서로 조합해 판단하는가에 집중합니다.

방법보여 주는 것한계
장비 테이블 조회 (ip route get, show ip route)각 장비가 지금 선택하는 경로과거 시점은 알 수 없음
traceroute / mtr현재 응답하는 홉의 순서와 지연ICMP를 막는 홉은 *, 복귀 경로는 안 보임
구간별 패킷 캡처실제로 지나간 패킷, MAC·TTL 변화캡처 지점을 미리 확보해야 함
보안장비·Flow 로그과거 시점의 통과 기록로그가 없는 장비 구간은 공백

2. 동작 원리

경로 분석은 출발지에서 목적지로 한 홉씩, 그리고 다시 돌아오는 방향으로 진행합니다.

① 출발지 호스트: ip route get <목적지>  → 첫 next hop·출구 확인
      ↓
② 첫 홉 장비: show ip route <목적지> / ip route get <목적지> → 다음 홉
      ↓   (목적지에 닿을 때까지 반복, 각 홉이 보안장비인지 표시)
③ 목적지 호스트: ip route get <출발지> → 복귀 첫 홉
      ↓
④ 복귀 경로를 같은 방식으로 추적
      ↓
⑤ 비교: 왕복 경로가 같은가? 방화벽이 양방향 모두에 있는가?
      ↓
⑥ traceroute·캡처·로그로 실제 통과 여부 교차 확인

③과 ④가 빠지기 쉬운 부분입니다. 라우팅 테이블은 가는 방향만 정하므로, 응답이 다른 길로 돌아오는 비대칭 라우팅이 생길 수 있습니다. 상태 기반 방화벽(185. Stateful Firewall)은 한쪽 방향만 보면 연결을 인식하지 못해 응답이나 후속 패킷을 차단할 수 있습니다.


3. 주요 특징

경로 추적 도구의 기본 동작 차이입니다.

도구기본 프로브참고 옵션
traceroute (Linux)UDP, 목적지 포트 33434부터 증가-I ICMP, -T -p 443 TCP SYN(root 필요), -n 이름 해석 생략
tracert (Windows)ICMP Echo-d 이름 해석 생략
tracepath (Linux)UDP, 경로 MTU도 함께 표시root 권한 불필요
mtrICMP (옵션으로 UDP·TCP)-r -c 10 보고서 모드, -n

방화벽이 UDP 고포트나 ICMP를 막는 환경에서는 실제 서비스 포트로 TCP 프로브(traceroute -T -p 443)를 보내야 방화벽 뒤 경로가 보이는 경우가 많습니다. 도구마다 막히는 결과가 다르다는 것 자체가 방화벽 정책의 단서입니다.

증상별로 의심할 원인입니다.

증상의심 원인확인 방법
특정 홉 이후 계속 * * *경로 끊김 또는 이후 구간이 프로브 차단TCP 프로브로 재시도, 해당 장비 테이블 조회
같은 두 홉이 번갈아 반복라우팅 루프두 장비의 해당 목적지 경로 비교
첫 홉이 예상 게이트웨이가 아님기본 경로·정적 경로 변경, 두 번째 NICip route get, 인터페이스 목록
traceroute는 성공, 서비스 접속은 실패경로가 아니라 정책(ACL·방화벽) 차단방화벽 차단 로그
SYN은 나가는데 응답이 없음복귀 경로 없음 또는 비대칭목적지 측에서 출발지로의 경로 조회

4. 예시

실습 예시 — 사용자망 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) 결과를 나란히 놓아, 방화벽 이후 구간이 한쪽에서만 * * *로 보이는 차이를 표시한 화면


5. 보안 관점

  • "방화벽 로그에 없다 = 통신이 없었다"가 아닙니다. 경로가 방화벽을 우회했을 수 있습니다. 경로 분석은 보안장비 가시성의 전제 조건을 검증하는 작업입니다.
  • 비대칭 라우팅은 장애 원인이면서 보안 공백입니다. 한쪽 방향만 통과하는 IDS는 세션 재조립이 어려워 탐지가 누락될 수 있습니다.
  • traceroute 결과는 내부 구조(홉 수, 장비 IP)를 드러냅니다. 경계 장비가 외부에서 오는 경로 추적 프로브에 응답하지 않도록 하는 경우가 많습니다.
  • 외부에서 내부로의 traceroute 시도 패턴은 정찰 행위로 분류될 수 있습니다(229. 외부망 정찰).

6. SOC 관점

흔적경로 분석에서의 의미
방화벽 세션 로그해당 통신이 방화벽을 통과했다는 증거
NetFlow / IPFIX어느 라우터 인터페이스로 들어오고 나갔는가
ICMP Time Exceeded(Type 11) 다량경로 추적 시도 또는 라우팅 루프
한 방향 세션만 기록된 방화벽 로그비대칭 라우팅 가능성

관제자가 확인할 질문

  • 이 통신이 지나야 할 보안장비 목록을 구성도로 먼저 정리했는가? 각 장비에 로그가 있는가?
  • 요청 방향과 응답 방향의 경로가 같은가?
  • 사건 시각의 경로가 지금과 같다고 볼 근거(설정 변경·인접 변경 로그 부재)가 있는가?

오탐 주의: 이중화·부하 분산 환경에서는 같은 목적지라도 홉이 번갈아 보일 수 있으며 루프가 아닙니다. 사건 분석에서는 현재 경로로 과거를 단정하지 말고, 사건 시각의 장비 로그로 확인합니다.


7. 핵심 정리

  • 경로 분석은 출발지 → 각 홉 → 목적지 → 복귀 경로 순으로 장비 테이블을 조회하고, traceroute·캡처·로그로 교차 확인합니다.
  • ip route get, show ip route <목적지>는 현재 선택 경로를, traceroute·mtr은 응답하는 홉 순서를 보여 줍니다.
  • 프로브 종류(UDP·ICMP·TCP)에 따라 결과가 달라지며, 그 차이가 방화벽 정책의 단서가 됩니다.
  • 비대칭 라우팅은 상태 기반 방화벽 차단과 IDS 탐지 누락의 원인이 됩니다.
  • 보안장비 로그가 증거가 되려면 먼저 그 장비가 경로 위에 있음을 확인해야 합니다.
profile
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

0개의 댓글