관리 메뉴

피터의 개발이야기

[Network] 08. 다른 동네의 편지는 누구에게 맡겨야 할까? 본문

DevOps/Network

[Network] 08. 다른 동네의 편지는 누구에게 맡겨야 할까?

기록하는 백앤드개발자 2026. 7. 16. 20:08
반응형

TCP/IP를 우편 시스템으로 이해하기 — Part 2. 편지에 두 종류의 주소가 필요한 이유

ㅁ 들어가며

호스트는 Subnet Mask와 라우팅 테이블을 사용해 목적지가 같은 네트워크인지 판단한다.

같은 네트워크의 On-link 목적지라면 상대의 MAC 주소를 ARP로 찾고 직접 프레임을 보낼 수 있다.

하지만 목적지가 다른 네트워크에 있다면 이야기가 달라진다.

PC A
IP 192.168.10.10/24

목적지
IP 192.168.20.20

 

PC A는 192.168.20.20이 자신의 네트워크인 192.168.10.0/24 밖에 있다는 사실은 안다.

그러나 목적지까지 이어지는 모든 라우터와 링크를 알지는 못한다.

 

그렇다면 첫 프레임을 누구에게 맡겨야 할까?

우리가 다른 지역으로 편지를 보낼 때 전국의 모든 배달길을 직접 고르지 않는 것과 같다.

주소를 적은 편지를 동네 우체국에 맡기면 우체국이 다음 지역으로 전달한다.

 

네트워크에서 이 첫 번째 우체국 역할을 하는 장비가 Default Gateway다.

이번 글에서는 Default Route, Next Hop, ARP, IP Forwarding이 어떻게 연결되는지,

그리고 라우터를 지날 때 IP 패킷과 Ethernet Frame 중 무엇이 유지되고 무엇이 바뀌는지 살펴본다.


ㅁ 모든 목적지의 길을 호스트가 알아야 할까?

인터넷에는 수많은 네트워크가 있다.

PC가 각 네트워크로 가는 경로를 모두 저장해야 한다면 다음과 같은 지도가 필요하다.

192.168.20.0/24는 Router A로
172.16.0.0/16은 Router B로
10.20.30.0/24는 Router C로
그 밖의 수많은 네트워크는 ...

 

 

일반 호스트가 인터넷 전체의 경로를 알고 관리하는 것은 비효율적이다.

호스트가 꼭 알아야 하는 것은 더 단순하다.

  1. 직접 연결된 네트워크는 자신의 인터페이스로 보낸다.
  2. 나머지 목적지는 동네 밖 출구에 맡긴다.

이때 “더 구체적인 경로가 없는 모든 목적지”에 사용하는 경로가 Default Route다.

IPv4에서는 다음 Prefix로 표현한다.

0.0.0.0/0

Prefix Length가 0이라는 것은 어떤 목적지 주소와도 일치할 수 있다는 뜻이다.

Linux 라우팅 테이블에서는 다음과 같이 보일 수 있다.

default via 192.168.10.1 dev eth0

이를 풀어 쓰면 다음과 같다.

더 구체적인 경로가 없는 목적지는
eth0 인터페이스를 통해
다음 홉 192.168.10.1로 보내라.

여기서 192.168.10.1이 PC A의 Default Gateway다.


ㅁ Default Gateway와 Default Route는 같은 말일까?

두 용어는 밀접하지만 가리키는 대상이 다르다.

 

ㅇ Default Route는 경로 규칙이다

특정 목적지와 일치하는 더 구체적인 경로가 없을 때 사용할 라우팅 테이블의 항목이다.

Destination Prefix : 0.0.0.0/0
Next Hop           : 192.168.10.1
Output Interface   : eth0

 

ㅇ Default Gateway는 다음으로 넘겨받을 장비다

Default Route가 선택되었을 때 패킷을 전달받는 현재 링크의 라우터다.

Default Route   : 모르는 목적지에 적용할 규칙
Default Gateway : 그 규칙이 가리키는 다음 라우터

 

일상에서는 두 표현을 비슷하게 사용하지만 장애를 분석할 때는 구분하는 것이 좋다.

  • Default Route 자체가 없을 수 있다.
  • Route는 있지만 잘못된 Gateway를 가리킬 수 있다.
  • Gateway IP는 맞지만 ARP로 MAC 주소를 찾지 못할 수 있다.
  • Gateway까지는 전달되지만 라우터가 다음 경로를 모를 수 있다.

