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 भाग दोन्हींपैकी कोणाबद्दलही काही सिद्ध करत नाही।