पोर्ट चेकर कहता है खुला? Minecraft खिलाड़ी फिर भी क्यों नहीं जुड़ पाते

कोई पोर्ट जाँच चलाता है, खुला शब्द देखता है, और सर्वर को हल हुआ मान लेता है। उस परिणाम का असली अर्थ सीमित है: जाँचकर्ता की जगह से, उस पल, उस पते और पोर्ट पर एक TCP कनेक्शन स्वीकार हुआ था। यह Minecraft प्रोटोकॉल हैंडशेक, खाता प्रमाणीकरण, या यह कि सर्वर ने खिलाड़ी को किसी दुनिया में जाने दिया या नहीं, के बारे में कुछ नहीं कहता।

ये चार अलग परतें हैं, और इनमें से किसी भी एक में विफलता खिलाड़ी से वही वाक्य निकलवाती है: यह काम नहीं आया।

एक प्रोब केवल वही जाँचता है जो वह देख सकता है

TCP कनेक्शन तब पूरा होता है जब दोनों पक्ष तीन-तरफा हैंडशेक पूरा करते हैं, जो खेल की जानकारी के सबसे नीचे होता है। प्रोब बताता है कि एक श्रोता मौजूद था और उसने अपने नेटवर्क स्थान से जवाब दिया। वह आपको यह नहीं बता सकता कि श्रोता ही खेल है, क्योंकि कोई भी प्रक्रिया पोर्ट बाँध सकती है और कनेक्शन स्वीकार कर सकती है।

स्थान का महत्व परिणाम जितना ही है। सार्वजनिक इंटरनेट पर एक जाँचकर्ता एक नेटवर्क से एक रास्ता जाँचता है। ऑपरेटर जो जाँचकर्ता उसी नेटवर्क के अंदर से चलाता है, वह पूरी तरह दूसरा रास्ता जाँचता है, और वहाँ का सकारात्मक परिणाम दूर के खिलाड़ी के अनुभव के बारे में लगभग कुछ नहीं कहता। दो अलग प्रदाताओं पर दो अलग जाँचकर्ता उन कारणों से असहमत भी हो सकते हैं जिनका आपके सर्वर से कोई संबंध नहीं है।

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

सॉकेट और खिलाड़ी के बीच चार परतें

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

Java Edition का चूक पोर्ट 25565 है, लेकिन ऑपरेटर कोई दूसरा बाहरी पोर्ट प्रकाशित करके उसे अंदर फ़ॉरवर्ड कर सकता है, इसलिए खिलाड़ी जो संख्या लिखता है वह ज़रूरी नहीं कि सर्वर जो संख्या देखता है वही हो। गलत बाहरी पोर्ट पर लक्ष्यित जाँचकर्ता सर्वर के पूरी तरह स्वस्थ रहते हुए बंद बताता है, और यह इस पूरे क्षेत्र में सबसे आम झूठा अलार्म है।

नाम पोर्ट के ऊपर एक और कदम जोड़ते हैं। यदि खिलाड़ी कोई होस्टनाम लिखता है, तो रिज़ॉल्यूशन को प्रकाशित पता लौटाना होता है, और नेटवर्क के अंदर की मशीन पर यह उसकी जगह निजी पता लौटा सकता है। यह फ़ायरवॉल की विफलता नहीं है और पोर्ट फ़ॉरवर्डिंग की कोई मात्रा इसे नहीं बदलेगी।

अंदर का खिलाड़ी अलग रास्ता क्यों लेता है

उसी LAN पर या उस LAN तक पहुँचने वाले VPN पर बैठा खिलाड़ी अंदर से सार्वजनिक पते तक पहुँचने की कोशिश करता है। अनुरोध राउटर के बाहरी पते पर जाता है और राउटर को उसे वापस अंदर अनुवादित करना होता है, जिसे आम तौर पर hairpinning या NAT परावर्तन कहा जाता है। इसके लिए आगे का अनुवाद और लौटने का रास्ता दोनों मेल खाने चाहिए, और कई उपभोक्ता राउटर इसे बिल्कुल लागू नहीं करते।

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

दो ईमानदार सुधार और एक बुरी आदत है। अच्छे विकल्प हैं अंदर के खिलाड़ियों को निजी पता या split-DNS नाम इस्तेमाल करने देना जो अंदर से निजी पते पर रिज़ॉल्व होता है, या यदि सुविधा मौजूद है और ठीक व्यवहार करती है तो राउटर पर परावर्तन सक्षम करना। बुरी आदत है और पोर्ट खोलना या होस्ट फ़ायरवॉल बंद करना, जो उस अनुवाद को प्रभावित नहीं कर सकता जो राउटर ने कभी किया ही नहीं।

Netgate का NAT परावर्तन दस्तावेज़ बाहरी बनाम अंदरूनी अंतर और split-DNS विकल्प को अधिक विस्तार से बताता है। इसे तंत्र के वर्णन के रूप में पढ़ें, किसी विशेष VPN प्रदाता या राउटर द्वारा हर loopback प्रकार के समर्थन के वादे के रूप में नहीं।

हर दृष्टिकोण से साक्ष्य इकट्ठा करें

हर परीक्षण के लिए लिखें कि किसने चलाया, कहाँ से, किस समय, किस पते और पोर्ट के विरुद्ध, और सर्वर ने क्या लॉग किया। सर्वर कंसोल में स्पष्ट कारण के साथ खेल का अस्वीकरण उस कनेक्शन से अलग निष्कर्ष है जो कभी पहुँचा ही नहीं, और दोनों विपरीत दिशाओं में ले जाते हैं।

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