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 अंशले दुवैमध्ये कसैबारे केही प्रमाणित गर्दैन।