رفع مشکل rp_filter و Asymmetric Routing روی VPS لینوکس؛ آموزش تشخیص و تنظیم صحیح

اگر روی VPS لینوکس چند مسیر خروجی، چند IP، Policy Routing یا دو کارت شبکه دارید و اتصال ورودی دیده می‌شود اما پاسخ برنمی‌گردد، یکی از مظنون‌های مهم rp_filter است. این قابلیت Reverse Path Filtering آدرس مبدأ بسته را با جدول مسیریابی بررسی می‌کند. در حالت Strict، اگر بهترین مسیر بازگشت به مبدأ از همان اینترفیس ورودی نباشد، بسته می‌تواند رد شود. مستندات رسمی Linux Kernel برای سناریوهای Asymmetric Routing استفاده از Loose Mode را توصیه می‌کند. در این راهنما قبل از هر تغییری مسیر را اثبات می‌کنیم، مقدار واقعی rp_filter را می‌خوانیم، تغییر موقت انجام می‌دهیم، نتیجه را با tcpdump و ip route Verify می‌کنیم و در صورت نیاز Rollback می‌کنیم.

rp_filter چیست و چرا در مسیر نامتقارن مشکل ایجاد می‌کند؟

rp_filter مخفف Reverse Path Filter است. کرنل هنگام دریافت یک بسته IPv4 بررسی می‌کند آیا مسیر برگشت به IP مبدأ با سیاست Reverse Path Validation سازگار است یا نه. طبق مستندات رسمی کرنل سه مقدار اصلی وجود دارد:

• 0: بررسی آدرس مبدأ غیرفعال است.
• 1 یا Strict: مسیر برگشت باید از همان اینترفیس ورودی بهترین مسیر باشد.
• 2 یا Loose: کافی است آدرس مبدأ از طریق یکی از مسیرهای موجود قابل دسترس باشد.

برای جلوگیری از IP Spoofing، Strict Mode در شبکه‌های ساده منطقی است؛ اما وقتی رفت و برگشت عمداً از مسیرهای متفاوت عبور می‌کنند، Strict Mode می‌تواند ترافیک سالم را هم Drop کند. نکته مهم دیگر این است که کرنل هنگام Source Validation مقدار مؤثر را با توجه به conf/all و اینترفیس مربوطه تعیین می‌کند؛ بنابراین بررسی فقط یک کلید کافی نیست.

اگر هدف شما سخت‌سازی عمومی تنظیمات شبکه کرنل است، راهنمای Kernel Hardening در لینوکس را نیز ببینید. در این مقاله عمداً فقط روی مشکل عملی Asymmetric Routing تمرکز می‌کنیم.

چه سناریوهایی معمولاً به Asymmetric Routing می‌رسند؟

این مشکل بیشتر در سرورهای تک‌مسیره دیده نمی‌شود. سناریوهای رایج عبارت‌اند از:

• VPS با دو کارت شبکه یا دو Gateway؛
• چند IP عمومی که با Policy Routing به جدول‌های جدا متصل شده‌اند؛
• Load Balancer، NAT Gateway یا فایروال بیرونی که مسیر رفت و برگشت را متفاوت می‌کند؛
• تونل، شبکه Overlay یا مسیر اختصاصی که پاسخ را از Interface دیگری می‌فرستد؛
• Multi-homing و اتصال هم‌زمان به دو شبکه.

نشانه کلاسیک: با tcpdump SYN ورودی را می‌بینید، اما اتصال کامل نمی‌شود یا پاسخ از Interface دیگری انتظار می‌رود و رفتار با خاموش‌کردن موقت یکی از مسیرها تغییر می‌کند.

پیش‌نیاز و احتیاط قبل از تغییر

قبل از دستکاری Sysctl مطمئن شوید یک Session مدیریتی دوم یا Console از پنل VPS دارید. تغییر اشتباه شبکه ممکن است SSH را قطع کند. تنظیم فعلی را ذخیره کنید:

mkdir -p ~/rp-filter-backup
sysctl net.ipv4.conf.all.rp_filter | tee ~/rp-filter-backup/all.txt
sysctl net.ipv4.conf.default.rp_filter | tee ~/rp-filter-backup/default.txt
ip -br link | tee ~/rp-filter-backup/interfaces.txt
ip rule show | tee ~/rp-filter-backup/ip-rule.txt
ip route show table all | tee ~/rp-filter-backup/routes.txt

اگر نام Interface را نمی‌دانید:

ip -br addr

در مثال‌های این مقاله از eth0 و eth1 استفاده می‌کنیم؛ روی سرور شما ممکن است نام‌هایی مثل ens3 یا enp1s0 باشد.

