📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 174편
이전 글: 173. Default Route · 다음 글: 175. Routing 경로 분석
1. 개념
Next Hop은 라우팅 경로에 적힌 "이 패킷을 다음에 넘겨줄 장비의 IP 주소"입니다. 라우팅 테이블 항목으로서의 의미는 18. Routing Table에서 다뤘고, 이 글은 next hop 주소가 실제 전송으로 이어지기까지 장비가 하는 일과, 그 과정이 패킷과 로그에 어떻게 드러나는지를 봅니다.
중요한 사실 하나가 있습니다. 패킷 안에는 next hop IP가 어디에도 적히지 않습니다. IP 헤더의 목적지는 끝까지 최종 목적지이고, next hop은 L2 목적지 MAC으로만 드러납니다.
| 항목 | 패킷에 기록되는 값 |
|---|---|
| IP 목적지 | 최종 목적지 (예: 10.20.0.15) — 구간마다 동일 |
| Ethernet 목적지 MAC | 이번 구간의 next hop MAC — 구간마다 바뀜 |
| Ethernet 출발지 MAC | 이번 구간에서 패킷을 보낸 장비의 MAC |
| TTL | 라우터를 지날 때마다 1 감소 |
2. 동작 원리
R1이 목적지 10.20.0.15 패킷을 받았을 때의 처리 과정입니다.
목적지 10.20.0.15 → 테이블 조회
↓
S 10.20.0.0/24 via 10.0.12.2 ← next hop IP 확보
↓
10.0.12.2 는 어디로? (재귀 조회)
C 10.0.12.0/30 is directly connected, Gi0/2 ← 출구 인터페이스 확정
↓
Gi0/2에서 10.0.12.2 의 MAC은? → ARP 캐시 조회, 없으면 ARP Request
↓
Ethernet 헤더 작성: dst MAC = R2 Gi0/2 MAC, src MAC = R1 Gi0/2 MAC
↓
TTL 1 감소 → Gi0/2 로 송신재귀 조회는 여러 단계일 수도 있습니다. BGP 경로처럼 next hop이 멀리 있는 주소면, 그 주소로 가는 경로를 다시 찾아 직접 연결된 next hop에 도달할 때까지 반복합니다. 끝내 직접 연결 경로에 닿지 못하면 그 경로는 사용되지 않습니다. CEF 같은 FIB는 이 계산 결과와 L2 정보(ARP)를 미리 묶어 두어 패킷마다 반복하지 않습니다.
3. 주요 특징
- next hop은 직접 연결된 서브넷 안에 있어야 최종적으로 전달이 가능합니다. Linux에서는 직접 연결되지 않은 주소를 next hop으로 넣으면 기본적으로 거부되며,
onlink옵션으로 강제할 수 있습니다. - ARP가 실패하면 경로는 있어도 전달되지 않습니다. 라우터의 ARP 캐시에 next hop 항목이
Incomplete로 남아 있으면 상대 장비 장애나 VLAN 설정 오류를 의심합니다. - ICMP Redirect(Type 5): 라우터가 받은 패킷을 받은 인터페이스로 다시 내보내야 하는 경우, 출발지 호스트에게 "같은 서브넷에 더 나은 next hop이 있다"고 알려 줍니다.
| 설정 항목 | Cisco IOS | Linux |
|---|---|---|
| Redirect 보내기 끄기 | 인터페이스에서 no ip redirects | net.ipv4.conf.all.send_redirects = 0 |
| Redirect 받아들이기 끄기 | (라우터는 일반적으로 무시) | net.ipv4.conf.all.accept_redirects = 0 |
| next hop ARP 확인 | show ip arp 10.0.12.2 | ip neigh show 10.0.12.2 |
| next hop별 전달 정보 | show ip cef 10.20.0.15 detail | ip route get 10.20.0.15 |
Linux에서는 인터페이스별 값(net.ipv4.conf.<인터페이스>.*)도 함께 적용되므로 all과 인터페이스 값을 모두 확인합니다.
4. 예시
실습 예시 — Linux 라우터 VM과 클라이언트 VM에서 next hop 해석 과정을 확인합니다(Rocky/Ubuntu 공통). 출력은 형식 예시(값은 환경마다 다름)입니다.
# 클라이언트: 이 목적지의 next hop과 출구
ip route get 10.20.0.15
# 10.20.0.15 via 192.168.10.1 dev ens160 src 192.168.10.20 uid 1000
# 클라이언트: next hop(게이트웨이)의 MAC
ip neigh show 192.168.10.1
# 192.168.10.1 dev ens160 lladdr 00:0c:29:aa:10:01 REACHABLE
# 라우터: 전달할 때 쓰는 next hop 과 그 MAC
ip route get 10.20.0.15
ip neigh show dev ens38
# 라우터: 양쪽 구간 캡처 — MAC과 TTL 비교
sudo tcpdump -e -nn -v -i ens37 host 10.20.0.15
sudo tcpdump -e -nn -v -i ens38 host 10.20.0.15실습 예시 — Cisco IOS 계열에서의 확인입니다(출력은 형식 예시).
R1# show ip cef 10.20.0.15 detail
10.20.0.0/24, epoch 0
recursive via 10.0.12.2
attached to GigabitEthernet0/2
R1# show ip arp 10.0.12.2
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.12.2 3 0c4e.2b11.0002 ARPA GigabitEthernet0/2Wireshark에서는 같은 요청이라도 캡처 위치에 따라 eth.dst가 달라지고 ip.dst는 같다는 점을 확인할 수 있습니다. 게이트웨이 앞에서 캡처한 패킷의 목적지 MAC이 게이트웨이 MAC과 다르다면 경로 설정이나 ARP 상태를 의심합니다.
📷 [실습 화면 삽입 위치] 라우터 VM 양쪽 인터페이스의 tcpdump 결과에서 동일 패킷의 목적지 MAC(구간별 next hop)과 TTL이 바뀌고 목적지 IP는 그대로인 부분을 표시한 화면
5. 보안 관점
- next hop의 IP와 MAC 대응이 곧 신뢰의 근거입니다. ARP 스푸핑은 next hop(게이트웨이) IP의 MAC을 공격자 MAC으로 바꿔, 경로를 건드리지 않고도 트래픽을 가로챕니다. 원리와 탐지는 33. ARP Cache 등에서 다룹니다.
- ICMP Redirect 수용은 호스트의 next hop을 외부 메시지로 바꿀 수 있게 합니다. 서버·라우터에서는 받아들이기와 보내기를 모두 끄는 것이 일반적인 보안 기준입니다.
- 정적 경로의 next hop이 보안장비를 거치지 않는 장비를 가리키면 정책 우회 통로가 됩니다(172. Static Routing).
- 게이트웨이 MAC을 고정하거나, 스위치의 DHCP Snooping·Dynamic ARP Inspection으로 next hop 위조를 막을 수 있습니다.
6. SOC 관점
| 흔적 | 의미 |
|---|---|
| 게이트웨이 IP의 MAC 변경(ARP 감시 도구·EDR) | 장비 교체 또는 ARP 스푸핑 |
| ICMP Type 5 패킷 | 경로 설계상 비효율, 또는 비정상 Redirect |
%IP-4-DUPADDR 등 중복 주소 로그 (Cisco 계열 예) | 같은 IP를 다른 MAC이 사용 |
| 라우터 ARP 캐시의 Incomplete 항목 | next hop 무응답, 장애 가능성 |
관제자가 확인할 질문
- 캡처에서 게이트웨이로 가는 패킷의 목적지 MAC이 자산 대장의 게이트웨이 MAC과 일치하는가?
- 같은 next hop IP에 대해 짧은 시간에 MAC이 바뀐 기록이 있는가?
- ICMP Redirect를 보낸 출발지가 실제 라우터인가?
오탐 주의: HSRP·VRRP 같은 게이트웨이 이중화는 가상 MAC을 쓰며, 장애 전환 시 활성 장비가 바뀌어도 가상 MAC은 유지되는 것이 정상입니다. 다만 전환 순간 Gratuitous ARP가 발생하고 스위치에서 가상 MAC이 다른 포트로 이동하므로, 이중화 구성과 전환 로그를 먼저 확인합니다.
7. 핵심 정리
- Next hop은 라우팅 경로가 지정한 다음 장비의 IP이며, 패킷에는 IP가 아니라 목적지 MAC으로만 드러납니다.
- 장비는 재귀 조회로 출구 인터페이스를 정하고, ARP로 next hop MAC을 찾아 Ethernet 헤더를 새로 씁니다.
- next hop은 직접 연결 서브넷 안에 있어야 하고, ARP가 실패하면 경로가 있어도 전달되지 않습니다.
- ICMP Redirect는 next hop을 외부 메시지로 바꾸므로 서버·라우터에서는 보통 비활성화합니다.
- 관제에서는 게이트웨이 IP↔MAC 대응 변화와 Redirect 패킷이 next hop 조작의 단서가 됩니다.
