127.0.0.1 वर DNAT ला विशेष काळजी का लागते
बाह्य ट्रॅफिक लूपबॅकशी बांधलेल्या प्रॉक्सी घटकाकडे पुनर्निर्देशित करताना route_localnet समजून घ्या.
एक सेवा 127.0.0.1:1080 वर ऐकत आहे. DNAT नियम येणारे ट्रॅफिक त्या पत्त्याकडे पाठवतो, तरीही कनेक्शन अयशस्वी होते. सेवा निरोगी असू शकते आणि NAT नियम जुळू शकतो: IPv4 लूपबॅक पत्त्यांना राउटिंगमध्ये विशेष वागणूक मिळते.
लिनक्सचा route_localnet राउटिंगच्या वेळी 127/8 पत्त्यांना मंगळ पत्ते मानायचे की नाही हे नियंत्रित करतो. त्याचे मूलभूत मूल्य नेहमीची लूपबॅक सीमा राखते. विशिष्ट इंटरफेससाठीचा अपवाद जाणीवपूर्वक केलेल्या स्थानिक पुनर्निर्देशन रचनेसाठी संबंधित असू शकतो.
म्हणूनच दुसऱ्या मशीनवर चालणारा नियम तुम्ही कॉपी न केलेल्या sysctl वर अवलंबून असू शकतो. पण हे पर्याय सर्वत्र सुरू करण्याचे समर्थन करत नाही.
सुरक्षा गृहीत मार्गानुसार बदलते
लूपबॅक बाइंडिंग अनेकदा वापरली जाते कारण सहाय्यक घटकाकडे स्वतंत्र क्लायंट प्रमाणीकरण नसते. दुसऱ्या इंटरफेसवरून येणारे ट्रॅफिक तिथे राउट होऊ शकत असेल, तर फक्त बाइंड पत्ता आता पोहोचण्यायोग्य प्रेक्षकांचे वर्णन करत नाही. प्रत्यक्ष नियमसंचात प्रवेश स्रोत, गंतव्य आणि पोर्ट मर्यादित करा, तसेच संबंधित असेल तिथे लूपबॅक स्रोत किंवा गंतव्य पत्त्यांचा दावा करणारे ट्रॅफिकही समाविष्ट करा.
सेवा असलेल्या नेटवर्क नेमस्पेसचा आढावा घ्या. कंटेनरचा लूपबॅक होस्टचा लूपबॅक नाही, आणि होस्ट इंटरफेसचे सेटिंग बदलल्याने कंटेनरमध्ये स्वयंचलितपणे श्रोता तयार होत नाही.
rp_filter स्रोत-मार्ग पडताळणीबद्दल वेगळ्या प्रश्नाचे उत्तर देतो. तो जागतिक स्तरावर बंद करणे हे लूपबॅक राउटिंग समजून घेण्याचा सामान्य पर्याय नाही. त्याचप्रमाणे ip_nonlocal_bind सॉकेट्सना स्थानिक नसलेल्या पत्त्यांशी बांधण्याबद्दल आहे, हा DNAT मार्ग बरोबर करण्याबद्दल नाही.
शेवटी, पुनर्निर्देशित प्रोटोकॉल श्रोत्याशी जुळला पाहिजे. SOCKS पोर्टवर कच्चे HTTP किंवा TLS ट्रॅफिक पाठवण्यासाठी अजूनही अनुवादक लागतो; राउटिंग अपवाद गहाळ वाटाघाटी पुरवू शकत नाही.