Nebula punchy सेटिङहरू: कुनले तपाईंको NAT ठीक गर्छ

दुई पियरहरू दीपस्तम्भमार्फत एकअर्कालाई भेट्टाउँछन् र त्यसपछि सीधा मार्ग बनाउन असफल हुन्छन्, र पहिलो प्रवृत्ति सबै punchy विकल्प सक्रिय गर्नु हो। त्यो प्रवृत्तिले तीन परिवर्तन भएको कन्फिगरेसन बनाउँछ, कुन महत्त्वपूर्ण थियो भन्ने थाहा नभई। सेटिङहरू फरक प्रश्नको जवाफ दिन्छन्: एउटाले पहिलेदेखि भएको म्यापिङ कायम राख्छ, अर्कोले उल्टो दिशामा ह्यान्डशेक प्रयास गर्छ। कुनै पनि छुनुअघि तपाईंको प्रश्न कुन हो निर्णय गर्नुहोस्।

समयभन्दा अघि अन्त्यबिन्दु पुष्टि गर्नुहोस्

अपेक्षित ठेगानामा कहिल्यै नदेखिने पियरलाई punch ट्युनिङले बचाउँदैन। दीपस्तम्भलाई पियरबारे के थाहा छ र पियरको आफ्नै कन्फिगरेसनले के घोषणा गर्छ हेर्नुहोस्, किनकि पुरानो bootstrap ठेगाना वा गल्तीले प्रकाशित निजी ठेगाना ले हरेक पार गर्ने उपायलाई निष्फल बनाउँछ। प्रमाणपत्र विश्वसनीय छ कि छैन पनि पुष्टि गर्नुहोस्, किनकि अविश्वसनीय पहिचानले NAT महत्त्वपूर्ण हुनुभन्दा धेरै अघि कुराकानी रोक्छ। त्यसपछि UDP दीपस्तम्भसम्म पुग्छ कि पुग्दैन जाँच्नुहोस्। समयका मानहरू पहिले होइन, अन्तिममा हेर्ने कुरा हुन्।

तपाईंले परीक्षण गरिरहेको अन्त्यबिन्दु जोडी लेख्नुहोस्, ताकि पछिका तुलनाले दुई अन्य मेसिन होइन, तीही पियरहरू प्रयोग गरून्।

punch म्यापिङ राख्छ, respond दिशा खोल्छ

punch विकल्पले पहिले नै सुरुङ भएको पियरको तल्लो तहको ठेगानामा नियमित रूपमा खाली प्याकेट पठाउँछ। यसको उद्देश्य भव्य छैन: स्थिति भएको NAT वा फायरवाललाई सीधा मार्ग निर्भर रहेको म्यापिङको म्याद सक्न दिँदैन। respond विकल्पले दीपस्तम्भ सूचनामा के हुन्छ परिवर्तन गर्छ, होस्टलाई आफूसम्म पुग्न खोज्ने पियरतर्फ उल्टो ह्यान्डशेक प्रयास गर्न बाध्य बनाउँछ। यी फरक असफलता शैली भएका फरक संयन्त्र हुन्।

सीधा मार्ग काम गरेर पछि क्षीण हुन्छ भने punch छान्नुहोस्। मार्ग एउटा दिशामा कहिल्यै बन्दैन भने respond छान्नुहोस्। दुवै सक्रिय गरेर आशा गर्नु भनेको पाँच मिनेटको सुधारलाई एक हप्ताको ट्युनिङमा बदल्नु हो।

ढिलाइले कहिले भन्ने निर्णय गर्छ, हुन्छ कि भन्ने होइन

ढिलाइका मानहरूले समय सार्छन्: एउटा सूचनापछि पठाइने प्याकेटमा लागू हुन्छ, अर्को उल्टो ह्यान्डशेक प्रयासमा। कुनैले पनि रोकिएको दिशालाई काम गर्ने बनाउँदैन। दुवै एकैचोटि बदल्दा तपाईं गर्न लागेको तुलना नष्ट हुन्छ।

संयन्त्र ठीक नहुँदासम्म तिनीहरूलाई छोड्नुहोस्। त्यसपछि एउटा समायोजन गर्नुहोस्, र पुरानो मान लेखेर राख्नुहोस्।

जब रिले नै इमानदार उत्तर हो

केही NAT संयोजनहरूले समय जसरी मिलाए पनि सीधा मार्ग समर्थन गर्न सक्दैनन्। दुवैतर्फ सममितीय NAT, वा नमागिएको आगमन ट्राफिक पूर्ण रूपमा फ्याँक्ने फायरवालले छेड्न केही बाँकी राख्दैन।

पुग्न सकिने ठेगाना भएको रिले नोडले ती पियरहरूलाई पार गर्ने सफलतामा निर्भर नहुने मार्ग दिन्छ। यसले त्यो नोडबाट ब्यान्डविथ खर्च गर्छ, त्यसैले यो बाटो छल्ने होइन, क्षमताको निर्णय हो। रिले जानाजान कन्फिगर गर्नुहोस् र पियरहरू त्यहाँ पुग्न सक्छन् कि जाँच्नुहोस्, किनकि आफै कठिन NAT पछाडि रहेको रिलेले केही बदल्दैन। त्यसपछि त्यो जोडीका लागि punch सेटिङ ट्युन गर्न छोड्नुहोस्, किनकि सीधा मार्ग कहिल्यै आउने थिएन।

असफल जोडी निष्क्रिय रहेपछि परीक्षण गर्नुहोस्

टुटेको अवस्था पुनः उत्पादन गर्नुहोस्: जोडीलाई त्यही अन्तरालमा निष्क्रिय राख्नुहोस्, वा पहिले असफल हुने ह्यान्डशेक क्रम दोहोर्याउनुहोस्। त्यसपछि दीपस्तम्भमा अनुरोध होइन, ती दुई पियरबीच एप्लिकेसन चलाउनुहोस्। दीपस्तम्भको जवाफले नियन्त्रण मार्ग प्रमाणित गर्छ, डेटा मार्गबारे केही भन्दैन।

कुन सेटिङ बदलियो, समय, र सीधा मार्ग आयो कि ट्राफिक रिलेमै रह्यो लेख्नुहोस्। रह्यो भने जवाफ रिले र क्षमताको टिप्पणी हो, र त्यो पूर्ण रूपमा राम्रो नतिजा हो। आयो भने अर्को प्रश्न यो हो कि यो एक घण्टाको निष्क्रियता सहन्छ कि, किनकि क्षीण हुने म्यापिङ नै punch हुनुको कारण भएको समस्या हो।