Linux Reverse Path Filtering(rp_filter) 문제의 원인과 해결 방법

Linux 서버를 운영하다 보면 Ping은 정상적으로 동작하지만 특정 인터페이스를 통한 통신만 실패하거나, Multi-Homing 환경에서 응답 패킷이 차단되는 문제가 발생할 수 있습니다. 특히 여러 개의 NIC를 사용하거나 VPN, Policy-Based Routing(PBR)을 사용하는 환경에서는 Reverse Path Filtering(rp_filter) 설정이 원인이 되는 경우가 많습니다.

Reverse Path Filtering은 IP 스푸핑(IP Spoofing) 공격을 방지하기 위한 커널 보안 기능입니다. 하지만 네트워크 구성이 복잡한 환경에서는 정상적인 패킷까지 차단하여 통신 장애를 일으킬 수 있습니다.

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

Reverse Path Filtering이란?

rp_filter는 수신한 패킷의 출발지 주소를 기준으로 역방향 경로가 동일한 인터페이스인지 확인하는 기능입니다.

동작 방식은 다음과 같습니다.

Packet 수신

↓

Source IP 확인

↓

Routing Table 조회

↓

동일 인터페이스인가?

↓

YES → 허용

NO → 패킷 차단

역방향 경로가 일치하지 않으면 Linux 커널이 패킷을 삭제합니다.

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

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

  • Multi-Homing 환경
  • Policy-Based Routing(PBR)
  • VPN 환경
  • Bonding 설정
  • 비대칭 라우팅(Asymmetric Routing)
  • 클라우드 멀티 NIC
  • VRF 환경
  • Static Route 충돌
  • 잘못된 Routing Table
  • 인터페이스 설정 오류

실무에서는 Multi-HomingPBR 환경에서 가장 많이 발생합니다.

1. 현재 rp_filter 설정 확인하기

전체 설정을 확인합니다.

cat /proc/sys/net/ipv4/conf/all/rp_filter

또는

sysctl net.ipv4.conf.all.rp_filter

출력 예시

0

2. 인터페이스별 설정 확인하기

특정 인터페이스를 확인합니다.

cat /proc/sys/net/ipv4/conf/eth0/rp_filter

또는

sysctl net.ipv4.conf.eth0.rp_filter

인터페이스마다 다른 값이 설정될 수 있습니다.

3. rp_filter 값의 의미

Linux에서는 다음 세 가지 값을 사용합니다.

의미
0비활성화
1Strict Mode
2Loose Mode

실무에서는 다음과 같이 사용합니다.

  • 일반 서버 → 1
  • Multi-Homing → 2
  • 특수 환경 → 0

4. 임시 변경하기

Loose Mode로 변경합니다.

sysctl -w net.ipv4.conf.all.rp_filter=2

특정 인터페이스만 변경하려면

sysctl -w net.ipv4.conf.eth0.rp_filter=2

을 사용합니다.

5. 영구 설정하기

설정 파일을 수정합니다.

vi /etc/sysctl.conf

추가합니다.

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2

적용합니다.

sysctl -p

6. Routing 확인하기

Routing Table을 확인합니다.

ip route

또는

ip rule

Policy-Based Routing을 사용하는 경우 Rule도 함께 확인해야 합니다.

7. 실제 경로 확인하기

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

ip route get 8.8.8.8 from 10.0.0.100

응답 경로가 예상과 일치하는지 확인합니다.

8. tcpdump 분석하기

패킷 흐름을 확인합니다.

tcpdump -i eth0

또는

tcpdump -i eth1

패킷은 들어오지만 응답이 나가지 않는다면 rp_filter를 의심할 수 있습니다.

9. 로그 확인하기

커널 로그를 확인합니다.

journalctl -k

또는

dmesg

rp_filter는 명확한 로그를 남기지 않는 경우가 많으므로 tcpdump와 함께 분석하는 것이 좋습니다.

10. 실제 테스트하기

설정을 변경한 후 다음 항목을 확인합니다.

  • Ping
  • SSH
  • HTTP
  • VPN
  • Multi-Homing
  • Policy Routing

서비스가 정상적으로 동작하는지 반드시 테스트합니다.

rp_filter 문제 점검 순서

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

  1. rp_filter 확인
  2. 인터페이스별 설정 확인
  3. Routing Table 확인
  4. Policy Rule 확인
  5. 실제 경로 확인
  6. tcpdump 분석
  7. 로그 확인
  8. 임시 변경 테스트
  9. 영구 설정 적용
  10. 서비스 테스트

rp_filter 사용 시 주의사항

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

  • 일반 서버에서는 Strict Mode가 보안상 유리하다.
  • Multi-Homing 환경에서는 Loose Mode를 많이 사용한다.
  • PBR 환경에서는 Rule과 함께 확인한다.
  • VPN 환경에서도 rp_filter 충돌이 자주 발생한다.
  • 설정 변경 후 반드시 서비스 테스트를 수행한다.
  • 모든 인터페이스 설정이 동일한지 확인한다.

rp_filter는 보안 기능이므로 특별한 이유 없이 비활성화(0)하는 것은 권장되지 않습니다.

rp_filter와 Firewall의 차이

항목rp_filterFirewall
목적출발지 경로 검증패킷 허용/차단
동작 계층커널 네트워크 스택Netfilter
기준Routing 정보IP, Port, Protocol
주요 역할IP 스푸핑 방지접근 제어

rp_filter는 패킷의 역방향 경로를 검사하고, Firewall은 패킷 자체를 허용하거나 차단하는 역할을 수행합니다.

자주 묻는 질문

Multi-Homing 환경에서는 rp_filter를 반드시 변경해야 하나요?

대부분의 경우 Loose Mode(2)를 사용하는 것이 좋습니다. Strict Mode에서는 정상적인 비대칭 라우팅도 차단될 수 있습니다.

rp_filter를 0으로 설정하면 어떤 문제가 있나요?

통신 문제는 줄어들 수 있지만 IP 스푸핑 공격에 대한 보호 기능이 약해질 수 있습니다. 특별한 이유가 없다면 0보다는 2를 사용하는 것이 일반적입니다.

설정을 변경했는데 재부팅 후 원래대로 돌아옵니다.

sysctl -w는 임시 설정입니다. /etc/sysctl.conf 또는 /etc/sysctl.d/에 설정을 추가하고 sysctl -p를 실행해야 영구적으로 유지됩니다.

마무리

Reverse Path Filtering은 Linux 커널의 중요한 보안 기능이지만, Multi-Homing이나 Policy-Based Routing 환경에서는 예상치 못한 네트워크 장애의 원인이 될 수 있습니다. sysctl, ip route, ip rule, tcpdump 등을 활용하면 대부분의 rp_filter 문제를 빠르게 진단할 수 있으며, 환경에 맞는 적절한 모드를 선택하는 것이 안정적인 운영의 핵심입니다.

댓글 남기기