127.0.0.1 पर DNAT को विशेष सावधानी की आवश्यकता क्यों है

एक सेवा 127.0.0.1:1080 पर सुनती है। एक DNAT नियम आने वाले ट्रैफ़िक को उस पते पर भेजता है, फिर भी कनेक्शन विफल हो जाता है। सेवा स्वस्थ हो सकती है और NAT नियम मेल भी खा सकता है: IPv4 लूपबैक पतों को राउटिंग में विशेष व्यवहार मिलता है।

लिनक्स का route_localnet तय करता है कि राउटिंग के दौरान 127/8 पतों को मंगल ग्रहीय पतों की तरह माना जाए या नहीं। इसका डिफ़ॉल्ट मान सामान्य लूपबैक सीमा बनाए रखता है। किसी विशिष्ट इंटरफ़ेस के लिए अपवाद जानबूझकर किए गए स्थानीय पुनर्निर्देशन डिज़ाइन के लिए प्रासंगिक हो सकता है।

यही कारण है कि किसी अन्य मशीन का काम करने वाला नियम उस sysctl पर निर्भर हो सकता है जिसे आपने प्रतिलिपि नहीं किया। पर यह इस विकल्प को हर जगह सक्षम करने का औचित्य नहीं देता।

सुरक्षा धारणा मार्ग के साथ बदलती है

लूपबैक बाइंडिंग अक्सर इसलिए प्रयोग होती है क्योंकि सहायक के पास स्वतंत्र क्लाइंट प्रमाणीकरण नहीं होता। यदि किसी अन्य इंटरफ़ेस से आने वाला ट्रैफ़िक वहाँ राउट किया जा सकता है, तो केवल बाइंड पता अब पहुँच योग्य दर्शकों का वर्णन नहीं करता। वास्तविक नियम-समुच्चय में प्रवेश स्रोत, गंतव्य और पोर्ट सीमित करें, तथा जहाँ प्रासंगिक हो वहाँ लूपबैक स्रोत या गंतव्य पतों का दावा करने वाला ट्रैफ़िक भी शामिल करें।

सेवा वाले नेटवर्क नामस्थान की समीक्षा करें। कंटेनर का लूपबैक होस्ट का लूपबैक नहीं है, और होस्ट इंटरफ़ेस की सेटिंग बदलने से कंटेनर में स्वतः श्रोता नहीं बनता।

rp_filter स्रोत-मार्ग सत्यापन के बारे में एक भिन्न प्रश्न का उत्तर देता है। इसे वैश्विक रूप से बंद करना लूपबैक राउटिंग समझने का सामान्य विकल्प नहीं है। इसी प्रकार ip_nonlocal_bind सॉकेट को गैर-स्थानीय पतों से बाँधने के बारे में है, इस DNAT मार्ग को सही बनाने के बारे में नहीं।

अंत में, पुनर्निर्देशित प्रोटोकॉल श्रोता के अनुरूप होना चाहिए। SOCKS पोर्ट पर कच्चा HTTP या TLS ट्रैफ़िक भेजने के लिए अब भी अनुवादक चाहिए; राउटिंग अपवाद अनुपस्थित बातचीत प्रदान नहीं कर सकता।