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 ट्राफिक पठाउन अझै अनुवादक चाहिन्छ; मार्ग अपवादले छुटेको वार्तालाप दिन सक्दैन।