Nebula punchy सेटिंग्ज: कोणती तुमचे NAT दुरुस्त करते

दोन पीअर दीपस्तंभातून एकमेकांना शोधतात आणि नंतर थेट मार्ग बांधू शकत नाहीत, आणि पहिली प्रवृत्ती म्हणजे प्रत्येक punchy पर्याय सुरू करणे। ती प्रवृत्ती तीन बदल असलेली संरचना तयार करते आणि कोणता बदल महत्त्वाचा होता हे कळत नाही। सेटिंग्ज वेगळ्या प्रश्नांची उत्तरे देतात: एक आधीपासून असलेले मॅपिंग टिकवते, आणि दुसरे उलट दिशेने हँडशेक करण्याचा प्रयत्न करते। यापैकी कोणालाही स्पर्श करण्यापूर्वी तुमचा प्रश्न कोणता आहे ते ठरवा।

वेळेपूर्वी एंडपॉइंटची खात्री करा

अपेक्षित पत्त्यावर कधीही न दिसणारा पीअर punch ट्यूनिंगने वाचणार नाही। दीपस्तंभाला पीअरबद्दल काय माहीत आहे आणि पीअरची स्वतःची संरचना काय जाहीर करते ते तपासा, कारण जुना bootstrap पत्ता किंवा चुकून प्रकाशित झालेला खाजगी पत्ता प्रत्येक पार करण्याची युक्ती निष्फळ करतो। प्रमाणपत्र विश्वासार्ह असल्याचीही खात्री करा, कारण अविश्वासार्ह ओळख NAT महत्त्वाचे होण्याच्या खूप आधी संभाषण थांबवते। नंतर UDP दीपस्तंभापर्यंत पोहोचते का ते तपासा। वेळेची मूल्ये पहिल्यांदा नाही, शेवटी पाहावयाची गोष्ट आहे।

तुम्ही चाचणी करत असलेली एंडपॉइंट जोडी नोंदवा, जेणेकरून पुढील तुलना दोन वेगळ्या यंत्रांऐवजी त्याच पीअरचा वापर करतील।

punch मॅपिंग ठेवते, respond दिशा उघडते

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

थेट मार्ग काम करून नंतर क्षीण होत असेल तर punch निवडा। मार्ग एका दिशेने कधीही तयार होत नसेल तर respond निवडा। दोन्ही सुरू करून आशा धरणे म्हणजे पाच मिनिटांची दुरुस्ती आठवडाभराच्या ट्यूनिंगमध्ये बदलणे।

विलंब कधी हे ठरवतात, होईल का हे नाही

विलंबाची मूल्ये वेळ हलवतात: एक सूचनेनंतर पाठवल्या जाणाऱ्या पॅकेटला लागू होते, दुसरे उलट हँडशेकच्या प्रयत्नाला। दोन्हीपैकी कोणतेही अडवलेली दिशा कार्यरत करत नाही। दोन्ही एकाच वेळी बदलल्यास तुम्ही करणार असलेली तुलना नष्ट होते।

यंत्रणा बरोबर होईपर्यंत ती तशीच ठेवा। नंतर एक समायोजित करा, आणि जुने मूल्य लिहून ठेवा।

जेव्हा रिले हेच प्रामाणिक उत्तर असते

काही NAT संयोजने वेळ कसा ही लावला तरी थेट मार्गाला आधार देऊ शकत नाहीत। दोन्ही बाजूंनी सममितीय NAT, किंवा न मागितलेला आंतरिक रहदारी पूर्णपणे टाकून देणारा फायरवॉल, भेदण्यासाठी काहीही ठेवत नाही।

पोहोचण्यायोग्य पत्ता असलेला रिले नोड त्या पीअरना पार करण्याच्या यशावर अवलंबून नसलेला मार्ग देतो। तो त्या नोडमधून बँडविड्थ खर्च करतो, त्यामुळे हा मार्ग टाळणे नसून क्षमतेचा निर्णय आहे। रिले जाणीवपूर्वक संरचित करा आणि पीअर त्यापर्यंत पोहोचू शकतात का ते तपासा, कारण स्वतः कठीण NAT मागे असलेला रिले काहीही बदलत नाही। नंतर त्या जोडीसाठी punch सेटिंग्ज ट्यून करणे थांबवा, कारण थेट मार्ग कधीही येणार नव्हता।

अयशस्वी जोडी निष्क्रिय राहिल्यानंतर तपासा

तुटलेली अट पुन्हा तयार करा: जोडी त्याच अंतराने निष्क्रिय ठेवा, किंवा पूर्वी अयशस्वी होणारा हँडशेक क्रम पुन्हा करा। नंतर दीपस्तंभाला विनंती नाही, त्या दोन पीअरमध्ये अनुप्रयोग चालवा। दीपस्तंभाचे उत्तर नियंत्रण मार्ग सिद्ध करते, डेटा मार्गाबद्दल काहीही सांगत नाही।

कोणती सेटिंग बदलली, वेळ, आणि थेट मार्ग आला की रहदारी रिलेवरच राहिली हे नोंदवा। राहिली असेल तर उत्तर रिले आणि क्षमतेची नोंद आहे, आणि तो अगदी चांगला निकाल आहे। आला असेल तर पुढील प्रश्न असा की तो एक तासाची निष्क्रियता सहन करतो का, कारण क्षीण होणारे मॅपिंग हीच punch असण्याचे कारण असलेली अडचण आहे।