“게이트웨이 문제”라는 한 문장 안에도 서로 다른 실패 지점이 있다.


ㅁ 게이트웨이는 어디에 있어야 할까?

PC A가 Default Gateway 192.168.10.1에게 Ethernet Frame을 보내려면

게이트웨이의 MAC 주소를 알아야 한다.

ARP는 같은 Broadcast Domain 안에서만 동작한다.

 

따라서 일반적인 구성에서 Default Gateway의 IP 주소는

호스트가 직접 도달할 수 있는 On-link Network에 있어야 한다.

PC A       : 192.168.10.10/24
Gateway    : 192.168.10.1/24
같은 Subnet: 192.168.10.0/24

 

PC A는 다음 ARP Request를 보낼 수 있다.

Who has 192.168.10.1?
Tell 192.168.10.10

 

게이트웨이가 다음처럼 응답한다고 하자.

192.168.10.1 is at 11:11:11:11:11:01

 

이제 PC A는 원격 목적지로 가는 첫 프레임을 만들 수 있다.

Default Gateway가 꼭 .1 주소일 필요는 없다.

.254나 다른 사용 가능한 주소도 될 수 있다.

중요한 것은 관습적인 숫자가 아니라 호스트의 라우팅 설정이 가리키는 On-link 라우터라는 점이다.

가정이나 사무실에서는 DHCP의 Router Option을 통해 Default Gateway 주소를 자동으로 받는 경우가 많다.

정적으로 설정할 수도 있다.


ㅁ 최종 목적지는 서버인데 왜 프레임은 게이트웨이에게 보낼까?

PC A가 PC B로 보내는 패킷을 살펴보자.

PC A
IP  : 192.168.10.10/24
MAC : AA:AA:AA:AA:AA:AA

Router R1 - 왼쪽 인터페이스
IP  : 192.168.10.1/24
MAC : 11:11:11:11:11:01

Router R1 - 오른쪽 인터페이스
IP  : 192.168.20.1/24
MAC : 11:11:11:11:11:02

PC B
IP  : 192.168.20.20/24
MAC : BB:BB:BB:BB:BB:BB

 

전체 구조는 다음과 같다.

PC A ── 192.168.10.0/24 ── R1 ── 192.168.20.0/24 ── PC B

 

PC A가 만드는 IP Packet의 목적지는 처음부터 PC B다.

IP Header
├─ Source IP      : 192.168.10.10
└─ Destination IP : 192.168.20.20

 

그러나 현재 Ethernet Link에서 직접 프레임을 받을 장비는 R1이다.

Ethernet Header
├─ Source MAC      : AA:AA:AA:AA:AA:AA
└─ Destination MAC : 11:11:11:11:11:01

 

두 목적지는 서로 다르다.

IP Destination       : 전체 여정의 최종 목적지 PC B
Ethernet Destination : 현재 링크의 다음 홉 R1

우편 봉투에는 최종 수신인의 주소를 적지만, 현재 배달 단계에서는 동네 우체국이 편지를 먼저 넘겨받는 것과 같다.


ㅁ 라우터는 받은 프레임을 그대로 넘길까?

PC A가 보낸 Ethernet Frame은 R1의 왼쪽 인터페이스에 도착한다.

R1은 목적지 MAC 주소가 자신의 인터페이스 주소이므로 프레임을 받아들인다.

그 뒤 다음 순서로 처리한다.

 

ㅇ 1단계: Ethernet Header를 벗긴다

현재 링크에서 사용한 Ethernet Header와 Trailer를 처리하고 안쪽의 IP Packet을 확인한다.

[Ethernet Header][IP Packet][Ethernet Trailer]
        ↓ 제거          ↓
                  [IP Packet]

 

ㅇ 2단계: Destination IP를 확인한다

Destination IP 192.168.20.20은 라우터 자신의 주소가 아니다.

R1은 이 패킷을 다른 인터페이스로 전달해야 하는지 판단한다.

 

ㅇ 3단계: TTL을 1 줄인다

