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

확대

라우터는 무엇을 하는가

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

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

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

확대

서버 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 경로가 선택됩니다.

ping 8.8.8.8 한 줄, 혹은 애플리케이션이 소켓을 여는 순간. 커널은 목적지 IP 하나만 손에 쥐고 "이 패킷을 어느 인터페이스로, 누구에게 넘길지"를 매번 계산합니다. 이 계산이 라우팅 결정이고, 아래 6단계로 진행됩니다. 각 단계를 알면 "왜 이 대상만 안 되지", "왜 응답이 안 돌아오지"를 단계로 좁힐 수 있습니다.

[호스트]  목적지 8.8.8.8 로 패킷을 보내려 함
   │
   ① 목적지 IP 확인 → 라우팅 테이블(ip route) 조회 시작
   │
   ② longest prefix match 로 경로 선택
   │    10.0.1.0/24 vs 0.0.0.0/0 → 더 긴 prefix 가 이김
   │    맞는 경로 없으면 default(0.0.0.0/0) 로
   │
   ③ 선택된 경로가 '직접 연결'인가 '게이트웨이 경유'인가
   │    ├─ scope link (같은 서브넷) → 목적지 IP 의 MAC 을 직접 해석
   │    └─ via 게이트웨이         → 다음 홉(게이트웨이)으로 위임
   │
   ④ 넘길 대상의 MAC 을 ARP 로 해석
   │    (게이트웨이 경유면 '목적지'가 아니라 '게이트웨이의 MAC')
   │
   ⑤ L2 이더넷 프레임 생성 → dev 인터페이스로 송신
   │    출발지 MAC = 내 NIC / 목적지 MAC = 게이트웨이
   │
   ⑥ 다음 홉 라우터가 ①~⑤ 를 자기 테이블로 반복 (TTL -1)
   ▼
[목적지]  홉을 거쳐 도달 (TTL 0 이면 폐기 + ICMP → traceroute 가 이용)

각 단계에서 무슨 일이 일어나고, 어긋나면 어떤 증상인가:

즉 라우팅은 "목적지 IP 하나로 다음 홉을 고르는 계산"을 홉마다 반복하는 것입니다. 라우팅 테이블을 눈으로 읽어 추측하지 말고, ip route get <목적지IP>로 커널이 실제로 고른 경로·인터페이스·출발지 IP를 직접 물어보는 것이 진단의 출발점입니다 — 이 결과가 의도와 다르면 ②(경로 선택)를, 정상인데도 통신이 안 되면 ④ 이하(ARP·L2)나 그 위(방화벽)를 의심합니다.

클라우드 인스턴스를 재시작했더니 어제까지 되던 특정 외부 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 레이아웃에 직접 정적 게이트웨이를 선언합니다.

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

NIC가 2개인 서버에서 "요청은 tcpdump에 찍히는데 응답이 사라지고 로그조차 없다"는 유령 같은 증상의 정체는 대개 rp_filter입니다. 이 커널 검사의 동작을 알아야 정책 기반 라우팅이 왜 필요한지 납득됩니다.

• 무엇을 검사하나: rp_filter는 패킷이 들어온 인터페이스가, 그 출발지 IP로 되돌아가는 경로(FIB 역방향 조회)의 인터페이스와 일치하는지 커널이 검사하는 리버스 경로 검증입니다.
• strict vs loose: 1(strict)은 응답이 나갈 인터페이스와 들어온 인터페이스가 다르면(비대칭) 폐기합니다. 2(loose)는 어느 인터페이스로든 그 출발지로 나가는 경로만 있으면 통과시킵니다. 0은 검사하지 않습니다.
• 멀티홈에서 자연히 깨진다: 디폴트 게이트웨이가 하나뿐이면, eth1로 들어온 요청의 응답이 eth0 경로로 나가려다 eth1의 strict 검사에 걸려 사라집니다. 방화벽이 아니라 라우팅 스택이 버리는 것입니다.
• 조용함이 핵심: rp_filter 폐기는 기본적으로 로그를 남기지 않습니다. net.ipv4.conf.<if>.log_martians=1을 켜야 dmesg에 martian source 로그가 남고, nstat -az의 리버스 경로 폐기 카운터로 드러납니다.
• 근본책: 정책 기반 라우팅(ip rule + 별도 테이블)으로 들어온 NIC로 응답이 나가는 대칭 경로를 만듭니다. 임시로는 rp_filter를 2로 완화하되, all과 인터페이스별 값 중 큰 값이 적용되므로 둘 다 낮춰야 합니다.