새벽 배포 후 서버가 내부망은 보이는데 인터넷으로는 나가지 못합니다. IP 주소는 정상이고 NIC도 살아 있지만 디폴트 게이트웨이가 사라져 모든 외부 패킷이 길을 잃었습니다.
라우팅 테이블에서 default 한 줄을 읽을 수 있으면 복구 시간이 크게 줄어듭니다.
디폴트 라우팅과 게이트웨이 점검
서버가 갑자기 인터넷에 연결되지 않을 때, 원인 중 하나는 디폴트 게이트웨이가 사라진 것입니다. 이 장에서는 라우팅 테이블을 읽는 법, 게이트웨이가 날아가는 이유, 그리고 수동 복구와 영구 설정 방법을 다룹니다.
- 1라우팅 테이블 구조와 ip route show 출력 해석
- 2디폴트 게이트웨이의 역할과 소실 원인
- 3ip route 명령어로 게이트웨이 수동 복구
- 4nmcli(CentOS/RHEL)와 netplan(Ubuntu)으로 영구 설정
- 5재부팅 후 게이트웨이 소실 장애 대응 절차
ip route showip route show default | awk '{print $3}'ping -c 3 $(ip route show default | awk '{print $3}')systemctl status NetworkManager라우팅 테이블과 디폴트 라우트
새 서버를 배포했는데 외부로 나가는 요청이 전부 실패합니다. curl https://example.com도, apt update도 안 됩니다. ip route를 보면 로컬 서브넷 경로는 있는데 디폴트 라우트가 없습니다. 라우팅 테이블이 어떻게 경로를 선택하는지 모르면 이 상황에서 어디서 무엇을 설정해야 하는지 알 수 없습니다.
패킷은 어디로 가야 하는가
리눅스 커널은 패킷을 전송하기 전에 **라우팅 테이블(routing table)**을 조회합니다. 목적지 IP와 가장 구체적으로 일치하는 경로를 찾아 해당 인터페이스와 게이트웨이로 패킷을 보냅니다.
목적지 패킷 → 라우팅 테이블 조회 → 일치하는 경로?
├── 있음: 해당 경로의 게이트웨이/인터페이스로 전달
└── 없음: 디폴트 라우트(default route)로 전달
└── 디폴트도 없음: "Network unreachable" 오류
ip route show 출력 해석
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part2/exam_9 && cd /tmp/networking/part2/exam_9
$ ip route show
default via 192.168.1.1 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50
10.0.0.0/8 via 10.0.0.1 dev eth1 proto static
- default 라우트—0.0.0.0/0에 해당하는 기본 경로가 존재하는지 확인합니다
- via 주소—게이트웨이 IP가 같은 L2 대역의 실제 라우터인지 봅니다
- dev 인터페이스—패킷이 나갈 NIC가 기대한 인터페이스인지 확인합니다
각 항목의 의미:
| 필드 | 예시 | 의미 |
|---|---|---|
default | default | 0.0.0.0/0 — 모든 목적지를 의미 |
via | via 192.168.1.1 | 패킷을 전달할 게이트웨이 IP |
dev | dev eth0 | 패킷을 보낼 네트워크 인터페이스 |
proto | proto static | 경로 설정 방식 (static/kernel/dhcp) |
metric | metric 100 | 경로 우선순위 (낮을수록 우선) |
scope link | scope link | 직접 연결된 네트워크 (게이트웨이 불필요) |
핵심: default via 192.168.1.1 dev eth0 이 한 줄이 없으면 서버는 외부 세계로 나갈 방법이 없습니다.
게이트웨이란 무엇인가
게이트웨이(Gateway)는 서로 다른 네트워크를 연결해주는 라우터의 IP 주소입니다. 집에서 사용하는 공유기가 인터넷 게이트웨이 역할을 합니다.
[서버 192.168.1.50]
|
| eth0
|
[게이트웨이 192.168.1.1] ← 이 주소가 디폴트 라우트의 via
|
[인터넷]
서버 입장에서:
- 목적지가
192.168.1.x이면 → 직접 ARP로 통신 (게이트웨이 불필요) - 목적지가
8.8.8.8이면 → 디폴트 게이트웨이로 패킷 전달
게이트웨이가 날아가는 원인과 영구 설정
어제까지 정상이던 서버가 새벽에 외부 통신이 안 됩니다. NIC 오류로 인터페이스가 잠깐 내려갔다 올라오는 과정에서 게이트웨이 설정이 사라진 것입니다. ip route add default via ...로 임시 복구는 했지만 다음 재부팅이나 NIC 재시작에서 또 날아갈 것입니다. 영구 설정 방법을 모르면 이 문제가 반복됩니다.
NIC down/up 후 게이트웨이 소실 현상
네트워크 인터페이스를 수동으로 내렸다가 올리거나, 케이블을 뽑았다 꽂으면 DHCP 갱신 과정에서 게이트웨이 정보가 유실되는 경우가 있습니다.
# NIC를 내렸다가 다시 올림
$ ip link set eth0 down
$ ip link set eth0 up
# 디폴트 라우트 확인
$ ip route show
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50
# ↑ default 항목이 없음! 외부 통신 불가 상태
발생 원인 정리:
- DHCP 방식: DHCP 클라이언트가 재갱신 중 게이트웨이 옵션을 못 받아옴
- 정적 IP 방식:
ifup/ifdown스크립트 버그 또는 설정 파일 미적용 - NetworkManager 미사용: 수동
ip명령어로 설정한 경우 재시작 후 초기화 - Bonding/VLAN 재설정: 복잡한 네트워크 구성에서 순서 문제
수동 복구 방법
ip route vs route 명령어 문법의 차이와 계보
SRE 초동 진단 중 수동으로 디폴트 게이트웨이를 추가하거나 변경할 때 사용하는 명령어는 리눅스 커널 유틸리티의 세대에 따라 다음과 같이 상이하므로 혼동해서는 안 됩니다.
- 현대적인 권장 방식 (iproute2 계열):
ip route add default via [게이트웨이IP] dev [인터페이스명]로컬 터미널$ sudo ip route add default via 192.168.1.1 dev eth0 - 레거시 방식 (net-tools 계열 - 구형 리눅스):
route add default gw [게이트웨이IP] [인터페이스명]로컬 터미널$ sudo route add default gw 192.168.1.1 eth0- 틀린 문법 주의:
ifconfig eth0 gateway 192.168.1.1와 같은 문법은 존재하지 않으며,ifconfig는 오직 IP 주소와 넷마스크 등 L2/L3 기본 바인딩만을 다루는 도구입니다.
- 틀린 문법 주의:
ip route vs route 명령어 문법의 차이와 계보
SRE 초동 진단 중 수동으로 디폴트 게이트웨이를 추가하거나 변경할 때 사용하는 명령어는 리눅스 커널 유틸리티의 세대에 따라 다음과 같이 상이하므로 혼동해서는 안 됩니다.
- 현대적인 권장 방식 (iproute2 계열):
ip route add default via [게이트웨이IP] dev [인터페이스명]로컬 터미널$ sudo ip route add default via 192.168.1.1 dev eth0 - 레거시 방식 (net-tools 계열 - 구형 리눅스):
route add default gw [게이트웨이IP] [인터페이스명]로컬 터미널$ sudo route add default gw 192.168.1.1 eth0- 틀린 문법 주의:
ifconfig eth0 gateway 192.168.1.1와 같은 문법은 존재하지 않으며,ifconfig는 오직 IP 주소와 넷마스크 등 L2/L3 기본 바인딩만을 다루는 도구입니다.
- 틀린 문법 주의:
ip route vs route 명령어 문법의 차이와 계보
SRE 초동 진단 중 수동으로 디폴트 게이트웨이를 추가하거나 변경할 때 사용하는 명령어는 리눅스 커널 유틸리티의 세대에 따라 다음과 같이 상이하므로 혼동해서는 안 됩니다.
- 현대적인 권장 방식 (iproute2 계열):
ip route add default via [게이트웨이IP] dev [인터페이스명]로컬 터미널$ sudo ip route add default via 192.168.1.1 dev eth0 - 레거시 방식 (net-tools 계열 - 구형 리눅스):
route add default gw [게이트웨이IP] [인터페이스명]로컬 터미널$ sudo route add default gw 192.168.1.1 eth0- 틀린 문법 주의:
ifconfig eth0 gateway 192.168.1.1와 같은 문법은 존재하지 않으며,ifconfig는 오직 IP 주소와 넷마스크 등 L2/L3 기본 바인딩만을 다루는 도구입니다.
- 틀린 문법 주의:
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
# 디폴트 게이트웨이 추가
$ sudo ip route add default via 192.168.1.1 dev eth0
# 확인
$ ip route show
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50
# 외부 통신 테스트
$ ping -c 3 8.8.8.8
주의:
ip route add명령어로 추가한 경로는 런타임 설정입니다. 시스템이 재부팅되면 사라집니다.
영구 설정 방법
CentOS/RHEL: nmcli 사용
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
# 현재 연결 이름 확인
$ nmcli connection show
NAME UUID TYPE DEVICE
eth0 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ethernet eth0
# 게이트웨이 영구 설정
$ sudo nmcli connection modify eth0 ipv4.gateway 192.168.1.1
# 설정 적용 (연결 재시작)
$ sudo nmcli connection up eth0
# 확인
$ nmcli connection show eth0 | grep gateway
ipv4.gateway: 192.168.1.1
Ubuntu 18.04+: netplan 사용
# /etc/netplan/00-installer-config.yaml 편집
$ sudo nano /etc/netplan/00-installer-config.yaml
network:
version: 2
ethernets:
eth0:
addresses:
- 192.168.1.50/24
gateway4: 192.168.1.1 # 게이트웨이 설정
nameservers:
addresses: [8.8.8.8, 8.8.4.4]
# 설정 적용
$ sudo netplan apply
# 확인
$ ip route show
default via 192.168.1.1 dev eth0 proto static
구형 CentOS 6/7: /etc/sysconfig/network-scripts
# /etc/sysconfig/network-scripts/ifcfg-eth0
GATEWAY=192.168.1.1
기존 디폴트 라우트 교체
이미 잘못된 게이트웨이가 설정된 경우:
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
# 기존 디폴트 삭제
$ sudo ip route del default
# 새 게이트웨이로 추가
$ sudo ip route add default via 192.168.1.1 dev eth0
또는 replace 옵션으로 한 번에:
$ sudo ip route replace default via 192.168.1.1 dev eth0
목표
ip route show 출력을 해석하고 디폴트 게이트웨이 상태를 확인합니다.
단계
1단계: 라우팅 테이블 전체 조회 — 현재 설정된 모든 경로와 게이트웨이를 확인합니다.
$ ip route show
출력 예시:
default via 10.0.2.2 dev ens3 proto dhcp src 10.0.2.15 metric 100
10.0.2.0/24 dev ens3 proto kernel scope link src 10.0.2.15
10.0.2.2 dev ens3 proto dhcp scope link src 10.0.2.15 metric 100
2단계: 특정 목적지의 경로 확인 — 목적지 IP로 어떤 경로가 선택되는지 확인합니다.
# 8.8.8.8으로 패킷이 어떤 경로로 가는지 확인
$ ip route get 8.8.8.8
8.8.8.8 via 10.0.2.2 dev ens3 src 10.0.2.15 uid 1000
cache
# 내부 IP 경로 확인
$ ip route get 10.0.2.5
10.0.2.5 dev ens3 src 10.0.2.15 uid 1000
cache
3단계: 게이트웨이 응답 테스트 — 게이트웨이가 실제로 응답하는지 ping으로 확인합니다.
# 게이트웨이까지 ping (1홉)
$ ping -c 3 $(ip route show default | awk '{print $3}')
4단계: 외부 통신 확인 — 인터넷까지 패킷이 정상 전달되는지 확인합니다.
# 인터넷 연결 테스트
$ ping -c 3 8.8.8.8
# DNS 포함 전체 테스트
$ curl -s --max-time 5 https://www.google.com -o /dev/null && echo "OK" || echo "FAIL"
확인 포인트
default via항목이 있는가?- 게이트웨이 IP에 ping이 응답하는가?
- 외부 IP(8.8.8.8)에 ping이 성공하는가?
목표
디폴트 라우트를 삭제하여 장애를 재현하고, 수동으로 복구하는 과정을 실습합니다.
경고: 원격 SSH 세션에서 실습 시 연결이 끊길 수 있습니다. 반드시 콘솔 접근이 가능한 환경에서 실습하거나, 복구 명령어를 미리 준비해두세요.
단계
1단계: 현재 게이트웨이 IP 기록 — 복구 시 필요하므로 미리 메모합니다.
# 현재 게이트웨이 저장
$ GW=$(ip route show default | awk '{print $3}')
$ DEV=$(ip route show default | awk '{print $5}')
$ echo "게이트웨이: $GW, 인터페이스: $DEV"
게이트웨이: 192.168.1.1, 인터페이스: eth0
2단계: 디폴트 라우트 삭제 (장애 재현) — 실습용 장애 상황을 만듭니다.
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
$ sudo ip route del default
3단계: 장애 확인 — 디폴트 라우트 삭제 후 외부 통신이 끊긴 것을 확인합니다.
# 라우팅 테이블에서 default 항목 사라짐
$ ip route show
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50
# 외부 통신 불가 확인
$ ping -c 2 8.8.8.8
ping: connect: Network unreachable
4단계: 수동 복구 — ip route add로 디폴트 라우트를 다시 추가합니다.
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
# 저장해둔 변수로 복구
$ sudo ip route add default via $GW dev $DEV
# 또는 직접 입력
$ sudo ip route add default via 192.168.1.1 dev eth0
5단계: 복구 확인 — 외부 통신이 정상으로 돌아왔는지 확인합니다.
$ ip route show
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50
$ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=5.21 ms
핵심 명령어 요약
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
# 조회
ip route show
# 추가
sudo ip route add default via [GW_IP] dev [INTERFACE]
# 삭제
sudo ip route del default
# 교체
sudo ip route replace default via [GW_IP] dev [INTERFACE]
목표
NetworkManager(nmcli)를 사용해 재부팅 후에도 유지되는 게이트웨이 설정을 구성합니다.
단계 (CentOS/RHEL/Rocky Linux)
1단계: 현재 연결 상태 확인 — nmcli로 현재 네트워크 연결을 파악합니다.
$ nmcli connection show
NAME UUID TYPE DEVICE
System eth0 b3bde1b5-5c33-4a87-9b8c-24fd1b1e3d71 ethernet eth0
$ nmcli connection show "System eth0" | grep -E "ipv4\.(address|gateway|method)"
ipv4.method: auto
ipv4.addresses: --
ipv4.gateway: --
2단계: 정적 IP 및 게이트웨이 설정 — nmcli로 IP와 게이트웨이를 영구 설정합니다.
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
# IP 주소, 게이트웨이, DNS 동시 설정
$ sudo nmcli connection modify "System eth0" \
ipv4.method manual \
ipv4.addresses "192.168.1.50/24" \
ipv4.gateway "192.168.1.1" \
ipv4.dns "8.8.8.8,8.8.4.4"
3단계: 설정 적용 — 연결을 재시작해 변경 사항을 적용합니다.
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
$ sudo nmcli connection up "System eth0"
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/...)
4단계: 영구 설정 확인 — 설정 파일에 게이트웨이가 기록됐는지 확인합니다.
# nmcli로 확인
$ nmcli connection show "System eth0" | grep ipv4.gateway
ipv4.gateway: 192.168.1.1
# 실제 설정 파일 확인
$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
TYPE=Ethernet
BOOTPROTO=none
IPADDR=192.168.1.50
PREFIX=24
GATEWAY=192.168.1.1
DNS1=8.8.8.8
ONBOOT=yes
5단계: 재부팅 후 확인 시뮬레이션 — 연결을 내렸다가 올려서 재부팅 동작을 시뮬레이션합니다.
이 명령은 실행 중인 서비스 상태를 바꿔 순간적인 중단이나 설정 반영 실패를 만들 수 있습니다. 운영 트래픽 영향과 재시작 후 확인 명령을 먼저 준비하세요.
# NetworkManager 서비스 재시작으로 시뮬레이션
$ sudo systemctl restart NetworkManager
# 게이트웨이 유지 확인
$ ip route show | grep default
default via 192.168.1.1 dev eth0 proto static metric 100
Ubuntu netplan 설정 (참고)
$ cat /etc/netplan/01-network-config.yaml
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: no
addresses: [192.168.1.50/24]
gateway4: 192.168.1.1
nameservers:
addresses: [8.8.8.8, 8.8.4.4]
$ sudo netplan apply
현상
서버를 재부팅하거나 네트워크 서비스를 재시작한 후 외부 통신이 되지 않습니다.
$ ping 8.8.8.8
ping: connect: Network unreachable
$ ip route show
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.5
# default 항목 없음
원인 분석
| 원인 | 확인 방법 |
|---|---|
ip route add 로만 설정 (런타임) | 설정 파일에 GATEWAY 항목 없음 |
| DHCP 서버 응답 없음 | `journalctl -u NetworkManager |
| 설정 파일 문법 오류 | nmcli connection show 오류 메시지 |
| NetworkManager 비활성화 상태 | systemctl status NetworkManager |
해결 절차
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
# 1. 임시 복구
$ sudo ip route add default via 192.168.1.1 dev eth0
# 2. 설정 파일 확인 및 수정
$ cat /etc/sysconfig/network-scripts/ifcfg-eth0 | grep GATEWAY
# 없으면 추가:
$ echo "GATEWAY=192.168.1.1" | sudo tee -a /etc/sysconfig/network-scripts/ifcfg-eth0
# 3. NetworkManager로 영구 적용
$ sudo nmcli connection reload
$ sudo nmcli connection up eth0
재발 방지
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
# 네트워크 설정 검증 스크립트
$ cat /usr/local/bin/check-gateway.sh
#!/bin/bash
if ! ip route show | grep -q "^default"; then
logger "경고: 디폴트 게이트웨이 없음. 복구 시도"
ip route add default via 192.168.1.1 dev eth0
fi
현상
ip route show에 default via 항목은 있지만 인터넷이 되지 않습니다.
$ ip route show
default via 192.168.1.1 dev eth0
$ ping 8.8.8.8
# 응답 없음 (100% packet loss)
원인 분석
디폴트 라우트가 있어도 통신이 안 되는 경우:
- 게이트웨이 자체가 다운: 게이트웨이 장비 장애
- 잘못된 게이트웨이 IP: 실제 게이트웨이와 다른 IP 설정
- 업스트림 방화벽 차단: 네트워크 장비 레벨에서 ICMP 차단
- NAT 설정 문제: 게이트웨이에서 NAT가 올바르게 동작하지 않음
- ARP 캐시 오염: 게이트웨이 MAC 주소가 잘못 캐싱됨
단계별 확인
# 1. 게이트웨이에 ping
$ ping -c 3 192.168.1.1
PING 192.168.1.1: 100% packet loss # 게이트웨이 자체 문제
# 2. ARP 테이블 확인 (게이트웨이의 MAC 주소)
$ arp -n | grep 192.168.1.1
192.168.1.1 ether 00:00:00:00:00:00 # 불완전한 ARP → 문제!
# 3. ARP 강제 갱신
$ sudo arp -d 192.168.1.1
$ ping -c 1 192.168.1.1
# 4. 올바른 게이트웨이 IP인지 확인 (DHCP 서버 정보)
$ nmcli device show eth0 | grep GATEWAY
IP4.GATEWAY: 192.168.1.1
# 5. traceroute로 첫 번째 홉 확인
$ traceroute -n 8.8.8.8
traceroute to 8.8.8.8, 30 hops max
1 192.168.1.1 1.234 ms 1.456 ms 1.678 ms # 게이트웨이 도달 확인
2 * * * # 그 이후 차단
결론
게이트웨이까지는 통신되나 그 이후가 안 된다면 → 업스트림 네트워크 팀 또는 ISP 문제. 게이트웨이에도 ping이 안 된다면 → 로컬 네트워크 또는 게이트웨이 장비 문제.
실제 장애 시나리오
상황: 새벽 2시, 프로덕션 서버가 외부 API 호출에 실패하기 시작했다는 알람이 옵니다.
현업 대응 순서
1. 모니터링 대시보드 확인
→ 특정 서버만 장애인지, 전체 서버인지 파악
2. 해당 서버 SSH 접속 후 즉시 확인
$ ip route show # 게이트웨이 유무
$ ping -c 2 [게이트웨이] # 게이트웨이 응답
$ ping -c 2 8.8.8.8 # 외부 통신
3. 원인 파악
$ journalctl -u NetworkManager --since "10 minutes ago"
→ DHCP 갱신 실패 로그 발견
4. 임시 복구 (서비스 우선 복구)
$ sudo ip route add default via 192.168.1.1 dev eth0
→ 서비스 즉시 정상화 확인
5. 근본 원인 해결 (영구 설정)
$ sudo nmcli connection modify eth0 ipv4.gateway 192.168.1.1
$ sudo nmcli connection up eth0
6. 재발 방지 논의
→ DHCP 임대 시간 증가 또는 정적 IP 전환 검토
→ 게이트웨이 모니터링 추가 (Prometheus + Alertmanager)
온콜 엔지니어가 알아야 할 것
ip route는 런타임: 설정 파일을 반드시 함께 수정할 것- 임시 복구와 영구 수정을 구분: 먼저 서비스를 살리고, 그 다음 근본 원인을 해결
- 변경 사항은 티켓에 기록: 다음 교대자가 알 수 있도록
- 재부팅 테스트: 영구 설정 적용 후 maintenance window에 재부팅으로 검증
클라우드 환경 차이점
AWS/GCP/Azure 같은 클라우드 환경에서는:
- VPC 라우팅 테이블은 콘솔/IaC로 관리 (OS 레벨이 아님)
- 인스턴스 재생성 시 기본 게이트웨이 자동 설정
- OS 레벨 ip route는 클라우드 내부 라우팅에만 영향
- 인터넷 게이트웨이(IGW) 설정은 VPC 레벨에서 별도 관리
클라우드 환경에서 외부 통신이 안 될 때는 OS 레벨보다 VPC 라우팅 테이블, 보안 그룹, NAT 게이트웨이 설정을 먼저 확인하세요.
관련 도구 및 스킬
| 상황 | 도구 |
|---|---|
| 라우팅 테이블 확인 | ip route show, netstat -rn |
| 경로 추적 | traceroute, mtr |
| 게이트웨이 응답 | ping, arping |
| 영구 설정 (RHEL) | nmcli, /etc/sysconfig/network-scripts/ |
| 영구 설정 (Ubuntu) | netplan, /etc/netplan/ |
핵심 명령어 치트시트
이 명령은 서버의 라우팅 또는 인터페이스 설정을 바꿔 원격 접속이 끊길 수 있습니다. 콘솔 접근과 현재 라우팅 백업을 확보한 뒤 실행하세요.
# ===== 조회 =====
ip route show # 전체 라우팅 테이블
ip route show default # 디폴트 라우트만
ip route get 8.8.8.8 # 특정 목적지의 경로
netstat -rn # 구형 방식 (동일 기능)
# ===== 수동 설정 (런타임) =====
sudo ip route add default via GW_IP dev IFACE # 추가
sudo ip route del default # 삭제
sudo ip route replace default via GW_IP dev IFACE # 교체
# ===== 영구 설정 =====
# CentOS/RHEL (nmcli)
sudo nmcli connection modify CONN ipv4.gateway GW_IP
sudo nmcli connection up CONN
# Ubuntu (netplan)
sudo nano /etc/netplan/00-config.yaml # gateway4: GW_IP 추가
sudo netplan apply
정리
디폴트 라우팅은 서버가 외부와 통신하기 위한 필수 조건입니다. NIC 재시작이나 설정 변경 후 반드시 ip route show로 default via 항목을 확인하는 습관을 가지세요. 런타임 복구와 영구 설정을 명확히 구분하고, 설정 변경 후에는 반드시 재부팅 테스트로 영구 적용 여부를 검증하세요.