라우팅 테이블

"이 목적지 대역으로 갈 거면 저기로 넘겨라"를 적어 둔 표.

0.0.0.0/0은 프리픽스 길이가 0이라 모든 주소에 매칭되므로 기본 경로가 된다.

최장 프리픽스 매칭

목적지 10.1.5.7 에 대해
  0.0.0.0/0     매칭 (프리픽스 0)
  10.0.0.0/8    매칭 (8)
  10.1.0.0/16   매칭 (16)
  10.1.5.0/24   매칭 (24)  ← 가장 구체적 → 이것이 선택된다

"전국행" 보다 "그 도시행" 표지판이 우선하는 것과 같다

지켜야 할 두 가지

• ① 넥스트 홉은 그 라우터가 직접 닿을 수 있어야 한다

  • 자기 인터페이스 중 하나와 같은 서브넷에 있어야 한다
  • 두 홉 건너 주소를 적으면 동작하지 않는다

• ② 경로는 양방향으로 있어야 한다

  • 요청이 가는 길만 있고 응답이 오는 길이 없으면 통신이 성립하지 않는다

        [A 10.1.0.10]        [B 10.2.0.10]
             │                     │
        ┌────┴────┐           ┌────┴────┐
        │ R1      ├───────────┤ R2      │
        │10.1.0.1 │ 10.0.0.1  │10.2.0.1 │
        └─────────┘ 10.0.0.2  └─────────┘

R1 : 10.2.0.0/24 → 10.0.0.2
R2 : 10.1.0.0/24 → 10.0.0.1     ← 빠뜨리면 응답이 못 온다

"요청은 도달했는데 응답이 없다"는 복귀 경로 누락의 전형적 증상이다.

면접 함정

• ❌ "기본 경로만 있으면 된다" → 내부 대역은 구체적 경로가 필요하다.
• ❌ 단방향 경로만 설정 → 통신은 양방향이다.

실제 출력 읽기

$ ip route
default via 192.168.1.1 dev eth0            # 0.0.0.0/0
10.0.0.0/8 via 192.168.1.254 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

• via 가 있으면 — 다른 라우터를 거친다 (넥스트 홉)
• via 가 없으면 — 직접 연결된 네트워크 (scope link)
  • — 인터페이스에 IP 를 설정하면 자동으로 생긴다

경로가 생기는 세 가지 경로

• 직접 연결 — 인터페이스 설정 시 자동 (connected)
• 정적 — 관리자가 직접 등록 (static)
• 동적 — 라우팅 프로토콜이 학습 (OSPF·BGP)

같은 목적지에 여러 출처가 있으면 프리픽스 길이 → 관리 거리(administrative distance) → 메트릭 순으로 고른다

비대칭 경로 문제

• 가는 길과 오는 길이 다르면

  • 상태 추적 방화벽이 응답을 모르는 연결로 보고 버린다
  • NAT 가 매핑을 못 찾는다

• 경로를 양방향으로 대칭이 되게 설계하는 것이 원칙이다

진단

ip route get 10.1.5.7     # 이 목적지에 어느 경로가 쓰이는지 바로 보여 준다
traceroute 10.1.5.7       # 실제로 어느 홉을 거치는지

ip route get은 최장 프리픽스 매칭 결과를 그대로 알려 주므로 경로 문제 진단의 첫 명령으로 좋다.