라우터는 IPv4 Header의 TTL 값을 1 감소시킨다. TTL이 0이 되면 패킷을 폐기한다.

TTL이 변경되므로 IPv4 Header Checksum도 다시 계산해야 한다.

 

ㅇ 4단계: 라우팅 테이블을 조회한다

R1은 Destination IP와 일치하는 경로를 찾는다.

192.168.20.0/24 dev eth1

목적지가 오른쪽 인터페이스에 직접 연결되어 있음을 알 수 있다.

 

ㅇ 5단계: 다음 L2 수신인의 MAC을 찾는다

PC B의 MAC 주소가 Neighbor Table에 없다면 R1은 오른쪽 네트워크에서 192.168.20.20을 ARP로 찾는다.

192.168.20.20 → BB:BB:BB:BB:BB:BB

 

ㅇ 6단계: 새 Ethernet Frame을 만든다

R1은 같은 IP Packet을 오른쪽 링크에 맞는 새 Ethernet Frame에 넣는다.

Ethernet Header
├─ Source MAC      : 11:11:11:11:11:02
└─ Destination MAC : BB:BB:BB:BB:BB:BB

IP Header
├─ Source IP      : 192.168.10.10
└─ Destination IP : 192.168.20.20

새 프레임의 FCS도 해당 링크에서 전송할 내용에 맞게 만들어진다.

라우터는 PC A의 Ethernet Frame을 그대로 연장하지 않는다.

IP Packet을 꺼내 다음 경로를 판단한 뒤, 새 링크의 Source MAC과 Destination MAC으로 다시 캡슐화한다.


ㅁ 주소는 여정에서 어떻게 바뀔까?

PC A에서 R1을 거쳐 PC B까지의 주소를 표로 비교해 보자.

구간 Source MAC Destination MAC Source IP Destination IP
PC A → R1 PC A MAC R1 왼쪽 MAC PC A IP PC B IP
R1 → PC B R1 오른쪽 MAC PC B MAC PC A IP PC B IP

 

MAC 주소는 링크마다 바뀐다.

IP 주소는 일반적인 라우팅 과정에서 최종 목적지까지 유지된다.

다만 TTL과 IPv4 Header Checksum 같은 헤더 값은 라우터를 지날 때 바뀐다.

MAC Address : Hop-by-Hop
IP Address  : End-to-End 목적지 표현

 

이 차이를 이해하면 “원격 서버의 MAC 주소를 왜 내 PC에서 볼 수 없는가?”라는 질문에도 답할 수 있다.

내 PC가 알아야 하는 것은 원격 서버의 MAC 주소가 아니라 현재 링크에서 첫 프레임을 받을 Default Gateway의 MAC 주소다.


ㅁ 라우터는 왜 패킷을 전달할 수 있을까?

IP 주소를 가진 모든 장비가 자동으로 라우터가 되는 것은 아니다.

라우터 역할을 하려면 보통 다음 조건이 필요하다.

  1. 둘 이상의 네트워크에 연결된 인터페이스가 있다.
  2. 목적지에 맞는 라우팅 정보가 있다.
  3. 인터페이스 사이의 IP Forwarding이 활성화되어 있다.
  4. 방화벽과 정책이 해당 전달을 허용한다.

일반 호스트는 자신의 IP를 목적지로 하는 패킷을 처리하지만 다른 호스트의 패킷을 인터페이스 사이로 넘기지 않는 것이 기본인 경우가 많다.

Linux에서는 IPv4 Forwarding 상태를 다음과 같이 읽을 수 있다.

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0  → IPv4 Forwarding 비활성
net.ipv4.ip_forward = 1  → IPv4 Forwarding 활성

Forwarding이 활성화되어 있어도 경로나 방화벽 정책이 올바르지 않으면 패킷은 전달되지 않는다.

Default Gateway는 단순히 IP 주소가 하나 더 설정된 장비가 아니라, 다른 네트워크로 패킷을 전달할 준비가 된 라우터여야 한다.


ㅁ 기본 경로가 없으면 어떤 일이 생길까?

PC A의 라우팅 테이블에 직접 연결된 경로만 있다고 하자.

192.168.10.0/24 dev eth0

 

목적지 192.168.20.20은 이 경로에 포함되지 않는다.

