Rocky Linux 버전별 고정 라우팅 설정방법 및 명령어 운용 백서
목차
1. 정적 라우팅의 개념과 Rocky Linux 버전별 차이
정적 라우팅은 특정 목적지 네트워크 또는 특정 호스트로 향하는 트래픽을 지정한 다음 홉 게이트웨이 또는 지정 인터페이스로 보내도록 고정하는 설정입니다. 기본 게이트웨이만으로는 원하는 망 분리 정책을 구현할 수 없을 때 사용하며, 내부 백업망, 전용 회선, 대외계 연계망, VPN 우회, 특정 업무망 강제 경로 구성이 대표적인 적용 사례입니다.
Rocky Linux 8부터는 NetworkManager 기반 관리가 사실상 기본 운영 방식으로 자리 잡았으며, Rocky Linux 9와 10으로 갈수록 keyfile 기반 관리와 `nmcli` 중심 구성이 더 표준화되는 흐름입니다. 따라서 신규 구축이라면 버전에 관계없이 `nmcli` 중심으로 표준을 통일하는 편이 가장 관리성이 높습니다. 다만 장기 운영 서버나 마이그레이션된 시스템에서는 여전히 `route-인터페이스명` 파일이나 ifcfg 계열 흔적을 만나게 되므로, 두 방식을 함께 이해해야 실제 장애 대응이 가능합니다.
| 버전 | 운영 특성 | 권장 방식 |
|---|---|---|
| Rocky Linux 8 | NetworkManager 사용이 일반적이며, 일부 환경에서는 레거시 파일 기반 설정이 남아 있을 수 있습니다. | 신규 구축은 `nmcli`, 기존 서버 유지보수는 `nmcli`와 `route-IFACE` 파일을 함께 해석하는 방식이 적합합니다. |
| Rocky Linux 9 | keyfile 및 NetworkManager 중심 구조가 더 명확합니다. | 영구 라우팅은 `nmcli connection modify ... ipv4.routes` 기준으로 표준화하는 것이 적절합니다. |
| Rocky Linux 10 | 최신 문서 체계도 NetworkManager와 connection profile 중심입니다. | 레거시 방식보다 `nmcli` 표준만 유지하는 편이 장기적으로 유리합니다. |
2. 현재 라우팅 상태 점검과 필수 진단 명령
정적 라우트를 추가하기 전에 먼저 확인해야 하는 것은 인터페이스명, connection profile 이름, 현재 IP 주소, 기본 게이트웨이, 기존 라우팅 테이블입니다. 이 선행 점검이 부족하면 잘못된 인터페이스에 라우트를 넣거나, 저장은 되었지만 실제 적용이 안 되는 상황이 자주 발생합니다.
특히 `nmcli`는 물리 인터페이스명과 connection profile 이름이 서로 다를 수 있으므로, `enp1s0`가 장치명인지 연결명인지 먼저 분리해서 보는 습관이 필요합니다. 실무에서는 이 차이 때문에 “명령은 성공했는데 설정 대상이 달랐다”는 유형의 장애가 매우 흔합니다.
| 명령 | 확인 대상 | 실무 의미 |
|---|---|---|
| `ip a` | 현재 인터페이스별 IP 주소, 링크 상태 | 라우트의 출발 인터페이스 후보를 확인합니다. |
| `ip route` | 현재 커널 라우팅 테이블 | 실제 패킷 포워딩 기준을 확인합니다. |
| `nmcli device status` | 장치 상태와 연결 여부 | 활성 NIC와 비활성 NIC를 구분합니다. |
| `nmcli connection show` | 연결 프로필 목록 | 영구 설정 변경 대상 프로필을 정확히 찾습니다. |
| `nmcli device show enp1s0` | IP4.GATEWAY, IP4.ROUTE, DNS 등 상세 값 | 적용 후 검증에도 그대로 활용할 수 있습니다. |
3. 임시 적용 방식: ip route 명령 사용법
가장 빠른 검증 방법은 `ip route add`를 사용하는 방식입니다. 이 명령은 커널 라우팅 테이블에 즉시 반영되므로, 운영 변경 전에 실제 통신 경로가 맞는지 시험하는 데 매우 유용합니다. 다만 네트워크 재기동 또는 시스템 재부팅 이후에는 유지되지 않을 수 있으므로, 실서버 반영은 여기서 끝내면 안 됩니다.
3-1. 특정 네트워크 대역 경로 추가
위 명령은 `10.10.10.0/24` 대역으로 가는 트래픽을 `192.168.1.1` 게이트웨이를 통해 `enp1s0` 인터페이스로 보내도록 강제합니다. 여기서 중요한 원리는 다음 홉 게이트웨이가 현재 인터페이스에서 실제로 도달 가능한 주소여야 한다는 점입니다. 즉, 논리적으로만 존재하는 게이트웨이는 설정이 들어가더라도 실제 통신이 실패합니다.
3-2. 특정 호스트 경로 추가
호스트 라우트는 특정 단일 IP에 대해서만 별도 경로를 강제할 때 사용합니다. 대외 기관 단일 서버, 특정 DB 리스너, 특정 백업 장비처럼 “한 대만 다른 망으로 보내야 하는 상황”에서 매우 유용합니다.
3-3. 기본 게이트웨이 임시 변경
기본 경로는 모든 미지정 목적지로 가는 트래픽의 최종 우회로입니다. 따라서 기본 게이트웨이를 임시로 넣는 테스트는 영향 범위가 넓으므로, 서버 운영 중에는 유지보수 창구나 분리 환경에서 먼저 시험하는 편이 안전합니다.
3-4. 삭제 명령
4. 영구 적용 방식: nmcli 기반 표준 설정
Rocky Linux 8 이후의 실무 표준은 NetworkManager connection profile에 정적 경로를 저장하는 방식입니다. 핵심 명령은 `nmcli connection modify 연결명 +ipv4.routes "목적지CIDR 다음홉"` 형태이며, 설정 후 connection을 다시 활성화해야 실제 커널 라우팅 테이블에도 반영됩니다.
이 방식의 장점은 다음과 같습니다. 첫째, 재부팅 후에도 유지됩니다. 둘째, 변경 내역을 connection profile 기준으로 관리할 수 있습니다. 셋째, 동일한 방법으로 주소, 게이트웨이, DNS, 정책 라우팅 규칙까지 한 체계 안에서 다룰 수 있습니다.
4-1. 단일 정적 라우트 추가
여기서 `enp1s0`는 실제로는 connection profile 이름일 수도 있고, 인터페이스명과 동일하게 맞춰져 있을 수도 있습니다. 따라서 명령 입력 전 `nmcli connection show`로 정확한 이름을 확인하는 습관이 중요합니다.
4-2. 여러 정적 라우트 추가
여러 경로를 개별 명령으로 순차 추가하면 변경 이력이 명확해지고 롤백 포인트도 분리됩니다. 실무에서는 이 방식이 특히 좋습니다. 반면 한 줄에 여러 설정을 과도하게 묶으면 오타가 났을 때 원인 파악이 느려질 수 있습니다.
4-3. Metric 포함 경로 추가
Metric은 동일 목적지 또는 유사한 후보 경로가 여러 개 있을 때 우선순위 판단에 사용됩니다. 일반적으로 숫자가 낮을수록 우선순위가 높게 해석되므로, 주 회선과 백업 회선을 구분하는 설계에서 자주 활용됩니다.
4-4. IPv6 정적 라우트
IPv6도 동일한 원리로 관리됩니다. 다만 운영환경에서는 IPv4만 정상이고 IPv6 경로가 누락된 상태로 서비스가 부분 장애를 일으키는 경우가 있으므로, 듀얼스택 환경에서는 반드시 `ip -6 route`까지 함께 확인해야 합니다.
4-5. 저장된 경로 확인
이 명령은 connection profile 내부에 영구 저장된 경로를 확인하는 데 적합합니다. 반면 실제 패킷이 어떤 경로를 타는지는 `ip route get 목적지IP`로 다시 보는 편이 정확합니다. 즉, 프로필 확인과 커널 확인은 서로 다른 단계입니다.
5. Rocky Linux 8, 9, 10 버전별 적용 전략
5-1. Rocky Linux 8 적용 전략
Rocky Linux 8에서는 `nmcli`를 기준으로 주소, 게이트웨이, DNS, 정적 라우트, 연결 재적용까지 대부분 일관되게 처리할 수 있습니다. 따라서 신규 구축에서는 가급적 `route-인터페이스` 파일 작성보다 `nmcli`를 중심으로 운영 문서를 통일하는 편이 적합합니다.
다만 CentOS 7 또는 RHEL 7 계열에서 이관된 서버라면 과거 문서가 ifcfg 스타일로 남아 있을 가능성이 높습니다. 이 경우 현재 적용 구조가 이미 NetworkManager profile로 바뀌었는지 먼저 확인하고, 파일 흔적만 남은 것인지 실제 반영 소스인지 분리해서 판단해야 합니다.
5-2. Rocky Linux 9 적용 전략
Rocky Linux 9는 keyfile 및 NetworkManager 중심 운영 기준이 더 명확합니다. 따라서 실무 표준서는 `nmcli`, `nmtui`, `ip`, `nmcli connection show` 계열 위주로 정리하는 편이 적절합니다.
이 버전대에서는 수동 파일 편집보다 connection profile 관점으로 접근하는 것이 훨씬 안정적입니다. 특히 운영 자동화 스크립트나 Ansible 역할 구성에서도 `nmcli` 중심이 이식성과 유지보수성 측면에서 유리합니다.
5-3. Rocky Linux 10 적용 전략
Rocky Linux 10 역시 최신 문서 기준으로 NetworkManager 중심 관리가 자연스럽습니다. 따라서 10 계열 신규 서버에는 레거시 파일 방식보다 connection profile만 유지하는 단순한 표준이 더 적합합니다.
즉, 버전이 올라갈수록 “수동 파일 직접 편집”보다 “NetworkManager 기반 선언적 구성”이 점점 더 실무 친화적입니다. 조직 차원에서는 Rocky 8부터 10까지 동일한 운영 절차로 묶는 편이 교육과 인수인계 측면에서 효율적입니다.
| 구분 | Rocky 8 | Rocky 9 | Rocky 10 |
|---|---|---|---|
| 신규 구축 권장 | `nmcli` | `nmcli` | `nmcli` |
| 레거시 파일 해석 필요성 | 높음 | 중간 | 낮음 |
| 문서 표준화 전략 | 구서버 호환 고려 | connection profile 기준 통합 | 최신 표준만 유지 |
6. 레거시 방식: route-인터페이스 파일과 ifcfg 계열
레거시 방식은 `/etc/sysconfig/network-scripts/route-인터페이스명` 파일에 정적 경로를 기술하는 방법입니다. 이 방식은 오래된 RHEL 계열 운영 경험이 있는 관리자에게는 익숙하지만, 최신 Rocky Linux 신규 구축에서는 우선순위가 떨어집니다. 그럼에도 불구하고 과거 서버 마이그레이션, 설정 비교, 장애 원인 분석에서는 여전히 매우 중요한 지식입니다.
6-1. IP 명령 인수 형식
각 줄이 하나의 경로를 의미합니다. 단순하고 직관적이기 때문에 사람이 읽고 검토하기 좋습니다. 다만 운영 자동화 체계와 결합하려면 파일 배포, 서비스 재적용, 현재 active profile과의 관계를 함께 관리해야 합니다.
6-2. 네트워크·넷마스크 지시문 형식
이 형식은 번호를 순차적으로 유지해야 합니다. 즉, `ADDRESS0` 다음에 `ADDRESS2`를 바로 쓰는 방식은 혼란을 만들 수 있으므로 권장되지 않습니다. 사람이 직접 편집할 때는 오타 가능성이 높아지므로, 운영 중에는 더 단순한 IP 인수 형식이 읽기와 검수에 유리한 경우가 많습니다.
7. 라우트 추가, 삭제, 수정, 검증 명령 상세
정적 라우팅 실무에서 중요한 것은 단순히 추가만 아는 것이 아니라, 삭제와 검증을 함께 표준화하는 것입니다. 운영 사고의 상당수는 “추가한 경로를 제거하지 못함”, “저장은 되었으나 커널에는 반영되지 않음”, “기존 라우트와 충돌함”에서 발생합니다.
7-1. nmcli 기반 삭제
삭제 시에는 추가할 때 사용한 경로 문자열을 동일하게 맞추는 것이 중요합니다. 문자열이 다르면 삭제가 실패하거나, 운영자가 삭제되었다고 오해할 수 있습니다.
7-2. 커널 선택 경로 확인
이 명령은 목적지 IP에 대해 실제 어떤 게이트웨이와 어떤 인터페이스, 어떤 출발지 주소를 선택하는지 보여줍니다. 따라서 단순히 `ip route` 목록을 보는 것보다 실제 통신 관점에서 훨씬 직접적인 검증 명령입니다.
7-3. 응답성 검증 명령
`ping`은 단순 도달성 확인에 적합하고, `tracepath` 또는 `traceroute`는 실제 경유 홉의 방향성을 보는 데 유리합니다. 다만 ICMP 차단 정책이 있는 환경에서는 `ping`만으로 라우팅 이상을 단정하면 안 되며, 서비스 포트 수준 검증과 함께 봐야 합니다.
| 검증 단계 | 명령 | 검증 목적 |
|---|---|---|
| 프로필 반영 확인 | `nmcli -f ipv4.routes connection show enp1s0` | 영구 저장 여부 확인 |
| 커널 반영 확인 | `ip route` | 실제 라우팅 테이블 확인 |
| 선택 경로 확인 | `ip route get 목적지IP` | 게이트웨이와 출발지 주소 선택 검증 |
| 통신 확인 | `ping`, `tracepath`, `traceroute` | 실제 도달성과 경로 가시화 |
8. 다중 NIC, 메트릭, 우선순위, 정책 기반 라우팅
정적 라우팅만으로 해결되지 않는 환경에서는 메트릭과 정책 기반 라우팅까지 함께 이해해야 합니다. 단일 NIC 서버에서는 목적지 라우트만으로 충분한 경우가 많지만, 다중 NIC 서버에서는 “어느 인터페이스에서 나갈 것인가”와 “어느 소스 IP를 사용할 것인가”가 함께 문제가 됩니다.
8-1. 메트릭 기반 우선순위
같은 목적지에 대해 두 개 이상의 경로가 있을 때 metric이 낮은 경로가 우선 사용됩니다. 따라서 주 회선 경로에는 낮은 metric, 백업 회선에는 높은 metric을 주는 방식으로 경로 우선순위를 설계할 수 있습니다.
8-2. 정책 기반 라우팅 개념
정책 기반 라우팅은 목적지뿐 아니라 소스 IP, 우선순위 규칙, 별도 라우팅 테이블을 조합해 경로를 결정하는 방식입니다. 예를 들어 한 서버가 두 개의 NIC를 가지고 있고, `10.0.2.50` 주소에서 나가는 트래픽만 보조 회선을 사용하게 하려면 일반 정적 라우트만으로는 부족하며 정책 규칙이 필요합니다.
8-3. 정책 기반 라우팅 예시
이 구조의 핵심은 별도 라우팅 테이블을 정의하고, 특정 소스 주소에서 발생한 트래픽만 그 테이블을 참조하도록 만드는 데 있습니다. 다중 ISP, 내부망과 인터넷망 분리, DMZ 응답 경로 강제, 특정 응용계 전용회선 사용 같은 환경에서 매우 유효합니다.
9. 실전 사례: 서버 운영 및 금융권 인프라 시나리오
9-1. 내부 백업망만 별도 게이트웨이 사용
운영망 기본 게이트웨이는 `192.168.1.1`이지만, 백업 장비가 위치한 `10.30.0.0/16` 대역은 백업 라우터 `192.168.1.254`를 통해서만 접근해야 하는 경우가 있습니다. 이때는 기본 게이트웨이는 유지한 채 특정 대역에만 정적 라우트를 추가하면 됩니다.
9-2. 특정 기관 연계망만 보조 회선 사용
대외 기관 연계 서버에서 주 회선은 일반 인터넷 트래픽을 유지하고, 특정 기관망 대역만 별도 게이트웨이로 보내야 하는 경우가 있습니다. 이 구조는 단순 목적지 기반 정적 라우트로 해결 가능하며, 서비스 영향 범위가 제한적이라는 장점이 있습니다.
9-3. 다중 NIC 서버에서 소스별 회선 분리
한 서버가 내부망 NIC와 외부 연동 NIC를 모두 가지고 있고, 특정 서비스 프로세스가 바인딩된 소스 IP에서만 외부 연계 회선을 사용해야 하는 경우가 있습니다. 이때는 일반 정적 라우트가 아니라 정책 기반 라우팅이 필요합니다. 그렇지 않으면 응답은 다른 NIC로 나가 비대칭 라우팅과 세션 실패가 발생할 수 있습니다.
9-4. 마이그레이션 서버의 레거시 라우팅 분석
CentOS 기반 구서버에서 Rocky Linux 8 또는 9로 올린 경우, `/etc/sysconfig/network-scripts/route-IFACE` 파일이 남아 있지만 현재 활성 연결은 NetworkManager profile일 수 있습니다. 이런 서버는 파일만 보고 판단하면 안 되며, 현재 커널 테이블과 connection profile을 동시에 확인해야 실제 동작을 이해할 수 있습니다.
10. 장애 대응 체크리스트와 운영 통제 포인트
정적 라우트 장애는 대부분 몇 가지 공통 원인으로 압축됩니다. 첫째, 잘못된 연결 프로필에 반영한 경우입니다. 둘째, 다음 홉 게이트웨이가 실제로 도달 불가능한 경우입니다. 셋째, 프로필에는 저장했지만 connection 재적용을 하지 않아 커널에 반영되지 않은 경우입니다. 넷째, 정책 기반 규칙과 기존 기본 라우트가 충돌하는 경우입니다.
| 증상 | 가능 원인 | 우선 조치 |
|---|---|---|
| 재부팅 후 라우트 소실 | `ip route add`만 사용하고 영구 반영 누락 | `nmcli -f ipv4.routes connection show`로 저장 여부 확인 후 영구 반영 |
| 설정 후 통신 불가 | 잘못된 다음 홉, 잘못된 인터페이스, 방화벽 정책 충돌 | `ip route get`, `ping 게이트웨이`, `tracepath`로 단계별 검증 |
| 정책 라우팅이 의도와 다름 | rule과 table 불일치, 우선순위 혼선 | `ip rule`, `ip route show table 번호` 확인 |
| 기본 게이트웨이 충돌 | DHCP 기본 경로와 수동 경로 중복 | 현재 프로필의 주소 방식과 gateway 설정 재검토 |
10-1. 권장 운영 절차
실무적으로 가장 안전한 방식은 다음 순서입니다. 첫째, 현재 상태를 백업합니다. 둘째, `ip route add`로 임시 테스트를 수행합니다. 셋째, 결과가 정상일 때만 `nmcli`로 영구 반영합니다. 넷째, `nmcli connection up` 후 `ip route get`과 서비스 수준 테스트로 검증합니다. 다섯째, 변경 기록과 롤백 명령을 함께 남깁니다.
