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

यी चार फरक तह हुन्, र तीमध्ये कुनै एकमा असफलता भए खेलाडीबाट त्यही वाक्य आउँछ: यो चलेन।

प्रोबले देख्न सक्ने कुरा मात्र परीक्षण गर्छ

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

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

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

सकेट र खेलाडीबीच चार तह

जोडिने क्लाइन्टले वास्तवमा गर्ने क्रम कल्पना गर्नुहोस्। पहिले यसले ठेगाना समाधान गर्छ, त्यसपछि प्रकाशित पोर्टमा TCP जडान खोल्छ, त्यसपछि वार्ता र प्रमाणीकरणका लागि खेलकै प्रोटोकल बोल्छ, र अन्तमा सर्भरले त्यो पहिचानलाई संसारमा प्रवेश दिने हो कि भनेर निर्णय गर्छ। प्रत्येक तहको आफ्नै असफलता-हस्ताक्षर छ, र पहिलो मात्र पोर्ट चेकरलाई देखिन्छ।

Java Edition को पूर्वनिर्धारित पोर्ट 25565 हो, तर अपरेटरले अर्को बाह्य पोर्ट प्रकाशित गरी त्यसलाई भित्र फर्वार्ड गर्न सक्छ, त्यसैले खेलाडीले टाइप गर्ने संख्या सर्भरले देख्ने संख्या हुनु जरुरी छैन। गलत बाह्य पोर्टमा लक्षित चेकरले सर्भर पूर्ण रूपमा स्वस्थ हुँदा पनि बन्द भनी रिपोर्ट गर्छ, र यो यो सम्पूर्ण क्षेत्रमा सबैभन्दा सामान्य झुटो अलार्म हो।

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

भित्रको खेलाडी किन फरक बाटो लिन्छ

एउटै LAN मा वा त्यो LAN सम्म पुग्ने VPN मा रहेको खेलाडीले भित्रबाट सार्वजनिक ठेगानामा पुग्न प्रयास गर्छ। अनुरोध राउटरको बाह्य ठेगानामा जान्छ र राउटरले त्यसलाई फेरि भित्र अनुवाद गर्नुपर्छ, जसलाई सामान्यतया hairpinning वा NAT परावर्तन भनिन्छ। यो चल्नका लागि अगाडिको अनुवाद र फर्कने बाटो दुवै मिल्नुपर्छ, र धेरै घरायसी राउटरले यसलाई बिल्कुल लागू गर्दैनन्।

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

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

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

हरेक दृष्टिकोणबाट प्रमाण जम्मा गर्नुहोस्

हरेक परीक्षणका लागि कसले चलायो, कहाँबाट, कति बजे, कुन ठेगाना र पोर्टविरुद्ध, र सर्भरले के लग गर्यो भनी लेख्नुहोस्। सर्भर कन्सोलमा स्पष्ट कारणसहित खेलको अस्वीकृति कहिल्यै नपुगेको जडानभन्दा फरक निष्कर्ष हो, र दुवै विपरीत दिशातिर लैजान्छन्।

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

सम्बन्धित लेखहरू