인터넷과 관리망 접속은 정상인데 특정 사내 대역으로만 연결되지 않는다면, 그 목적지에 사용할 경로를 따로 지정해야 할 수 있습니다. 이 글은 기본 게이트웨이는 유지하면서 172.16.50.0/24만 내부 라우터로 보내는 정적 라우팅을 Rocky Linux에서 구성하는 예제입니다.
Rocky Linux 9의 NetworkManager 환경을 기준으로 설명합니다. 먼저 ip route로 경로를 시험한 뒤, nmcli로 연결 프로필에 저장합니다. NIC 이름·연결 프로필·IP 주소는 실제 서버에 맞게 바꿉니다.
이 글의 목차
예제의 목적지와 다음 홉
| 항목 | 예제 값 |
|---|---|
| 관리망 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 |
다음 홉은 목적지로 가기 위해 패킷을 먼저 넘길 라우터입니다. 서버의 192.168.20.10/24와 다음 홉 192.168.20.1은 같은 링크에서 통신할 수 있어야 합니다. 라우터는 172.16.50.0/24로 전달하는 경로와 정책을 갖고 있어야 합니다.
정적 IP는 서버 자신의 주소를 고정하는 설정이고, 정적 라우팅은 목적지별 전달 방향을 정하는 설정이에요. 여기서는 이미 설정된 두 NIC의 주소를 사용합니다. 주소 설정이 먼저 필요하다면 Rocky Linux 고정 IP 설정 글을 참고하세요.
1. NIC와 연결 프로필부터 확인
cat /etc/rocky-release
nmcli --version
ip -br address
ip -4 route show
nmcli -f NAME,UUID,TYPE,DEVICE connection show --active
nmcli -g GENERAL.CONNECTION device show ens19ens19는 인터페이스 이름이며 NetworkManager 연결 프로필 이름과 다를 수 있습니다. 아래부터는 해당 NIC의 활성 프로필이 internal-lan이라고 가정합니다. 이름이 다르면 확인한 값으로 바꾸고, 같은 이름이 여러 개라면 활성 프로필의 UUID로 대상을 지정합니다.
PROFILE='internal-lan'
nmcli -f connection.id,connection.interface-name,ipv4.addresses,ipv4.gateway,ipv4.routes \
connection show "$PROFILE"
ip -4 route get 192.168.20.1
ip -4 route get 172.16.50.20
ip -4 route show default다음 홉 192.168.20.1이 ens19의 직접 연결 경로로 조회되는지 확인합니다. SSH로 작업한다면 실제 접속 PC 주소도 ip route get으로 확인해 두세요. 추가할 목적지에 접속 PC가 포함되면 SSH의 응답 경로도 바뀔 수 있습니다.
프로필 파일은 아래처럼 별도 디렉터리에 보관합니다. 백업에는 접속 정보가 들어 있을 수 있으므로 root만 읽을 수 있는 위치를 사용합니다. NetworkManager의 프로필과 장치 상태 구분은 Rocky Linux 네트워크 문서에서도 확인할 수 있습니다.
BACKUP_DIR="/root/nm-route-backup-$(date +%Y%m%d-%H%M%S)"
sudo install -d -m 700 "$BACKUP_DIR"
sudo cp -a /etc/NetworkManager/system-connections "$BACKUP_DIR/"2. ip route로 임시 경로 시험
아래 명령은 현재 커널의 라우팅 테이블에 경로를 추가합니다. 재부팅이나 네트워크 재구성 후에도 남길 설정은 다음 절에서 저장합니다. 같은 경로가 이미 있다면 추가하기 전에 기존 항목의 목적과 메트릭을 확인합니다.
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이 주소 구성에서 조회 결과는 다음 형태가 됩니다. via가 내부 라우터, dev가 내부망 NIC, src가 내부망 주소인지 읽습니다. 부가 필드와 출력 형식은 iproute2 버전에 따라 달라질 수 있습니다.
172.16.50.20 via 192.168.20.1 dev ens19 src 192.168.20.10ip route get은 커널이 선택한 경로를 보여 줍니다. 실제 패킷이 상대편에 도착했다는 검사는 아니므로 ping이나 허용된 서비스 연결도 따로 확인합니다. ICMP가 차단된 환경에서는 ping 실패만으로 라우팅 오류라고 판단하지 않습니다.
시험 경로가 맞으면 임시 항목을 제거하고 영구 프로필에 추가합니다. 이렇게 하면 수동 경로와 NetworkManager가 관리하는 경로가 겹치는 상황을 줄일 수 있어요.
sudo ip route del 172.16.50.0/24 via 192.168.20.1 dev ens19 metric 1003. nmcli로 영구 경로 추가
PROFILE='internal-lan'
sudo nmcli connection modify "$PROFILE" \
+ipv4.routes "172.16.50.0/24 192.168.20.1 100"
nmcli -f ipv4.routes connection show "$PROFILE"
sudo nmcli device reapply ens19값의 순서는 목적지/접두사 다음홉 메트릭입니다. 앞의 +는 기존 경로 목록에 항목을 추가합니다. ipv4.routes만 쓰면 기존 목록을 교체하므로 이미 저장된 다른 경로를 지울 수 있습니다. 추가·삭제 문법은 RHEL 9 정적 경로 구성 문서와 대조했습니다.
connection modify는 프로필을 저장하고, device reapply는 활성 연결에 변경분 적용을 시도합니다. 성공 메시지 뒤에도 실제 라우팅 테이블을 확인합니다. 이때 기본 게이트웨이나 NIC 주소를 함께 바꾸지는 않습니다.
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.20reapply가 지원하지 않는 변경이라고 응답하거나 반영되지 않았다면, 콘솔을 확보한 유지보수 시간에 아래처럼 프로필을 재활성화합니다. 연결이 잠시 끊길 수 있습니다. 두 명령의 역할은 nmcli 장치 관리 문서를 참고하세요.
sudo nmcli connection up "$PROFILE" ifname ens19활성 프로필이 자동 연결되도록 관리되는 환경에서는 저장한 경로도 다음 활성화 때 적용됩니다. 운영 서버의 재부팅 검증은 유지보수 시간에 진행하고, 재부팅 후 같은 ip route get과 실제 서비스 연결을 다시 확인합니다.
4. 서버 한 대·여러 대역에 적용하는 예제
특정 서버 한 대만 다른 라우터로 보내기
sudo nmcli connection modify "$PROFILE" \
+ipv4.routes "172.16.50.20/32 192.168.20.1 100"
sudo nmcli device reapply ens19
ip -4 route get 172.16.50.20/32는 IPv4 주소 한 개에 대한 경로입니다. 같은 테이블에서는 더 구체적인 접두사가 먼저 선택되므로 /32가 /24보다 우선합니다. 같은 목적지·접두사의 경로를 비교할 때는 낮은 메트릭이 우선하며, 정책 라우팅의 규칙은 그보다 앞서 테이블 선택에 영향을 줄 수 있습니다.
같은 다음 홉으로 두 대역 추가하기
sudo nmcli connection modify "$PROFILE" +ipv4.routes \
"172.16.60.0/24 192.168.20.1 100, 172.16.70.0/24 192.168.20.1 100"
sudo nmcli device reapply ens19예제는 필요에 맞춰 골라 사용합니다. 앞 절의 172.16.50.0/24와 위 두 대역은 서로 다른 경로입니다. 더 넓은 대역 하나로 임의로 묶으면 다른 목적지까지 경로가 바뀔 수 있으므로 실제 할당 범위를 유지합니다.
5. 경로는 있는데 통신이 안 될 때
ip -4 route get 172.16.50.20
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.10으로 돌아올 경로가 없으면 연결되지 않습니다. 목적지 서버의 게이트웨이 또는 그 라우터에서 192.168.20.0/24로 돌아오는 경로를 확인합니다. 상대편 Linux에서도 ip route get 192.168.20.10으로 확인할 수 있습니다.
이 글의 Rocky 서버는 자신이 만든 트래픽을 보내는 호스트입니다. 두 NIC 사이에서 다른 장비의 패킷을 중계하는 라우터로 쓰는 경우에만 IP forwarding과 전달 방화벽 정책이 추가로 필요합니다. 커널 IP forwarding 문서의 적용 대상을 구분하고, 경로 문제를 해결하려고 서버의 방화벽 전체를 내리지는 않습니다.
메시지가 Nexthop has invalid gateway라면 NIC 주소·넷마스크·VLAN·가상 스위치 연결부터 확인합니다. onlink로 오류 표시만 없애도 게이트웨이가 같은 링크에 실제로 생기지는 않습니다. 해당 속성은 NetworkManager IPv4 설정 문서에 정의되어 있습니다.
6. 추가한 경로 삭제와 복구
영구 항목을 지우려면 같은 프로필에서 해당 경로만 제거합니다. 메트릭을 지정해 추가했다면 삭제할 때도 같은 값을 사용합니다.
sudo nmcli connection modify "$PROFILE" \
-ipv4.routes "172.16.50.0/24 192.168.20.1 100"
sudo nmcli device reapply ens19
nmcli -f ipv4.routes connection show "$PROFILE"
ip -4 route show 172.16.50.0/24
ip -4 route get 172.16.50.20커널의 경로만 삭제하면 프로필 재활성화 때 다시 생깁니다. 반대로 프로필만 고치고 활성 상태에 반영하지 않으면 기존 경로가 잠시 남을 수 있습니다. 저장된 프로필과 실행 중인 테이블을 함께 확인하세요.
SSH가 끊겼다면 가상화 콘솔에서 잘못 추가한 프로필 항목을 제거한 뒤 재적용합니다. 프로필 자체를 복구해야 한다면 백업에서 해당 프로필 파일만 원래 위치로 되돌리고 sudo nmcli connection reload 후 올바른 프로필을 활성화합니다. 전체 라우팅 테이블을 비우면 관리망의 기본 경로까지 사라질 수 있으므로 추가한 항목을 정확히 지정합니다.
예제 파일과 확인 환경
Rocky Linux 정적 라우팅 예제 ZIP에는 프로필에 추가·삭제하는 명령과 읽기 전용 확인 명령을 넣었습니다. 예제 주소를 실제 값으로 바꾼 뒤 필요한 부분만 사용합니다. Ubuntu에서 같은 경로를 구성하는 방법은 Ubuntu Netplan 정적 라우팅 글에 정리했습니다.
2026년 10월 23일 Rocky Linux 9 컨테이너의 NetworkManager 1.54.3-5.el9_8에서 격리된 가상 링크와 네트워크 네임스페이스로 확인했습니다. 임시 경로의 통신, 프로필 저장·재적용·재활성화, 기존 다른 경로를 유지한 삭제와 /32 경로를 실행했습니다. 반환 경로 제거 시 통신 실패와 복원 후 성공도 확인했습니다. 실제 VM의 OS 재부팅과 SSH 단절 복구는 실행 검증하지 않았습니다.
