N2N ओव्हरले हा प्रॉक्सी नाही: दोन्ही कनेक्शन काढा

Firefox 127.0.0.1:8000 कडे निर्देश करतो, N2N किनारा सुरू आहे, पीअर त्याच्या ओव्हरले पत्त्यावर ping ला उत्तर देतो, आणि तरीही ब्राउझर सांगतो की प्रॉक्सीने कनेक्शन नाकारले। त्या साखळीत काहीही विसंगत नाही। ओव्हरले होस्टला खाजगी नेटवर्कवर पोहोचण्यायोग्य पत्ता देतो; तो प्रॉक्सी प्रोटोकॉल बोलणारी प्रक्रिया तयार करत नाही। ब्राउझर पीअरकडे मार्ग मागत नाही। तो स्थानिक लिसनर मागत आहे।

येथे दोन कनेक्शन गोंधळली आहेत, आणि ती वेगळी काढल्यास बहुतेक गोंधळ एका मिनिटात सुटतो।

दोन कनेक्शन, एक नाही

पहिले कनेक्शन ब्राउझरपासून loopback पोर्टवर ऐकणाऱ्या गोष्टीपर्यंत जाते। ते स्थानिक सॉकेट आहे, आणि त्याचा कोणी मालक नसल्यास एकही पॅकेट N2N पर्यंत पोहोचण्यापूर्वी कनेक्शन नाकारले जाते। दुसरे प्रॉक्सी प्रक्रियेपासून ती जे आणते त्या मूळापर्यंत जाते। तो मार्ग प्रॉक्सी होस्टच्या राउटिंग टेबलने निवडला जातो, आणि तो सामान्य अपलिंक, दुसरे टनेल किंवा ओव्हरलेशी काहीही संबंध नसलेला धोरण-मार्ग असू शकतो।

पीअरला ping करणे हे सिद्ध करते की ओव्हरले किनाऱ्याच्या पत्त्यांदरम्यान पॅकेट पोहोचवू शकतो। पोर्ट 8000 वरील लिसनरबद्दल ते काहीही सिद्ध करत नाही, आणि तो होस्ट मूळापर्यंत पोहोचू शकतो का याचेही नाही। वेगळे अपयश, वेगळी दुरुस्ती।

लिसनर कुठे राहिला पाहिजे

127.0.0.1 ला बांधलेला प्रॉक्सी जाणूनबुजून स्थानिक असतो: तो फक्त ज्या मशीनवर चालतो तिथूनच कनेक्शन स्वीकारतो। वैयक्तिक प्रॉक्सीसाठी हा योग्य डीफॉल्ट आहे आणि ओव्हरलेवर तो सामायिक करण्यासाठी चुकीचा आकार आहे। ओव्हरले पीअरना सेवा देण्यासाठी एकतर ओव्हरले इंटरफेसवर बाइंड पत्ता किंवा loopback कनेक्शन संपवून ते रिले करणारा फॉरवर्डिंग घटक आवश्यक आहे। कोणत्याही परिस्थितीत, सामायिक नेटवर्कवरील खुला प्रॉक्सी हे आमंत्रण असल्याने कोणते ओव्हरले स्रोत सेवा वापरू शकतात हे स्पष्ट धोरणाने ठरवले पाहिजे।

कॉन्फिगरेशन फाइलऐवजी सॉकेट यादीने प्रत्यक्ष बाइंड तपासा। ओव्हरले येण्यापूर्वी सुरू झालेला डेमन अजूनही अस्तित्वात नसलेल्या पत्त्याला बांधलेला असू शकतो।

localhost पीअर नाही

ब्राउझरच्या प्रॉक्सी फील्डमध्ये, localhost ब्राउझरच्या स्वतःच्या मशीनकडे निर्देश करतो। तो किनारा नाही, सुपरनोड नाही, आणि टनेलच्या दूरच्या टोकावरील होस्टही नाही। प्रॉक्सी दुसऱ्या पीअरवर चालत असल्यास, त्या पीअरचा पोहोचण्यायोग्य ओव्हरले पत्ता आणि पोर्ट फील्डमध्ये टाका, नंतर लिसनर तुमच्या किनाऱ्याच्या पत्त्यावरून कनेक्शन स्वीकारतो याची खात्री करा।

सुपरनोड किनाऱ्यांना एकमेकांना शोधण्यास मदत करतात; ते प्रॉक्सी सेवा नाहीत। सुपरनोड पत्त्याला प्रॉक्सी एंडपॉइंट मानल्यास तोच नकार मिळतो, शिवाय गोंधळाचे अतिरिक्त पाऊल।

मार्ग handshake करू शकत नाही

पत्ता बरोबर असला तरी, राउटिंग म्हणजे प्रॉक्सी करणे नाही। HTTP प्रॉक्सी कनेक्शन CONNECT विनंती किंवा निरपेक्ष स्वरूपाच्या विनंती ओळीने सुरू होते, आणि SOCKS प्रॉक्सी आवृत्ती व पद्धतीच्या वाटाघाटीने सुरू होते। राउटर किंवा ओव्हरले बाइट्स पुढे पाठवतो; तो त्या संदेशांचे विश्लेषण करत नाही किंवा तुमच्यासाठी पुढील कनेक्शन उघडत नाही। म्हणूनच ping आणि SSH साठी चालणारा मार्ग ब्राउझर प्रॉक्सीसाठी अयशस्वी होऊ शकतो: ब्राउझरला सहकार्य करणारी प्रक्रिया हवी, केवळ पोहोचण्यायोग्यते नाही।

ध्येय फक्त पीअरवरील सेवेपर्यंत पोहोचणे असेल, तर प्रॉक्सी सेटिंग काढा आणि सेवेचा ओव्हरले पत्ता थेट वापरा।

मर्यादा क्रमाने तपासा

ओव्हरले पत्ता उत्तर देतो याची खात्री करा, नंतर कॉन्फिगर केलेल्या पोर्टवर लिसनर आहे याची खात्री करा आणि त्याचा बाइंड पत्ता नोंदवा। एक नियंत्रित विनंती करा आणि प्रॉक्सीचा लॉग वाचा, जेणेकरून अपयश लिसनरवर आहे की पुढील आणण्यात हे कळेल। शेवटी, प्रॉक्सी होस्टचा मार्ग आणि मूळासाठी DNS धोरण तपासा।

N2N प्रकल्प किनारे आणि सुपरनोडची ओव्हरले घटक म्हणून नोंद करतो। तो किनाऱ्याला अनुप्रयोग प्रॉक्सी बनवत नाही, आणि कोणतेही राउटिंग कॉन्फिगरेशन कोणीही सुरू न केलेला प्रोटोकॉल हँडलर जोडत नाही।