두 개의 NIC를 쓰는 Ubuntu 서버에서 인터넷은 관리망으로, 특정 사내 대역은 내부 라우터로 보내려면 목적지별 경로를 추가하면 됩니다. 이 글에서는 172.16.50.0/24만 ens19의 192.168.20.1로 보내고 기존 기본 경로는 유지합니다.
Ubuntu 24.04·26.04의 Netplan 구성을 다루며, NetworkManager 프로필을 직접 관리하는 환경의 대안도 함께 설명합니다. 버전만 보고 관리 방식을 정하지 말고 해당 NIC의 renderer와 설정 원본을 먼저 확인합니다.
이 글의 목차
목적지·게이트웨이·NIC 구분
| 항목 | 예제 값 |
|---|---|
| 관리망 NIC | ens18 · 192.168.10.50/24 |
| 기본 게이트웨이 | 192.168.10.1 |
| 내부망 NIC | ens19 · 192.168.20.10/24 |
| 내부망 라우터 | 192.168.20.1 |
| 목적지 대역·서버 | 172.16.50.0/24 · 172.16.50.20 |
서버의 ens19 주소는 192.168.20.10/24로 이미 설정되어 있다고 가정합니다. 목적지 172.16.50.0/24는 직접 연결된 대역이 아니므로 같은 링크의 라우터 192.168.20.1에 넘깁니다. 그 라우터와 상대편에서도 전달·반환 경로가 준비되어 있어야 합니다.
고정 IP와 정적 라우팅은 서로 다른 설정입니다. IP·DNS부터 구성해야 한다면 Ubuntu 24.04 고정 IP 설정 또는 Ubuntu 26.04 두 NIC 구성을 먼저 확인하세요.
1. 실제 네트워크 관리 방식 확인
cat /etc/os-release
ip -br address
ip -4 route show
ls -l /etc/netplan/
sudo netplan get
systemctl is-active systemd-networkd NetworkManagerNetplan은 YAML 설정을 읽어 systemd-networkd 또는 NetworkManager가 사용할 설정을 생성합니다. Server·Desktop·클라우드 이미지에 따라 구성이 다를 수 있어요. 두 서비스가 모두 실행 중이어도 같은 NIC를 둘 다 관리한다는 뜻은 아닙니다.
sudo netplan get에서 해당 NIC의 설정과 renderer를 읽고, networkd 환경은 networkctl status ens19, NetworkManager 환경은 nmcli device status로 소유 관계를 확인합니다. Netplan YAML이 원본이면 그 YAML에서 경로를 관리합니다. 개요는 Ubuntu Server 네트워크 문서를 참고하세요.
SSH 접속 PC의 주소와 현재 반환 경로도 확인합니다. 아래 주소는 예시이므로 실제 접속 PC 주소로 바꿉니다. 변경 전에 콘솔 접속 수단과 설정 백업을 확보합니다.
ip -4 route get 192.168.10.100
ip -4 route get 192.168.20.1
ip -4 route get 172.16.50.20
BACKUP_DIR="/root/netplan-route-backup-$(date +%Y%m%d-%H%M%S)"
sudo install -d -m 700 "$BACKUP_DIR"
sudo cp -a /etc/netplan "$BACKUP_DIR/"50-cloud-init.yaml처럼 이미지 배포 도구가 만드는 파일은 설정 원본도 확인합니다. cloud-init이 네트워크를 다시 생성하는 환경에서는 수동 변경이 나중에 덮어써질 수 있습니다. 원본을 바꿀지 수동 관리로 전환할지 정한 뒤 수정하며, 이 글의 정적 경로를 위해 cloud-init 전체를 끌 필요는 없습니다.
2. 임시 경로로 먼저 통신 확인
sudo ip route add 172.16.50.0/24 via 192.168.20.1 dev ens19 metric 100
ip -4 route get 172.16.50.20
ping -c 3 -W 1 172.16.50.20이 명령은 현재 커널에만 반영합니다. 올바른 구성에서는 다음 형태로 경로가 선택됩니다. 주소가 실제로 있는지와 다음 홉에 도달할 수 있는지도 확인합니다.
172.16.50.20 via 192.168.20.1 dev ens19 src 192.168.20.10임시 시험이 끝나면 해당 항목을 지우고 Netplan으로 저장합니다. 같은 경로가 이미 존재해 File exists가 나왔다면 기존 경로를 읽은 뒤 중복 여부를 판단하세요. 이 오류를 없애려고 기본 경로나 다른 항목을 삭제하지 않습니다.
sudo ip route del 172.16.50.0/24 via 192.168.20.1 dev ens19 metric 1003. 기존 Netplan NIC에 routes 추가
주소·DNS·DHCP·renderer는 유지하고 해당 NIC의 기존 routes: 목록에 목적지 항목만 추가합니다. 아래 코드는 추가할 계층을 보여 주는 조각이며 기존 파일 전체를 이 내용으로 덮어쓰는 예제가 아닙니다.
# 기존 NIC의 routes 목록에 합칩니다. 기존 주소와 renderer는 유지합니다.
network:
version: 2
ethernets:
ens19:
routes:
- to: 172.16.50.0/24
via: 192.168.20.1
metric: 100이미 routes:가 있으면 같은 목록에 - to: 항목을 더합니다. 같은 YAML 매핑 안에 routes:를 두 번 만들지 않습니다. ens19 대신 internal: 같은 ID와 match:로 장치를 정의했다면 그 기존 ID 아래에 넣습니다.
to는 목적지, via는 다음 홉, metric은 같은 목적지·접두사의 경로를 비교할 때 쓰는 값입니다. to: default를 내부망에 추가하는 것과는 다릅니다. 설정 항목은 Netplan 라우팅 형식에 정의되어 있습니다.
두 NIC를 처음 구성하는 실습용 전체 파일
다음은 앞의 예제 주소를 모두 포함한 networkd용 전체 구성입니다. 새 실습 VM에서만 이 주소와 구성을 사용하고, 기존 서버는 앞서 설명한 경로 항목만 반영합니다. 관리망에는 기본 경로 한 개, 내부망에는 특정 대역 경로만 둡니다.
network:
version: 2
renderer: networkd
ethernets:
ens18:
dhcp4: false
addresses: [192.168.10.50/24]
routes:
- to: default
via: 192.168.10.1
metric: 100
nameservers:
addresses: [192.168.10.1]
ens19:
dhcp4: false
addresses: [192.168.20.10/24]
routes:
- to: 172.16.50.0/24
via: 192.168.20.1
metric: 100전체 파일을 실습에 쓸 때는 /etc/netplan/60-routing-lab.yaml 같은 이름으로 저장하고 sudo chmod 600 /etc/netplan/60-routing-lab.yaml로 권한을 정합니다. 다른 YAML에서 같은 NIC를 이미 정의했다면 병합 결과부터 확인합니다. 경로 목록 같은 시퀀스는 병합될 수 있어 새 파일 하나로 기존 항목이 모두 대체된다고 가정하면 안 됩니다.
4. 구문 검사 후 netplan try로 적용
sudo netplan get
sudo netplan generate
sudo netplan try --timeout 120generate는 설정을 검사하고 백엔드용 파일을 생성하지만 실행 중인 네트워크를 재구성하지는 않습니다. 오류가 있으면 적용 전에 YAML 들여쓰기와 키를 고칩니다. Netplan generate 문서에서 두 동작을 구분합니다.
try는 제한 시간 안에 변경을 확인하도록 합니다. 확인 대기 중 다른 터미널에서 SSH 재접속과 아래 경로·통신을 검사한 뒤 원래 터미널에서 승인합니다. 연결이 안 되면 콘솔에서 상태를 확인합니다.
ip -4 route show 172.16.50.0/24
ip -4 route get 172.16.50.20
ip -4 route show default
ping -c 3 -W 1 172.16.50.20try가 시간 초과나 취소로 끝났을 때는 실제 경로가 원래대로 돌아왔는지 확인합니다. 디스크의 YAML도 기대한 상태인지 확인한 뒤 재부팅합니다. 자동 복귀만 믿지 말아야 하는 이유는 공식 try 문서의 알려진 문제에 설명되어 있습니다.
콘솔에서 작업하고 변경을 바로 적용할 조건이 갖춰졌다면 sudo netplan apply를 사용할 수 있습니다. 승인된 YAML은 다음 부팅에서도 설정 원본으로 사용됩니다. 유지보수 재부팅 후에는 ip route get과 서비스 연결을 다시 확인합니다.
5. 서버 한 대만 지정하거나 경로 삭제하기
특정 서버 한 대만 지정하려면 목적지에 /32를 씁니다. 다음 항목을 필요한 NIC의 routes: 목록에 넣습니다. 아래처럼 항목 하나를 보여 주는 코드는 독립된 Netplan 전체 파일이 아닙니다.
- to: 172.16.50.20/32
via: 192.168.20.1
metric: 100같은 테이블에서는 /32가 /24보다 구체적이므로 먼저 선택됩니다. 낮은 메트릭으로 더 넓은 대역을 적었다고 이 우선순위를 뒤집지는 못합니다. 출발지별 테이블 선택이 필요하면 별도의 정책 라우팅 문제로 다룹니다.
삭제할 때는 원본 YAML에서 추가한 목적지 항목만 제거합니다. 다른 경로가 있으면 목록을 남기고, 더 이상 항목이 없을 때만 비어 있는 routes: 키를 함께 지웁니다. 다시 generate와 try로 적용합니다.
sudo netplan generate
sudo netplan try --timeout 120
ip -4 route show 172.16.50.0/24
ip -4 route get 172.16.50.20추가한 경로가 없어지면 목적지는 기존 기본 경로나 다른 일치 경로로 조회될 수 있습니다. sudo ip route del로 커널에서만 지운 항목은 다음 apply나 재부팅 때 YAML에서 다시 생성되므로, 영구 삭제는 원본 파일에서 합니다.
6. NetworkManager 프로필을 직접 관리하는 경우
기존 환경에서 해당 NIC의 원본을 NetworkManager 프로필로 관리하고 있다면 다음 방법을 사용합니다. 같은 NIC를 Netplan YAML과 nmcli 양쪽에서 번갈아 수정하면 원본을 추적하기 어려워집니다. Netplan이 생성한 프로필을 쓰는 경우에는 앞의 YAML 경로를 우선합니다.
nmcli -f NAME,UUID,TYPE,DEVICE connection show --active
nmcli -g GENERAL.CONNECTION device show ens19
PROFILE='internal-lan'
sudo nmcli connection modify "$PROFILE" \
+ipv4.routes "172.16.50.0/24 192.168.20.1 100"
sudo nmcli device reapply ens19
ip -4 route get 172.16.50.20internal-lan은 앞에서 확인한 실제 프로필 이름으로 바꿉니다. 삭제는 -ipv4.routes로 같은 항목을 지정한 뒤 재적용합니다. 프로필 재활성화가 필요하면 연결이 끊길 수 있으므로 콘솔에서 진행합니다. 자세한 추가·삭제 예제는 nmcli 정적 라우팅 글과 NetworkManager 문서를 참고하세요.
7. 적용됐는데 연결되지 않을 때와 SSH 복구
ip -4 route get 172.16.50.20 from 192.168.20.10
ping -c 3 -W 1 192.168.20.1
ip neigh show dev ens19
ip -4 rule show
ip -4 route show table all| 증상 | 다음 확인 |
|---|---|
| 게이트웨이가 유효하지 않음 | ens19 주소·접두사와 게이트웨이의 같은 링크 여부 확인 |
| 기본 게이트웨이로 나감 | 목적지 오타, 더 구체적인 경로, ip rule과 다른 테이블 확인 |
| 경로는 맞지만 응답 없음 | 다음 홉 도달 여부, 라우터의 전달·ACL, 상대편 반환 경로 확인 |
| 재부팅 뒤 경로 사라짐 | ip route 임시 설정만 했는지와 영구 설정의 로딩 여부 확인 |
목적지 서버와 중간 라우터에도 192.168.20.0/24로 응답을 돌려보낼 경로가 필요합니다. IP로 연결되는데 이름으로만 실패하면 DNS를 별도로 확인하고, ping만 막힌 경우에는 허용된 서비스 포트로 검사합니다. 패킷이 출발하는 서버의 경로 하나만으로 양방향 통신이 보장되지는 않습니다.
Ubuntu 서버가 다른 장비의 패킷을 두 NIC 사이에서 중계하는 역할이라면 IP forwarding과 전달 방화벽 정책도 구성해야 합니다. 일반 호스트에 정적 경로를 추가하는 이번 예제와는 적용 범위가 다릅니다. 커널의 IP forwarding 설명을 기준으로 역할을 구분합니다.
SSH가 끊겼다면 콘솔에서 ip route와 실제 접속 PC 방향을 먼저 확인합니다. 원본 YAML에서 잘못 추가한 경로를 제거하거나 백업의 해당 파일을 복원한 뒤, sudo netplan generate와 콘솔에서의 sudo netplan apply로 복구합니다. 새로 만든 실습 파일이 원인이면 그 파일만 제거하고 기존 파일을 유지합니다. 다른 작업 이후의 변경까지 백업으로 덮어쓰지 않도록 수정한 파일을 비교합니다.
예제 다운로드와 검증 범위
Ubuntu 정적 라우팅 예제 ZIP에는 기존 NIC에 추가할 경로 조각, 두 NIC 전체 구성, /32 항목과 확인 명령을 넣었습니다. 실제 서버에는 경로 조각을 참고해 기존 설정에 필요한 항목만 더합니다. 먼저 다음 홉과 목적지를 확인하고, 적용 후 관리망과 사내 서비스 연결을 함께 확인하세요.
2026년 10월 23일 Ubuntu 24.04.5 컨테이너의 Netplan 1.1.2와 systemd 255에서 설정 생성 후 networkd로 적용한 경로의 실제 통신과 renderer 재시작 후 경로 유지를 확인했습니다. Ubuntu 26.04 컨테이너의 Netplan 1.2에서도 설정 생성, NetworkManager 1.54.3에서 경로를 포함한 프로필의 오프라인 생성을 검사했습니다. 테스트는 격리된 가상 링크에서 진행했으며, 실제 VM 재부팅·netplan try의 시간 초과 복구·SSH 단절 복구는 실행 검증에 포함하지 않았습니다.
