Nebula punchy सेटिंग्स: कौन सी आपका NAT ठीक करती है

दो पीयर लाइटहाउस के ज़रिए एक-दूसरे को ढूँढते हैं और फिर सीधा रास्ता बनाने में नाकाम रहते हैं, और पहली प्रवृत्ति हर punchy विकल्प चालू करने की होती है। वह प्रवृत्ति तीन बदलावों वाला कॉन्फ़िगरेशन बनाती है, बिना यह जाने कि कौन सा मायने रखता था। सेटिंग्स अलग-अलग सवालों के जवाब देती हैं: एक पहले से मौजूद मैपिंग बनाए रखती है, और दूसरी उलटी दिशा में हैंडशेक आज़माती है। किसी को भी छूने से पहले तय करें कि आपका सवाल कौन सा है।

समय से पहले एंडपॉइंट की पुष्टि करें

जो पीयर कभी अपेक्षित पते पर नहीं दिखता, उसे punch की ट्यूनिंग नहीं बचाएगी। देखें कि लाइटहाउस पीयर के बारे में क्या जानता है और पीयर का अपना कॉन्फ़िगरेशन क्या घोषित करता है, क्योंकि पुराना bootstrap पता या गलती से प्रकाशित निजी पता हर ट्रैवर्सल तरकीब को बेकार कर देता है। यह भी पुष्टि करें कि सर्टिफ़िकेट भरोसेमंद है, क्योंकि अविश्वसनीय पहचान NAT के मायने रखने से बहुत पहले बातचीत रोक देती है। फिर जाँचें कि UDP लाइटहाउस तक पहुँचता भी है या नहीं। समय के मान सबसे आख़िर में देखने की चीज़ हैं, पहले नहीं।

जिस एंडपॉइंट जोड़ी से आप परख रहे हैं उसे लिख लें, ताकि बाद की तुलनाएँ दो अन्य मशीनों के बजाय वही पीयर इस्तेमाल करें।

punch मैपिंग रखता है, respond दिशा खोलता है

punch विकल्प समय-समय पर खाली पैकेट उस पीयर के अंडरले पते पर भेजता है जिसके पास पहले से टनल है। इसका मक़सद बड़ा नहीं है: यह स्टेटफ़ुल NAT या फ़ायरवॉल को उस मैपिंग की अवधि पूरी होने से रोकता है जिस पर सीधा रास्ता टिका है। respond विकल्प बदलता है कि लाइटहाउस सूचना पर क्या होता है, और होस्ट को उस पीयर की ओर वापस हैंडशेक आज़माने पर मजबूर करता है जो उस तक पहुँचना चाहता है। ये अलग-अलग विफलता वाले अलग तंत्र हैं।

punch चुनें जब सीधा रास्ता काम करता है और बाद में क्षीण होता है। respond चुनें जब रास्ता एक दिशा में कभी नहीं बनता। दोनों चालू करके उम्मीद करना ही पाँच मिनट की मरम्मत को एक हफ़्ते की ट्यूनिंग बनाने का तरीका है।

देरी तय करती है कब, न कि क्या

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

तंत्र सही होने तक इन्हें छोड़ दें। फिर एक को समायोजित करें, और पुराना मान लिखकर रखें।

जब रिले ही सच्चा जवाब हो

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

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

नाकाम जोड़ी को निष्क्रिय रहने के बाद जाँचें

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

लिखें कि कौन सी सेटिंग बदली, समय, और क्या सीधा रास्ता आया या ट्रैफ़िक रिले पर ही रहा। रहा हो तो जवाब रिले और क्षमता का नोट है, और यह बिल्कुल अच्छा नतीजा है। आया हो तो अगला सवाल यह है कि क्या वह एक घंटे की निष्क्रियता झेलता है, क्योंकि क्षीण होती मैपिंग ठीक वही समस्या है जिसके लिए punch मौजूद है।