Default Route도 없다면 운영체제는 패킷을 어느 인터페이스와 Next Hop으로 보낼지 결정할 수 없다.

애플리케이션에서는 다음과 같은 즉시 오류를 볼 수 있다.

Network is unreachable

이 오류는 패킷이 먼 네트워크에서 사라졌다는 뜻이 아니다.

로컬 호스트가 보낼 경로를 찾지 못해 출발조차 하지 못했을 가능성을 나타낸다.

 

 

반면 Default Route는 있지만 Gateway의 MAC 주소를 ARP로 찾지 못하는 경우에는

ARP 재시도 뒤 지연되거나 Host Unreachable 계열 오류가 나타날 수 있다.

 

Default Route 없음
→ 경로 선택 실패
→ 출발 전 즉시 오류 가능

Default Route 있음, Gateway ARP 실패
→ 링크에서 이웃 탐색 재시도
→ 지연 후 실패 가능

겉으로는 모두 “인터넷이 안 된다”지만 실패한 단계는 다르다.


ㅁ Default Route가 여러 개일 수도 있을까?

노트북에 유선과 무선이 함께 연결되거나 라우터에 여러 인터넷 회선이 있으면 Default Route가 여러 개 존재할 수 있다.

default via 192.168.10.1 dev eth0 metric 100
default via 192.168.30.1 dev wlan0 metric 600

같은 목적지 Prefix에 여러 경로가 있을 때 운영체제는 Metric과 정책 같은 정보를 사용해 경로를 선택할 수 있다.

Metric이 낮은 경로를 더 선호하는 구성이 흔하지만 정확한 선택 규칙은 운영체제, 라우팅 프로토콜, 정책 라우팅 구성에 따라 달라질 수 있다.

Default Route는 반드시 하나뿐이라는 규칙이 아니다.

또한 Default Route보다 더 구체적인 목적지 경로가 있으면 구체적인 경로가 우선한다.

10.20.0.0/16 via 192.168.10.2
default       via 192.168.10.1

목적지 10.20.30.40/16 경로를 사용하고, 일치하는 구체적 경로가 없는 다른 목적지는 Default Route를 사용한다.

왜 구체적인 경로가 먼저 선택되는지는 다음 글의 Longest Prefix Match에서 자세히 살펴본다.


ㅁ 편지가 도착하면 통신이 끝난 것일까?

PC A의 패킷이 R1을 거쳐 PC B에 도착했다.

그러나 통신이 완성되려면 PC B의 응답도 PC A로 돌아와야 한다.

PC B 역시 192.168.10.10이 자신의 네트워크 밖에 있다는 것을 판단하고 자신의 Default Gateway인 192.168.20.1로 답장을 보낸다.

이 예제에서는 같은 R1이 양쪽 네트워크에 직접 연결되어 있으므로 돌아오는 경로도 알고 있다.

실제 네트워크에서는 요청 경로와 응답 경로가 서로 별개의 라우팅 결정이다. 가는 길이 존재한다고 돌아오는 길이 자동으로 보장되는 것은 아니다.

이 문제는 Part 3의 「가는 길이 있으면 돌아오는 길도 있는 것일까?」에서 더 자세히 다룬다.


ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습 네트워크 용어 의미
동네 밖 편지를 맡기는 우체국 Default Gateway 구체적인 경로가 없는 원격 패킷을 처음 전달받는 라우터
모르는 모든 지역에 적용할 규칙 Default Route IPv4에서는 0.0.0.0/0으로 표현하는 기본 경로
편지를 다음으로 넘겨받는 우체국 Next Hop 현재 장비가 패킷을 전달할 다음 라우터 또는 이웃
우체국까지의 현재 배달 봉투 Ethernet Frame 한 링크 안에서 다음 L2 수신인에게 전달하는 단위
봉투 안의 최종 주소가 적힌 편지 IP Packet 여러 네트워크를 지나 최종 목적지를 나타내는 단위
편지를 꺼내 새 봉투에 넣음 Re-encapsulation 라우터가 다음 링크의 L2 헤더로 패킷을 다시 감싸는 과정
다른 지역으로 편지를 넘김 IP Forwarding 수신한 IP 패킷을 다른 인터페이스로 전달하는 기능
지금 구간의 배달 주소 Hop-by-Hop MAC Address 링크마다 바뀌는 Source와 Destination MAC 주소

 

 

