מדוע DNAT אל 127.0.0.1 דורש זהירות מיוחדת
הבינו את route_localnet בעת הפניית תעבורה חיצונית לרכיב פרוקסי הכרוך ל-loopback.
שירות מאזין על 127.0.0.1:1080. כלל DNAT מפנה תעבורה נכנסת לכתובת הזו, ובכל זאת החיבור נכשל. השירות יכול להיות תקין והכלל יכול להתאים: לכתובות loopback של IPv4 יש טיפול ניתוב מיוחד.
המשתנה route_localnet של לינוקס קובע אם כתובות 127/8 נחשבות לכתובות מאדים במהלך הניתוב. ברירת המחדל שומרת על גבול ה-loopback הרגיל. חריגה ברמת ממשק מסוים יכולה להיות רלוונטית לתכנון מכוון של הפניה מקומית.
זה מסביר מדוע כלל שעובד במחשב אחר עשוי להיות תלוי ב-sysctl שלא העתקתם. אבל זה אינו מצדיק הפעלת האפשרות בכל מקום.
הנחת האבטחה משתנה עם המסלול
כריכה ל-loopback משמשת לעתים קרובות מפני שלרכיב עזר אין אימות לקוח עצמאי. אם תעבורה המגיעה מממשק אחר יכולה להיות מנותבת אליו, כתובת הכריכה לבדה אינה מתארת עוד את הקהל הנגיש. הגבילו את מקורות הכניסה, היעד והפורט במערכת הכללים בפועל, כולל תעבורה שמצהירה על כתובות מקור או יעד של loopback היכן שרלוונטי.
סקרו את מרחב השמות של הרשת שמכיל את השירות. ה-loopback של מכולה אינו ה-loopback של המארח, ושינוי הגדרת ממשק במארח אינו יוצר מאזין במכולה באופן אוטומטי.
rp_filter עונה על שאלה אחרת בנוגע לאימות מסלול המקור. כיבויו באופן גלובלי אינו תחליף כללי להבנת ניתוב loopback. באופן דומה, ip_nonlocal_bind עוסק בכריכת sockets לכתובות לא מקומיות, ולא בהפיכת מסלול DNAT זה לנכון.
לבסוף, הפרוטוקול המופנה חייב להתאים למאזין. שליחת תעבורת HTTP או TLS גולמית לפורט SOCKS עדיין דורשת מתרגם; חריגת ניתוב אינה יכולה לספק את המשא ומתן החסר.