Tinyproxy में Listen, Bind और BindSame: कौन-सा पता जीतता है
Listen वह पता चुनता है जो ग्राहकों को स्वीकार करता है, Bind बाहर जाने वाले कनेक्शनों का स्रोत चुनता है। कोई भी रूट नहीं बिछाता, इसलिए मार्ग की अलग से जाँच करें।
प्रॉक्सी उत्तर देता है, अनुरोध पूरा होता है, और फिर भी गंतव्य अब भी लैन पता दर्ज करता है। प्रॉक्सी लॉग में कुछ भी गलत नहीं दिखता, और जो पंक्ति आपने बदली वही वह पंक्ति है जिसे बदलने को दस्तावेज़ ने कहा था। ऐसे होस्ट पर जिसके पास लैन पता और टनल पता दोनों हैं, तीन निर्देश तय करते हैं कि कौन-सा पता कहाँ दिखेगा, और उनमें से केवल एक बाहर जाने वाले पक्ष से संबंधित है। गलत क्रम में पढ़ने पर आप बिना कारण रूटिंग तालिका में पहुँच जाएँगे।
लक्षण: गंतव्य लैन पता देखता है
एक ग्राहक लैन पते पर प्रॉक्सी से जुड़ता है, और प्रॉक्सी गंतव्य की ओर अपना कनेक्शन खोलता है। वह दूसरा कनेक्शन कर्नेल के नियमों से स्रोत पता चुनता है, और डिफ़ॉल्ट रूप से वही होता है जो रूट खोज चुनती है। इसलिए गंतव्य होस्ट का प्राथमिक पता दर्ज करता है, भले ही हर बाइट प्रॉक्सी से गुज़री। अग्रेषण की दृष्टि से कुछ टूटा नहीं है, और इसीलिए प्रॉक्सी लॉग के पास इस पर कहने को कुछ नहीं है।
उस खराबी की दर्पण-छवि पहचानना आसान है: बाहर जाने वाले स्रोत को टनल पते पर पिन करें और लैन ग्राहक श्रोता तक पहुँचना ही बंद कर देंगे। वह संस्करण स्वयं घोषणा करता है, जबकि पहला काम कर रहे अनुरोध के पीछे छिपा रहता है। दोनों इसी से आते हैं कि एक निर्देश को ऐसे देखा जाए मानो वह दोनों प्रश्नों का उत्तर देता हो।
तीन निर्देश, तीन अलग पते
Listen उस स्थानीय पते का नाम देता है जो प्रॉक्सी ग्राहकों को स्वीकार करता है। Bind बाहर की ओर प्रॉक्सी जो कनेक्शन बनाता है उनके लिए स्रोत पता देता है, और BindSame उसे कहता है कि अभी स्वीकार किए गए कनेक्शन के स्थानीय पते का पुनः उपयोग करे। ये तीन अलग प्रश्न हैं, और एक पंक्ति केवल एक का उत्तर देती है। इन्हें मिलाना ही वह सामान्य कारण है कि बदलाव कुछ न करता हुआ लगता है।
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
स्थापित संस्करण के साथ आने वाली टिप्पणीयुक्त कॉन्फ़िगरेशन पढ़ें, क्योंकि डिफ़ॉल्ट और स्वीकार्य सिंटैक्स संस्करणों के बीच बदलते हैं। परियोजना का नमूना कॉन्फ़िगरेशन हर निर्देश को दूसरों के साथ दस्तावेज़ित करता है। उस फ़ाइल की डिस्क पर मौजूद फ़ाइल से तुलना करें, किसी दूसरे वितरण के लिए लिखी गाइड से नहीं।
श्रोता और बाहर जाने वाला स्रोत अलग-अलग सेट करें
ऐसा होस्ट लें जिसका लैन पता 192.168.50.10 और टनल पता 10.90.0.3 है। यदि लैन ग्राहकों को प्रॉक्सी तक पहुँचना है और उनके अनुरोध टनल से बाहर जाने हैं, तो ये दो स्वतंत्र निर्णय हैं और दोनों लिखने होंगे। नीचे का अंश ठीक यही कहता है, इससे अधिक कुछ नहीं।
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noयह पूरा कॉन्फ़िगरेशन नहीं है, इसलिए स्वीकृत पोर्ट, प्रमाणीकरण, ग्राहक पहुँच नियंत्रण और गंतव्य प्रतिबंध रखें। दोनों पते Tinyproxy के नेटवर्क नामस्थान के भीतर इस होस्ट के होने चाहिए, क्योंकि जिस Bind मान का प्रक्रिया स्वामी नहीं हो सकती वह शुरुआत में नहीं, कनेक्ट के समय असफल होता है। BindSame yes दूसरी नीति बताता है, जहाँ स्वीकृत कनेक्शन का स्थानीय पता ही बाहर जाने वाला स्रोत बन जाता है। वर्तमान संस्करणों में उस शाखा को Bind सूची पर प्राथमिकता है, और इसी तरह कॉन्फ़िगर किया गया स्रोत बिना किसी त्रुटि के गायब हो जाता है।
जिस मार्ग का स्रोत संकेत देता है उसकी जाँच करें
स्रोत पता चुनने से मार्ग नहीं बनता, इसलिए कर्नेल से पूछें कि वह उस स्रोत और उस गंतव्य के साथ क्या करेगा। जो खोज टनल इंटरफ़ेस का नाम लेती है वह न्यूनतम प्रमाण है, और जो लैन इंटरफ़ेस का नाम लेती है उसका अर्थ है कि स्रोत लिखे अनुसार काम नहीं कर सकता। खोज प्रसंगगत है: यह उस नामस्थान के लिए लागू नीति नियमों और तालिका का मूल्यांकन करती है। यह कनेक्शन नहीं है, और यह नहीं बताती कि नीचे का NAT सेवा को क्या प्रस्तुत करेगा।
ip -4 route get 203.0.113.25 from 10.90.0.3उदाहरण में दस्तावेज़ीकरण पता लें और उसे उस सेवा से बदलें जिसे जाँचने की आपको अनुमति है। जब प्रॉक्सी कंटेनर में हो तो खोज प्रॉक्सी के नामस्थान के भीतर चलाएँ, क्योंकि होस्ट के नियम वे नियम नहीं हैं जो प्रक्रिया देखती है। जब इच्छित टनल मार्ग न हो तो प्रॉक्सी होस्ट पर गंतव्य-विशिष्ट नियम जोड़ने के बजाय नेटवर्क के स्वामी से उसे ठीक करवाएँ। खोज सफल होने के लिए होस्ट रूट साफ़ न करें और सर्वर द्वारा भेजे गए रूट बंद न करें, भले ही किसी पुरानी गाइड ने ऐसा किया हो, क्योंकि ऐसे बदलाव एक प्रॉक्सी मार्ग ठीक करने के लिए पूरे होस्ट के स्वीकृत VPN व्यवहार को हिला देते हैं।
गंतव्य पर स्रोत की पुष्टि करें
स्रोत वहाँ पढ़ें जहाँ अनुरोध पहुँचता है, वहाँ नहीं जहाँ से निकलता है। गंतव्य का अनुप्रयोग लॉग, या उसके सामने का एज उपकरण, वह पता दर्ज करता है जो उसने वास्तव में देखा, जबकि प्रॉक्सी केवल अपना इरादा बता सकता है। बदलाव के बाद इच्छित श्रोता से एक नया अनुरोध करें, क्योंकि कैश में रखा कनेक्शन नए बंधन के बारे में कुछ सिद्ध नहीं करता। फिर दर्ज पते की तुलना उस पते से करें जो आपने सेट किया।
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl केवल ट्रैफ़िक जनरेटर है; जाँच के योग्य पता वही है जो दूर के पक्ष ने दर्ज किया, न कि वह सहकर्मी जिससे curl संयोगवश जुड़ा। यदि दोनों मेल न खाएँ तो तय करें कि अंतर स्रोत-चयन से आ रहा है या आगे के रूपांतरण से, क्योंकि उन्हें अलग जगहों पर ठीक किया जाता है। पता बदलाव और प्रॉक्सी पुनःआरंभ साथ योजना में रखें, क्योंकि जिस पते का टनल अब स्वामी नहीं है उसे बाँधना पुनः कनेक्ट के बाद चुपचाप विफल होता है। DNS और IPv6 व्यवहार भी अलग से परिभाषित करें, क्योंकि ऊपर का IPv4 अंश दोनों में से किसी के बारे में कुछ सिद्ध नहीं करता।