مرحله ۱: مقدار واقعی rp_filter را روی همه Interfaceها ببینید

ابتدا کلیدهای عمومی را بخوانید:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

سپس مقدار هر Interface را بررسی کنید:

for i in /proc/sys/net/ipv4/conf/*/rp_filter; do
  printf '%-55s ' "$i"
  cat "$i"
done

اگر روی Interface درگیر مقدار 1 می‌بینید، هنوز به معنی قطعی بودن علت نیست؛ فقط یک سرنخ قوی است. قبل از تغییر باید مسیر برگشت را بررسی کنید.

مرحله ۲: مسیر برگشت به Client را بررسی کنید

فرض کنید Client با IP نمونه 203.0.113.25 از طریق eth1 به سرور می‌رسد. مسیر برگشت را ببینید:

ip route get 203.0.113.25

خروجی ممکن است چیزی شبیه این باشد:

203.0.113.25 via 198.51.100.1 dev eth0 src 198.51.100.10

اگر بسته از eth1 وارد شده اما بهترین Route برگشت از eth0 است، دقیقاً سناریویی دارید که Strict Reverse Path Filtering می‌تواند با آن درگیر شود.

اگر Policy Routing دارید، فقط جدول main را نگاه نکنید:

ip rule show
ip route show table all

برای سرورهایی که از fwmark در Policy Routing استفاده می‌کنند، پارامتر src_valid_mark هم می‌تواند در محاسبه Reverse Path نقش داشته باشد؛ آن را بدون طراحی و تست روشن تغییر ندهید.

مرحله ۳: با tcpdump ثابت کنید بسته کجا می‌آید و پاسخ کجا می‌رود

روی سرور یک Capture محدود بگیرید:

sudo tcpdump -ni any host 203.0.113.25

یا فقط TCP پورت 443:

sudo tcpdump -ni any 'host 203.0.113.25 and tcp port 443'

هم‌زمان از Client اتصال را تکرار کنید. انتظار دارید Interface ورودی و در صورت وجود پاسخ خروجی را ببینید. اگر SYN وارد می‌شود اما پاسخ متناسب تولید نمی‌شود، مرحله بعدی تست موقت rp_filter است. اگر اصلاً بسته ورودی دیده نمی‌شود، مشکل قبل از سرور است و تغییر Sysctl کمکی نمی‌کند.

مرحله ۴: تغییر موقت و کم‌ریسک؛ ابتدا فقط Interface درگیر

به‌جای خاموش‌کردن سراسری Source Validation، در سناریوی مسیر نامتقارن ابتدا Loose Mode را روی Interface درگیر امتحان کنید:

sudo sysctl -w net.ipv4.conf.eth1.rp_filter=2

دوباره تست Client و tcpdump را اجرا کنید. اگر مشکل حل شد، هنوز کار تمام نشده است؛ مقدار عمومی را هم بررسی کنید:

sysctl net.ipv4.conf.all.rp_filter

طبق مستندات کرنل، مقدار مؤثر Reverse Path Validation از مقدارهای all و Interface تأثیر می‌گیرد. بنابراین اگر all=1 باشد، صرفاً قراردادن Interface روی 2 را بدون تست عملی کافی فرض نکنید. هدف این است که دقیقاً همان Scope لازم را اصلاح کنید، نه اینکه کورکورانه همه جا Source Validation را غیرفعال کنید.

مرحله ۵: اگر تست موفق بود، تنظیم را پایدار کنید

بعد از اینکه با Capture و تست واقعی مطمئن شدید Loose Mode مشکل را حل می‌کند، یک فایل اختصاصی بسازید:

sudo nano /etc/sysctl.d/99-asymmetric-routing.conf

نمونه برای Interface مشخص:

net.ipv4.conf.eth1.rp_filter = 2

سپس اعمال کنید:

sudo sysctl --system

و Readback بگیرید:

sysctl net.ipv4.conf.eth1.rp_filter
sysctl net.ipv4.conf.all.rp_filter

اگر نام Interface بعد از Reboot ممکن است عوض شود، قبل از Production درباره naming پایدار Interface مطمئن شوید.

آیا باید rp_filter را روی 0 بگذاریم؟

در اغلب سناریوهای Asymmetric Routing، اولین انتخاب Loose Mode یعنی 2 است، نه خاموش‌کردن کامل. مقدار 0 Source Validation را غیرفعال می‌کند و سطح محافظت در برابر برخی بسته‌های جعلی را پایین می‌آورد. فقط وقتی طراحی شبکه شما با Loose Mode هم سازگار نیست و کنترل Anti-Spoofing در لایه دیگری به‌صورت روشن انجام می‌شود، غیرفعال‌سازی کامل را با تحلیل ریسک در نظر بگیرید.

برای سرور اینترنتی، تغییر شبکه باید در کنار کنترل‌های پایه انجام شود. چک‌لیست امن‌سازی VPS لینوکس مکمل مناسبی برای این سناریو است.

تست نهایی بعد از اصلاح

بعد از اعمال تنظیم پایدار، فقط به «وصل شد» اکتفا نکنید. این موارد را بررسی کنید:

1. از هر شبکه‌ای که قبلاً مشکل داشت، TCP Connection را تکرار کنید.
2. با tcpdump مسیر ورودی و خروجی را Verify کنید.
3. ip rule show و Routeهای جدول‌های Policy Routing را دوباره بخوانید.
4. SSH، سرویس وب، مانیتورینگ و Health Checkهای اصلی را تست کنید.
5. بعد از Reboot کنترل‌شده، مقدار Sysctl را دوباره Readback بگیرید.

دستورهای سریع Verify:

sysctl net.ipv4.conf.eth1.rp_filter
ip rule show
ip route show table all
ss -lntup

خطاهای رایج در عیب‌یابی rp_filter

• خاموش کردن rp_filter قبل از اثبات مسیر: ممکن است مشکل واقعی Firewall، Route یا NAT باشد.
• بررسی فقط conf/all: مقدار Interface هم مهم است و باید Readback شود.
• استفاده از 0 به‌عنوان راه‌حل پیش‌فرض: معمولاً Loose Mode انتخاب محافظه‌کارانه‌تری برای مسیر نامتقارن است.
• نادیده گرفتن Policy Routing: جدول main تمام واقعیت را نشان نمی‌دهد؛ ip rule و tableهای دیگر را هم ببینید.
• تغییر هم‌زمان Route، Firewall و Sysctl: بعداً مشخص نمی‌شود کدام تغییر مشکل را حل کرده یا ایجاد کرده است.
• تست از داخل همان سرور: تست باید تا حد ممکن از همان Client یا مسیری انجام شود که مشکل را بازتولید می‌کند.

Rollback و Recovery

اگر بعد از تغییر رفتار شبکه بدتر شد، مقدار قبلی ثبت‌شده را برگردانید. برای نمونه اگر مقدار قبلی 1 بوده:

sudo sysctl -w net.ipv4.conf.eth1.rp_filter=1

فایل پایدار را نیز اصلاح یا حذف کنید:

sudo rm /etc/sysctl.d/99-asymmetric-routing.conf
sudo sysctl --system

سپس Readback بگیرید و Routeها را دوباره بررسی کنید. اگر SSH قطع شده، از Console پنل VPS وارد شوید و مقدار قبلی را برگردانید. به همین دلیل داشتن Console یا Session دوم قبل از تغییر مهم است.

چه زمانی مشکل از rp_filter نیست؟

اگر بسته ورودی در Capture دیده نمی‌شود، ابتدا Route بیرونی، Security Group، فایروال دیتاسنتر یا NAT را بررسی کنید. اگر بسته می‌آید و پاسخ هم روی Interface درست خارج می‌شود اما Client دریافت نمی‌کند، مشکل می‌تواند در مسیر برگشت بیرون از VPS باشد. اگر فقط یک Port خاص مشکل دارد، وضعیت Listener و Firewall محلی را نیز بررسی کنید:

ss -lntup
sudo nft list ruleset

روی سیستم‌هایی که هنوز از iptables استفاده می‌کنند، Ruleهای همان Firewall را با ابزار متناظر بررسی کنید.

جمع‌بندی

در سرورهای دارای Asymmetric Routing، مشکل را با «خاموش کردن همه چیز» حل نکنید. ابتدا Interface ورودی و Route برگشت را با tcpdump و ip route اثبات کنید، سپس مقدار rp_filter را Readback بگیرید و تغییر موقت و محدود به Loose Mode را تست کنید. فقط بعد از Verify آن را در /etc/sysctl.d/ پایدار کنید و مسیر Rollback را نگه دارید. این روش هم ریسک قطعی را کم می‌کند و هم مشخص می‌کند مشکل واقعاً Reverse Path Filtering بوده است یا لایه دیگری از Routing/Firewall.

اگر برای سناریوی چندمسیره به VPS نیاز دارید، مشخصات سرور مجازی وان‌سرور را می‌توانید بر اساس تعداد IP، شبکه و منابع موردنیاز پروژه بررسی کنید.

منبع فنی اصلی: Linux Kernel Documentation — IP Sysctl / rp_filter.