호스트에서 라우터를 거쳐 목적지까지의 흐름은 다음과 같다.

1. Destination IP에 대해 Routing Table을 조회한다.
2. Default Route가 선택되면 Next Hop인 Gateway를 확인한다.
3. Gateway MAC을 Neighbor Table에서 찾거나 ARP로 조회한다.
4. IP Packet을 Gateway MAC 목적지의 Ethernet Frame에 넣어 보낸다.
5. Router는 L2 Header를 벗기고 TTL을 줄인 뒤 경로를 조회한다.
6. 다음 링크의 MAC 주소로 새 Frame을 만들어 전달한다.

ㅁ 직접 확인해 보기

Linux에서 현재 라우팅 테이블을 확인한다.

ip -4 route show

 

다음과 같은 항목을 찾는다.

default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0 scope link src 192.168.10.10

 

특정 원격 목적지에 선택되는 Gateway, Interface, Source IP를 확인한다.

ip route get 8.8.8.8

 

예상 결과의 핵심은 다음과 같다.

8.8.8.8 via 192.168.10.1 dev eth0 src 192.168.10.10

 

게이트웨이의 MAC 주소가 이웃 테이블에 있는지도 살펴본다.

ip neigh show 192.168.10.1

 

첫 홉을 숫자 주소로 확인하려면 다음 명령을 사용할 수 있다.

traceroute -n 8.8.8.8

 

환경에 따라 traceroute가 설치되어 있지 않거나 방화벽과 ICMP 정책 때문에 일부 홉이 응답하지 않을 수 있다.

첫 홉이 항상 화면에 보인다고 보장할 수는 없다.

macOS에서는 다음 명령으로 기본 경로와 목적지 경로를 확인할 수 있다.

route -n get default
route -n get 8.8.8.8

운영 중인 환경에서 Default Route를 삭제하거나 Gateway를 변경하면

현재 연결이 즉시 끊어질 수 있으므로 읽기 명령으로 상태만 관찰한다.


ㅁ 핵심 정리

  • 호스트는 모든 인터넷 경로를 저장하지 않고 구체적 경로가 없는 목적지를 Default Route로 보낸다.
  • IPv4 Default Route는 0.0.0.0/0으로 표현한다.
  • Default Gateway는 Default Route가 가리키는 현재 링크의 Next Hop 라우터다.
  • 일반적으로 Gateway는 호스트가 ARP로 MAC 주소를 찾을 수 있는 On-link Network에 있어야 한다.
  • 원격 통신에서 IP Destination은 최종 서버지만 첫 Ethernet Destination은 Gateway MAC이다.
  • 라우터는 L2 Header를 벗기고 TTL을 줄인 뒤 경로를 조회해 다음 링크의 새 Frame으로 Re-encapsulation한다.
  • MAC 주소는 링크마다 바뀌고 IP Source와 Destination은 일반적인 라우팅 중 유지된다.
  • IP 주소가 여러 개 있다고 자동으로 라우터가 되는 것은 아니며 IP Forwarding, 경로, 정책이 필요하다.
  • Default Route가 없을 때와 Gateway ARP가 실패할 때는 장애가 발생하는 단계가 다르다.

핵심 용어: Default Gateway, Default Route, 0.0.0.0/0, Next Hop, Routing Table, ARP, IP Forwarding, Re-encapsulation, Hop-by-Hop, TTL, IPv4 Header Checksum, Metric

Default Gateway는 최종 목적지를 대신하는 주소가 아니다.
호스트가 모르는 먼 길을 처음 맡아 줄 수 있는 같은 동네의 라우터다.


ㅁ 다음 이야기

호스트는 자신이 모르는 목적지를 Default Gateway에 맡겼다.

이제 라우터는 Routing Table에서 패킷을 보낼 다음 길을 선택해야 한다.

그런데 하나의 Destination IP가 여러 경로 Prefix와 동시에 일치하면 어느 길을 선택해야 할까?

다음 글에서는 「라우터는 수많은 목적지의 길을 어떻게 고를까?」라는 질문을 통해 Routing Table, Route Entry, Longest Prefix Match, Administrative Distance와 Metric의 역할을 구분해 본다.

반응형
Comments