چرا DNAT به 127.0.0.1 نیازمند توجه ویژه است
route_localnet را هنگام هدایت ترافیک خارجی به مؤلفه پراکسی متصل به loopback درک کنید.
یک سرویس روی 127.0.0.1:1080 گوش می‌دهد. قاعده‌ای DNAT ترافیک ورودی را به آن نشانی می‌فرستد، اما اتصال شکست می‌خورد. سرویس می‌تواند سالم باشد و قاعده NAT هم تطبیق یابد: نشانی‌های loopback در IPv4 رفتار مسیریابی ویژه‌ای دارند.
route_localnet در لینوکس تعیین می‌کند که آیا نشانی‌های 127/8 در هنگام مسیریابی به‌عنوان نشانی‌های مریخی تلقی می‌شوند یا نه. مقدار پیش‌فرض آن مرز معمول loopback را حفظ می‌کند. استثنای مربوط به یک واسط مشخص می‌تواند برای طراحی عمدی تغییرمسیر محلی مرتبط باشد.
این توضیح می‌دهد که چرا قاعده‌ای کارآمد از دستگاهی دیگر ممکن است به sysctl وابسته باشد که شما کپی نکرده‌اید. اما این توجیهی برای فعال‌کردن این گزینه در همه‌جا نیست.
فرض امنیتی همراه با مسیر تغییر می‌کند
اتصال به loopback غالباً به این دلیل استفاده می‌شود که یک کمک‌کننده احراز هویت مستقل مشتری ندارد. اگر ترافیکِ رسیده از واسطی دیگر بتواند به آن مسیریابی شود، نشانی اتصال به‌تنهایی دیگر مخاطب دسترسی‌پذیر را توصیف نمی‌کند. منابع ورودی، مقصد و درگاه را در همان مجموعه‌قواعد واقعی محدود کنید، از جمله ترافیکی که نشانی مبدأ یا مقصد loopback را ادعا می‌کند در جایی که مربوط است.
فضای نام شبکه‌ای را که سرویس در آن است بازبینی کنید. loopback یک کانتینر همان loopback میزبان نیست و تغییر تنظیم واسط میزبان به‌طور خودکار شنونده‌ای در کانتینر ایجاد نمی‌کند.
rp_filter به پرسشی دیگر درباره اعتبارسنجی مسیر مبدأ پاسخ می‌دهد. خاموش‌کردن سراسری آن جایگزین عمومی درک مسیریابی loopback نیست. به همین ترتیب ip_nonlocal_bind به اتصال سوکت‌ها به نشانی‌های غیرمحلی مربوط است، نه به درست‌کردن این مسیر DNAT.
در پایان، پروتکل تغییرمسیر‌یافته باید با شنونده سازگار باشد. فرستادن ترافیک خام HTTP یا TLS به درگاه SOCKS همچنان به مترجم نیاز دارد؛ استثنای مسیریابی نمی‌تواند مذاکره مفقود را فراهم کند.