📚 네트워크 · 패킷 분석 › 01. TCP/IP 구조 이해 — 17편
이전 글: 16. Default Gateway · 다음 글: 18. Routing Table
이 글은 호스트 입장에서 본 라우팅 개념을 다룹니다. 라우터 장비 설정·정적 라우팅 구성은 04. 네트워크 장비 실습 시리즈에서 다룹니다.
1. 왜 알아야 하는가
3편에서 목적지가 다른 네트워크면 게이트웨이로 보낸다고 했습니다. 이번 글은 그 다음 질문입니다.
게이트웨이를 넘어간 패킷은 어떤 경로로 목적지까지 가는가?
보안관제에서 라우팅을 알아야 하는 이유는 다음과 같습니다.
- 패킷이 지나간 경로 위의 장비(방화벽, IDS, 프록시)만 그 트래픽의 로그를 남깁니다. 경로를 모르면 어디서 증거를 찾아야 할지 알 수 없습니다.
- 호스트의 기본 경로(default route)가 바뀌면 모든 외부 통신이 다른 장비를 거치게 됩니다. 중간자 공격이나 설정 변조의 흔적일 수 있습니다.
- 일반 서버에서 IP 포워딩이 켜져 있으면 그 서버가 라우터처럼 동작합니다. 침해된 서버를 내부망 접근 발판(pivot)으로 쓰는 경우 확인하는 항목입니다.
- 로그에 남는 TTL 값으로 대략적인 거리(hop 수)와 출발지 OS를 추정할 수 있습니다.
2. 핵심 개념
2-1. 용어 정리
| 용어 | 의미 |
|---|---|
| 게이트웨이(Gateway) | 내 네트워크 밖으로 나가는 출구 역할의 라우터 주소 |
| 기본 경로(Default Route) | 0.0.0.0/0 — 라우팅 테이블에 더 구체적인 경로가 없을 때 쓰는 경로 |
| 다음 홉(Next Hop) | 패킷을 넘겨줄 바로 다음 라우터 |
| 홉(Hop) | 라우터 하나를 지나는 것 |
| TTL(Time To Live) | IP 헤더의 값. 라우터를 지날 때마다 1씩 감소, 0이 되면 폐기 |
| 메트릭(Metric) | 같은 목적지로 가는 경로가 여러 개일 때 우선순위 |
2-2. 라우팅 테이블 읽는 법
default via 192.168.10.1 dev ens33 proto dhcp metric 100
192.168.10.0/24 dev ens33 proto kernel scope link src 192.168.10.20 metric 100| 줄 | 의미 |
|---|---|
default via 192.168.10.1 | 모르는 목적지는 전부 192.168.10.1(게이트웨이)로 보낸다 |
192.168.10.0/24 dev ens33 ... scope link | 이 대역은 직접 연결되어 있으므로 게이트웨이 없이 보낸다 (3편의 "같은 네트워크") |
proto dhcp / proto kernel / proto static | 이 경로가 어디서 생겼는가 (DHCP 할당 / 커널 자동 / 관리자 수동) |
위 출력은 형식 예시입니다. 실제 값은 환경마다 다릅니다.
2-3. 정적 라우팅 vs 동적 라우팅
| 구분 | 정적 라우팅 | 동적 라우팅 |
|---|---|---|
| 설정 | 관리자가 직접 입력 | 라우터끼리 경로 정보 교환 (OSPF, BGP 등) |
| 장점 | 단순, 예측 가능 | 장애 시 자동 우회 |
| 주로 쓰는 곳 | 호스트, 소규모 망 | 기업 내부망(OSPF), 인터넷 통신사 간(BGP) |
3. 동작 원리
3-1. 경로 선택 — Longest Prefix Match
라우팅 테이블에 목적지와 일치하는 경로가 여러 개 있으면 프리픽스가 가장 긴(가장 구체적인) 경로를 고릅니다.
목적지: 10.10.20.5
0.0.0.0/0 via 192.168.10.1 ← 일치 (/0)
10.10.0.0/16 via 192.168.10.254 ← 일치 (/16)
10.10.20.0/24 via 192.168.10.253 ← 일치 (/24) ★ 선택→ 기본 경로는 "아무것도 일치하지 않을 때"만 쓰입니다.
3-2. 라우터가 패킷 하나를 넘길 때 하는 일
① 자기 MAC으로 온 프레임 수신 → Ethernet 헤더 제거
② IP 헤더의 TTL 1 감소
→ TTL이 0이 되면 폐기 + 출발지에 ICMP Time Exceeded(Type 11) 전송
③ 목적지 IP로 라우팅 테이블 조회 (Longest Prefix Match)
→ 경로가 없으면 폐기 + ICMP Destination Unreachable(Type 3) 전송
④ 다음 홉의 MAC을 ARP로 확인
⑤ 새 Ethernet 헤더(출발지=라우터 MAC, 목적지=다음 홉 MAC)를 붙여 전송1편·2편과 연결되는 핵심
| 값 | 라우터를 지날 때 |
|---|---|
| 출발지·목적지 MAC | 매 홉마다 바뀜 |
| 출발지·목적지 IP | 그대로 (NAT 구간 제외) |
| TTL | 1씩 감소 |
3-3. traceroute가 경로를 알아내는 원리
TTL을 1, 2, 3… 으로 늘려 가며 패킷을 보냅니다. TTL이 0이 되는 지점의 라우터가 ICMP Time Exceeded를 돌려주므로, 응답한 라우터 주소를 순서대로 모으면 경로가 됩니다.
TTL=1 → 1번째 라우터에서 0 → 1번째 라우터가 Time Exceeded 응답
TTL=2 → 2번째 라우터에서 0 → 2번째 라우터가 Time Exceeded 응답
...
TTL=n → 목적지 도착 → 목적지가 응답Linux
traceroute는 기본적으로 UDP 패킷을, Windowstracert는 ICMP Echo를 사용합니다. 중간 라우터가 ICMP 응답을 막으면* * *로 표시됩니다.
4. 실제 명령어 / 실습
실습 환경: 본인 소유 Linux VM 1대 (Rocky Linux 또는 Ubuntu), 인터넷 연결. ens33은 예시 인터페이스 이름입니다.
4-1. 라우팅 테이블과 경로 선택 확인
# 라우팅 테이블 전체
ip route
# 특정 목적지로 갈 때 실제로 선택되는 경로
ip route get 8.8.8.8📷 [실습 화면 삽입]
ip route와ip route get 8.8.8.8결과
4-2. TTL을 일부러 1로 보내기 — 첫 번째 라우터의 응답 관찰
# 터미널 1 : ICMP Time Exceeded만 캡처
sudo tcpdump -i ens33 -nn 'icmp[icmptype] == icmp-timxceed'
# 터미널 2 : TTL=1로 ping (Linux ping의 -t 옵션 = TTL)
ping -c 1 -t 1 8.8.8.8기대 결과: ping에는 Time to live exceeded가 표시되고, 응답을 보낸 주소는 첫 번째 라우터(보통 게이트웨이)입니다.
4-3. 전체 경로 확인
# tracepath는 iputils에 포함되어 대부분 기본 설치되어 있음
tracepath -n 8.8.8.8
# traceroute가 설치되어 있다면
traceroute -n 8.8.8.8📷 [실습 화면 삽입] tracepath 또는 traceroute 결과 — 1번째 홉이 게이트웨이인지 표시
4-4. 이 호스트가 라우터처럼 동작하는지 확인
# 0 = 포워딩 꺼짐(일반 호스트), 1 = 포워딩 켜짐(라우터 역할)
sysctl net.ipv4.ip_forward4-5. 받은 TTL 값 비교
ping -c 1 <게이트웨이_IP>
ping -c 1 8.8.8.8
# 각 응답 줄의 ttl= 값을 비교5. 결과 확인
확인 체크리스트
-
ip route에default via <게이트웨이>줄이 하나 있는가? (여러 개면 metric 확인) -
ip route get 8.8.8.8결과의via주소가 기본 게이트웨이와 같은가? -
ping -t 1의 Time Exceeded 응답 주소가 tracepath 1번째 홉과 같은가? - tcpdump에서
ICMP time exceeded in-transit패킷이 보였는가? - 실습 VM의
ip_forward값을 기록했는가? (일반 VM이라면 0이 정상)
TTL 값 해석 (추정용 참고치)
| 받은 TTL | 추정 초기값 | 흔한 출발지 |
|---|---|---|
| 64 이하 | 64 | Linux, macOS |
| 65~128 | 128 | Windows |
| 129~255 | 255 | 네트워크 장비 |
예: 외부에서 받은 응답이
ttl=117이면 초기값 128에서 약 11홉 떨어진 Windows 계열일 가능성이 있습니다. 초기값은 설정으로 바꿀 수 있으므로 확정 근거가 아니라 참고 단서입니다.
6. 패킷 / 로그 분석 — 라우팅 관련 이상징후
| 관찰 내용 | 정상일 수 있는 경우 | 의심해야 하는 경우 |
|---|---|---|
| 기본 경로(default via)가 바뀜 | DHCP 갱신, 네트워크 변경 | 서버의 게이트웨이가 내부 일반 호스트 IP로 바뀜 |
일반 서버의 ip_forward = 1 | 컨테이너·VPN 호스트, 라우터 역할 서버 | 목적이 없는 서버에서 켜짐 → Pivot 발판 가능성 |
| 외부에서 ICMP Time Exceeded 다량 수신 유발 | 관리자의 경로 점검 | 외부 IP가 TTL을 바꿔 가며 반복 접근 → 네트워크 구조 파악(정찰) 가능성 |
| 같은 출발지인데 TTL이 크게 다름 | 경로 변경 | 같은 IP로 위조된 패킷이 섞였을 가능성 |
| 내부 호스트가 보낸 패킷인데 TTL이 비정상적으로 작음 | — | 중간에 예상하지 못한 장비를 거쳤을 가능성 |
6-1. 경로 변경을 실시간으로 관찰
# 라우팅 테이블 변경이 생기면 즉시 출력 (Ctrl+C로 종료)
ip monitor route기준값(Baseline)으로
ip route와sysctl net.ipv4.ip_forward결과를 저장해 두고, 점검 때 비교하는 방식이 가장 간단합니다.
7. 보안관제 관점
7-1. 경로 = 증거가 남는 위치
[사용자 PC] → [L2 스위치] → [게이트웨이/방화벽] → [IDS 미러링 지점] → [인터넷]
└ 방화벽 로그 └ IDS Alert- 같은 대역 안의 통신(3편의 "직접 전송")은 게이트웨이 방화벽을 지나지 않습니다. → 방화벽 로그에 안 남음. 내부 확산 분석에서 자주 놓치는 부분입니다.
- 경로 위 어디에서 패킷을 캡처하느냐에 따라 보이는 IP와 MAC이 달라집니다. (NAT 전/후, 홉 전/후)
7-2. 비대칭 라우팅
요청과 응답이 서로 다른 경로로 오가는 상황입니다. 상태 기반 방화벽(Stateful Firewall)은 한쪽 방향만 보게 되어 정상 응답을 차단하거나, IDS가 연결의 절반만 보게 됩니다. 탐지 누락의 원인이 될 수 있으므로 장비 배치를 설계할 때 확인해야 합니다. (06. 방화벽 · IDS/IPS 시리즈에서 다룸)
7-3. 점검 항목 요약
| 항목 | 명령 | 기준 |
|---|---|---|
| 기본 게이트웨이 | ip route show default | 승인된 게이트웨이 IP인가 |
| 게이트웨이 MAC | ip neigh | 2편의 기준값과 같은가 |
| IP 포워딩 | sysctl net.ipv4.ip_forward | 목적 없는 서버는 0 |
| 수동 추가 경로 | ip route show proto static | 변경 관리 기록과 일치하는가 |
8. 핵심 정리
- 게이트웨이는 내 네트워크의 출구이고, 기본 경로(0.0.0.0/0)는 다른 경로가 없을 때 쓰인다.
- 경로는 Longest Prefix Match로 가장 구체적인 것이 선택된다.
- 라우터를 지날 때 MAC은 바뀌고, IP는 유지되고, TTL은 1 감소한다.
- traceroute는 TTL 감소와 ICMP Time Exceeded를 이용해 경로를 알아낸다.
- 관제에서는 기본 경로·게이트웨이 MAC·ip_forward를 기준값과 비교하고, 경로 위 장비만 로그를 남긴다는 점을 기억한다.
다음 글: 사설 IP · 공인 IP와 NAT — 로그의 IP가 서로 다른 이유
