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 परियोजना किनारों और सुपरनोड को ओवरले घटकों के रूप में प्रलेखित करती है। यह किनारे को अनुप्रयोग प्रॉक्सी नहीं बनाती, और कोई राउटिंग कॉन्फ़िगरेशन ऐसा प्रोटोकॉल हैंडलर नहीं जोड़ता जिसे किसी ने शुरू न किया हो।