서버를 배포하고 서비스가 잘 올라왔는데 외부에서 전혀 접근이 안 될 때가 있습니다. 포트는 열려 있고, 방화벽 규칙도 문제없고, 프로세스도 정상인데 패킷이 서버까지 도달하지 못합니다. ip route를 보면 게이트웨이가 없거나 잘못된 네트워크 인터페이스로 경로가 잡혀 있는 경우가 많습니다. 라우터가 패킷을 어떻게 전달하는지 이해하지 못하면, 이런 네트워크 단절 상황에서 몇 시간을 낭비하게 됩니다.

라우터는 무엇을 하는가

**라우터(Router)**는 서로 다른 네트워크 사이에서 패킷을 전달하는 장비입니다. 호스트가 패킷을 보낼 때, 목적지 IP 주소가 자신과 같은 서브넷인지 아닌지를 먼저 판단합니다.

• 같은 서브넷: ARP로 목적지 MAC 주소를 찾아 직접 전송
• 다른 서브넷: 라우터(게이트웨이)에게 패킷을 위임

라우터는 여러 개의 네트워크 인터페이스를 가지고, 각 인터페이스가 서로 다른 네트워크에 연결됩니다. 패킷이 들어오면 **라우팅 테이블(Routing Table)**을 조회하여 어느 인터페이스로 내보낼지 결정합니다.

[서버 A: 192.168.1.10]
      |
   [스위치 - 192.168.1.0/24 네트워크]
      |
   [라우터 eth0: 192.168.1.1] ←── 게이트웨이 역할
   [라우터 eth1: 10.0.0.1   ] ←── 외부 네트워크 연결
      |
   [인터넷 / 다른 서브넷]

서버 A(192.168.1.10)가 8.8.8.8로 패킷을 보낼 때의 흐름:

1. 8.8.8.8은 192.168.1.0/24 서브넷이 아님을 판단
2. 게이트웨이 192.168.1.1(라우터 eth0)로 패킷 전송
3. 라우터가 자신의 라우팅 테이블을 보고 eth1로 패킷을 전달
4. 패킷이 인터넷으로 나감

라우팅 테이블 구조

리눅스에서 ip route 명령으로 라우팅 테이블을 확인합니다:

# 실습 디렉토리 준비
mkdir -p /tmp/networking/part1/exam_3 && cd /tmp/networking/part1/exam_3

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10 metric 100

각 필드의 의미:

라우팅 결정 우선순위

라우터는 가장 구체적인(Longest Prefix Match) 경로를 선택합니다:

목적지: 10.0.1.50

라우팅 테이블:
  10.0.0.0/8      via 192.168.1.2   ← 매칭
  10.0.1.0/24     via 192.168.1.3   ← 더 구체적 → 이 경로 선택
  default         via 192.168.1.1

/24가 /8보다 더 구체적이므로 10.0.1.0/24 경로가 선택됩니다.

클라우드 인스턴스를 재시작했더니 어제까지 되던 특정 외부 IP로의 통신이 갑자기 안 됩니다. ping은 되는데 특정 서브넷만 막힙니다. 원인은 재시작 후 임시로 추가한 정적 경로가 사라진 것이었습니다. 디폴트 게이트웨이와 정적 경로의 차이, 영구 설정 방법을 모르면 재부팅마다 경로 설정을 다시 해야 하는 상황이 반복됩니다.

디폴트 게이트웨이란

**디폴트 게이트웨이(Default Gateway)**는 라우팅 테이블에 일치하는 경로가 없을 때 패킷을 전달하는 마지막 수단입니다. ip route 출력에서 default via [IP]로 표시됩니다.

DHCP 환경에서는 자동으로 설정되지만, 정적 IP를 사용하는 서버라면 반드시 수동으로 설정해야 합니다. 디폴트 게이트웨이가 없으면 로컬 서브넷 외부와 통신이 불가능합니다.

# 디폴트 게이트웨이 확인
$ ip route show default
default via 10.0.0.1 dev eth0 proto static

# 디폴트 게이트웨이 임시 추가
$ ip route add default via 10.0.0.1 dev eth0

# 디폴트 게이트웨이 삭제
$ ip route del default via 10.0.0.1

정적 경로(Static Route) 추가

특정 서브넷으로 가는 패킷을 다른 게이트웨이로 보내야 할 때 정적 경로를 추가합니다. 대표적인 사례:

• 사내 전용 서브넷(172.16.0.0/12)은 사내망 라우터를 통해
• 인터넷 트래픽은 기본 게이트웨이를 통해

# 정적 경로 추가 (임시 — 재부팅 시 사라짐)
$ ip route add 172.16.0.0/16 via 10.0.0.254 dev eth0

# 경로 확인
$ ip route
default via 10.0.0.1 dev eth0
10.0.0.0/24 dev eth0 proto kernel scope link
172.16.0.0/16 via 10.0.0.254 dev eth0   ← 추가된 정적 경로

# 특정 목적지로의 경로 확인
$ ip route get 172.16.5.10
172.16.5.10 via 10.0.0.254 dev eth0 src 10.0.0.5

# 정적 경로 삭제
$ ip route del 172.16.0.0/16 via 10.0.0.254

영구 경로 설정 방법

