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 परियोजनाले किनारा र सुपरनोडलाई ओभरले घटकका रूपमा कागजात गर्छ। यसले किनारालाई अनुप्रयोग प्रोक्सी बनाउँदैन, र कुनै राउटिङ कन्फिगरेसनले कसैले सुरु नगरेको प्रोटोकल ह्यान्डलर थप्दैन।