Linux Policy-Based Routing(PBR) 문제의 원인과 해결 방법

일반적인 Linux 서버는 목적지 IP 주소를 기준으로 하나의 Routing Table을 사용합니다. 하지만 서버에 여러 개의 네트워크 인터페이스가 있거나, ISP를 이중화하거나, VPN과 일반 인터넷을 동시에 사용하는 환경에서는 목적지뿐 아니라 출발지(Source IP), 인터페이스, 패킷의 특성에 따라 다른 경로를 사용해야 하는 경우가 있습니다.

이때 사용하는 기능이 Policy-Based Routing(PBR) 입니다. PBR 설정이 잘못되면 특정 IP만 통신되지 않거나, 응답 패킷이 다른 인터페이스로 나가 서비스 장애가 발생할 수 있습니다.

이번 글에서는 Linux에서 Policy-Based Routing 문제가 발생하는 원인과 확인 방법, 해결 방법을 실무 중심으로 알아보겠습니다.

Policy-Based Routing(PBR)이란?

Policy-Based Routing은 단순히 목적지 주소만 보는 것이 아니라 다양한 조건을 기준으로 다른 Routing Table을 사용하는 기능입니다.

구조는 다음과 같습니다.

Source IP 10.0.0.10
        │
        ▼
 Rule 100
        │
        ▼
Routing Table 100
        │
        ▼
Gateway A

Source IP 192.168.10.10
        │
        ▼
 Rule 200
        │
        ▼
Routing Table 200
        │
        ▼
Gateway B

하나의 서버가 여러 개의 회선을 사용할 때 자주 활용됩니다.

PBR 문제가 발생하는 주요 원인

대표적인 원인은 다음과 같습니다.

  • ip rule 설정 오류
  • Routing Table 누락
  • Gateway 설정 오류
  • Rule 우선순위(Priority) 충돌
  • 인터페이스 오류
  • Source IP 설정 오류
  • VPN Route 충돌
  • Metric 충돌
  • NetworkManager 설정 오류
  • 재부팅 후 설정 유실

실무에서는 Rule 누락Routing Table 설정 오류가 가장 많이 발생합니다.

1. Routing Rule 확인하기

현재 Rule을 확인합니다.

ip rule show

예시

0:      from all lookup local

100:    from 10.0.0.10 lookup 100

32766:  from all lookup main

Rule이 정상적으로 등록되어 있는지 확인합니다.

2. Routing Table 확인하기

특정 Routing Table을 확인합니다.

ip route show table 100

예시

default via 10.0.0.1 dev eth1

Routing Table이 비어 있다면 PBR은 동작하지 않습니다.

3. Rule 추가하기

Rule을 추가합니다.

ip rule add from 10.0.0.10 table 100

등록 후 다시 확인합니다.

ip rule show

4. Routing Table 추가하기

Table에 Route를 추가합니다.

ip route add default via 10.0.0.1 dev eth1 table 100

Rule만 있고 Route가 없으면 통신할 수 없습니다.

5. Source IP 확인하기

현재 IP를 확인합니다.

ip addr

Rule에서 지정한 Source IP가 실제 인터페이스에 존재하는지 확인합니다.

6. 실제 경로 확인하기

특정 Source IP를 기준으로 확인합니다.

ip route get 8.8.8.8 from 10.0.0.10

출력 예시

8.8.8.8

via 10.0.0.1

dev eth1

예상한 인터페이스를 사용하는지 확인합니다.

7. 인터페이스 확인하기

ip link

또는

ethtool eth1

인터페이스가 DOWN 상태라면 Rule이 정상이어도 통신되지 않습니다.

8. tcpdump 확인하기

패킷이 어느 인터페이스로 나가는지 확인합니다.

tcpdump -i eth1

또는

tcpdump -i eth0

응답 패킷이 다른 인터페이스로 나가는지 확인합니다.

9. 로그 확인하기

NetworkManager 로그를 확인합니다.

journalctl -u NetworkManager

또는

journalctl -k

라우팅 관련 오류를 확인합니다.

10. 영구 설정 확인하기

ip rule addip route add는 재부팅 후 사라집니다.

Ubuntu에서는 Netplan, RHEL 계열에서는 NetworkManager 또는 네트워크 설정 파일에 PBR 설정을 추가해야 합니다.

Policy-Based Routing 문제 점검 순서

실무에서는 다음 순서대로 확인하는 것이 좋습니다.

  1. Rule 확인
  2. Routing Table 확인
  3. Rule 추가 여부 확인
  4. Route 등록 확인
  5. Source IP 확인
  6. 실제 경로 확인
  7. 인터페이스 확인
  8. tcpdump 분석
  9. 로그 확인
  10. 영구 설정 확인

Policy-Based Routing 사용 시 주의사항

다음 사항을 확인해야 합니다.

  • Rule과 Routing Table은 함께 설정해야 한다.
  • Priority가 중복되지 않도록 관리한다.
  • Source IP가 실제 인터페이스에 존재해야 한다.
  • Gateway가 올바르게 설정되어야 한다.
  • 재부팅 후에도 유지되도록 영구 설정을 적용한다.
  • VPN이나 여러 ISP 환경에서는 Route 충돌 여부를 확인한다.

PBR은 설정이 복잡한 만큼 작은 실수 하나만으로도 특정 서비스만 장애가 발생하는 상황을 만들 수 있습니다.

Policy-Based Routing과 Static Route의 차이

항목Policy-Based RoutingStatic Route
기준출발지, 인터페이스, 정책목적지 네트워크
Routing Table여러 개 사용 가능일반적으로 Main Table 사용
활용 환경멀티 ISP, VPN일반 네트워크
구성 난이도높음낮음

Static Route는 목적지 중심, PBR은 정책 중심으로 동작한다는 점이 가장 큰 차이입니다.

자주 묻는 질문

Rule만 추가하면 동작하나요?

아니요. Rule이 참조하는 Routing Table에도 적절한 Route가 등록되어 있어야 합니다.

여러 개의 Routing Table을 사용할 수 있나요?

네. Linux는 여러 개의 Routing Table을 지원하며, 각각의 Rule이 서로 다른 Table을 참조하도록 구성할 수 있습니다.

PBR은 어떤 환경에서 많이 사용되나요?

멀티 ISP, VPN, 이중 회선, 서버 이중화, 보안망 분리, 클라우드 멀티 NIC 환경에서 많이 사용됩니다.

마무리

Policy-Based Routing은 복잡한 네트워크 환경에서 매우 강력한 기능입니다. ip rule, ip route, ip route get, tcpdump 등을 활용하면 대부분의 PBR 문제를 빠르게 분석할 수 있으며, Rule과 Routing Table을 함께 관리하고 영구 설정을 적용하는 것이 안정적인 운영의 핵심입니다.

댓글 남기기