Linux 배포판별 정적 라우팅 영구 적용 가이드 (Debian /etc/network/interfaces 등)

서버가 재부팅되면 터미널에 입력한 ip route add 정적 경로는 모두 초기화됩니다. 실무 SRE는 서버 재시작 후에도 설정이 유지되도록 다음과 같이 네트워크 설정 파일에 라우팅 경로를 명시해야 합니다.

1. Debian/Ubuntu 계열 (Legacy /etc/network/interfaces 환경): 설정 파일 맨 아래에 up route add 지시어를 추가하여 네트워크 인터페이스가 Up 상태가 될 때 커맨드가 자동 기동되도록 구성합니다.
   로컬 터미널

   auto eth0
   iface eth0 inet static
       address 192.168.1.10
       netmask 255.255.255.0
       # 인터페이스 활성화 시 정적 경로 자동 결합
       up ip route add 10.0.0.0/8 via 192.168.1.1 dev eth0
   

   복사
2. 현대적 Netplan 환경 (Ubuntu 18.04+): /etc/netplan/*.yaml 파일을 열어 routes 레이아웃에 직접 정적 게이트웨이를 선언합니다.

Linux 배포판별 정적 라우팅 영구 적용 가이드 (Debian /etc/network/interfaces 등)

서버가 재부팅되면 터미널에 입력한 ip route add 정적 경로는 모두 초기화됩니다. 실무 SRE는 서버 재시작 후에도 설정이 유지되도록 다음과 같이 네트워크 설정 파일에 라우팅 경로를 명시해야 합니다.

1. Debian/Ubuntu 계열 (Legacy /etc/network/interfaces 환경): 설정 파일 맨 아래에 up route add 지시어를 추가하여 네트워크 인터페이스가 Up 상태가 될 때 커맨드가 자동 기동되도록 구성합니다.
   로컬 터미널

   auto eth0
   iface eth0 inet static
       address 192.168.1.10
       netmask 255.255.255.0
       # 인터페이스 활성화 시 정적 경로 자동 결합
       up ip route add 10.0.0.0/8 via 192.168.1.1 dev eth0
   

   복사
2. 현대적 Netplan 환경 (Ubuntu 18.04+): /etc/netplan/*.yaml 파일을 열어 routes 레이아웃에 직접 정적 게이트웨이를 선언합니다.

Linux 배포판별 정적 라우팅 영구 적용 가이드 (Debian /etc/network/interfaces 등)

서버가 재부팅되면 터미널에 입력한 ip route add 정적 경로는 모두 초기화됩니다. 실무 SRE는 서버 재시작 후에도 설정이 유지되도록 다음과 같이 네트워크 설정 파일에 라우팅 경로를 명시해야 합니다.

1. Debian/Ubuntu 계열 (Legacy /etc/network/interfaces 환경): 설정 파일 맨 아래에 up route add 지시어를 추가하여 네트워크 인터페이스가 Up 상태가 될 때 커맨드가 자동 기동되도록 구성합니다.
   로컬 터미널

   auto eth0
   iface eth0 inet static
       address 192.168.1.10
       netmask 255.255.255.0
       # 인터페이스 활성화 시 정적 경로 자동 결합
       up ip route add 10.0.0.0/8 via 192.168.1.1 dev eth0
   

   복사
2. 현대적 Netplan 환경 (Ubuntu 18.04+): /etc/netplan/*.yaml 파일을 열어 routes 레이아웃에 직접 정적 게이트웨이를 선언합니다.

RHEL/CentOS (NetworkManager 방식)

# nmcli로 영구 경로 추가
$ nmcli connection modify eth0 +ipv4.routes "172.16.0.0/16 10.0.0.254"
$ nmcli connection up eth0

# 또는 파일 직접 편집
$ cat /etc/sysconfig/network-scripts/route-eth0
172.16.0.0/16 via 10.0.0.254 dev eth0

Ubuntu/Debian (Netplan 방식)

# /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    eth0:
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      routes:
        - to: 172.16.0.0/16
          via: 10.0.0.254

# Netplan 적용
$ netplan apply

NIC 2개 서버의 비대칭 라우팅 문제

서버에 NIC가 2개 있을 때(예: 서비스용 eth0 + 관리용 eth1) 단일 디폴트 게이트웨이만 설정하면 **비대칭 라우팅(Asymmetric Routing)**이 발생합니다.

[클라이언트]
    |
    → eth1(10.0.2.10)으로 패킷 수신
    ← 응답이 eth0(10.0.1.10)의 게이트웨이로 나감 ← 문제!

이 문제는 방화벽 상태 추적(stateful inspection)을 깨뜨려 연결 거부나 불안정한 통신을 유발합니다.

해결책: Policy-based Routing (정책 기반 라우팅) — 출처 IP별로 다른 라우팅 테이블을 적용합니다.

# eth1용 별도 라우팅 테이블 생성
$ echo "200 eth1-table" >> /etc/iproute2/rt_tables

# eth1 테이블에 게이트웨이 추가
$ ip route add default via 10.0.2.1 dev eth1 table eth1-table

# eth1로 들어온 패킷은 eth1-table 사용 규칙
$ ip rule add from 10.0.2.10 lookup eth1-table