Minecraft VPN मार्फत: सर्भर सूचीमा कुन ठेगाना जान्छ?
VPN अन्त्य बिन्दुले सुरुङ बनाउँछ; खेललाई होस्टको निजी ठेगाना र पोर्ट चाहिन्छ। भूमिकाहरूलाई ठेगानासँग जोड्नुहोस्, त्यसपछि श्रोता, मार्ग र होस्ट नियम जाँच्नुहोस्।
Minecraft को सर्भर सूचीमा VPN अन्त्य बिन्दु टाइप गर्नु तार्किक लाग्छ र हरेक पटक असफल हुन्छ, किनकि त्यो ठेगानाले सुरुङ अन्त्य गर्छ, खेल होस्ट गर्दैन। त्यही VPN मा जोडिएको खेलाडीसँग पहिले नै खेलको होस्टसम्म मार्ग छ, त्यसैले प्रविष्टिले होस्ट र खेल सुन्ने पोर्ट बताउनुपर्छ। यी दुई सच्याएपछि बाँकी समस्या सामान्य सेवा-पहुँच हो, जुन पहिलो हेर्दा लाग्नेभन्दा धेरै छोटो जाँच सूची हो।
दुई ठेगाना, दुई काम
एउटा ठेगाना सार्वजनिक पूर्वाधार हो: सहकर्मीहरूबीच इन्क्रिप्ट गरिएका प्याकेट बोक्ने यातायात अन्त्य बिन्दु। अर्को समर्पित सर्भर चलाउने मेसिनको निजी ठेगाना हो। ती परस्पर फेर्न मिल्दैन, र एउटालाई अर्कोले बदल्दा जडान अस्वीकृत हुन्छ वा फायरवाल समस्या जस्तो देखिने समय सकिन्छ।
| Role | Address | Where it belongs |
|---|---|---|
| Public transport endpoint | 203.0.113.40 | VPN client configuration, never the game |
| Game host on the VPN | 10.60.0.20 | Server address field, with the port |
| Player peer | 10.60.0.30 | Assigned by the tunnel, nothing to type |
पूर्वनिर्धारित पोर्टसँग, खेलाडीले 10.60.0.20:25565 टाइप गर्छ र अरू केही होइन। Mojang को Java सर्भर डाउनलोड पृष्ठले 25565 लाई पूर्वनिर्धारित भन्छ, र पोर्ट परिवर्तन गर्ने सर्भर सञ्चालकलाई पुरानो ट्युटोरियलबाट शंका गर्नुभन्दा विश्वास गर्नुपर्छ।
त्यो ठेगानालाई साँचो सेवा बनाउनुहोस्
पुग्न सकिने ठेगाना आवश्यक छ र पर्याप्त छैन। समर्पित सर्भर चलिरहेको हुनुपर्छ, खेलाडीको क्लाइन्टले चलाउने संस्करणसँग मिल्नुपर्छ, र सुरुङले पुर्याउन सक्ने ठेगानामा सुन्नुपर्छ। केवल loopback मा बाँधिएको प्रक्रिया कसैले मेसिनमा अर्को ठेगाना थपेको कारणले पुग्न सकिने हुँदैन।
फायरवाल छुनुअघि श्रोता पुष्टि गर्नुहोस्:
ss -lntp | grep 25565
nc -vz 10.60.0.20 25565पहिलो लाइनले प्रक्रिया वास्तवमा केमा बाँधियो देखाउँछ, र दोस्रोले सहकर्मीले TCP हात मिलाउने कार्य पूरा गर्न सक्छ कि सक्दैन देखाउँछ। जब बन्धन 127.0.0.1 हुन्छ, VPN कन्फिगरेसनको कुनै पनि मात्राले नतिजा बदल्दैन, र यही एउटा विवरणले «VPN बिग्रियो» भन्ने अचम्मलाग्दो संख्याका रिपोर्ट व्याख्या गर्छ।
सहकर्मी नीति, फायरवाल र फर्कने मार्ग
श्रोतामाथि दुई अनुमति प्रश्न छन्। VPN सहकर्मी कन्फिगरेसनले दुई सहकर्मीबीचको ट्राफिकलाई अनुमति दिनुपर्छ, र खेल होस्टको फायरवालले त्यो सहकर्मीबाट खेलको पोर्ट स्वीकार गर्नुपर्छ। दुवैलाई खेल सेवा र अधिकृत सहकर्मीमा सीमित राख्नुहोस्, होस्टको फायरवाल बन्द गर्नुको सट्टा, जसले दुई लाइनको नियमलाई धेरै ठूलो समस्यासँग साट्छ। साँघुरा नियमहरू पनि यसको एउटै संस्करण हुन् जुन एक अनुच्छेदको औचित्य बिना सुरक्षा समीक्षा पार गर्छ।
त्यसपछि सम्झनुहोस् सफल ping ले के प्रमाणित गर्छ। VPN गेटवेसम्म पुग्नु, वा खेल होस्टबाट जवाफ पाउनु, ICMP ले मार्ग पार गरेको मात्र देखाउँछ। खेल जडानका लागि विशेष पोर्ट दुवै दिशामा खुला हुनुपर्छ, र फर्कने मार्ग बाहिर जाने मार्गजत्तिकै महत्त्वपूर्ण छ।
सर्भर गेटवे पछाडि हुँदा
माथिको उदाहरणमा खेल सर्भर सहकर्मी हो, जसले ठेगाना योजना सरल राख्छ। यदि सर्भर त्यसको सट्टा VPN गेटवे पछाडिको LAN मा छ भने, खेलाडीलाई सर्भरको मार्गनिर्देशनयोग्य निजी ठेगाना चाहिन्छ, गेटवेमा त्यो LAN का लागि अगाडि पठाउने कन्फिगर गरिएको हुनुपर्छ, र LAN होस्टलाई सुरुङको क्लाइन्टतर्फ फर्कने मार्ग चाहिन्छ। फर्कने मार्ग छुट्यो भने हात मिलाउने कार्य आधा बाटोमा मर्छ, जुन तीनमध्ये सबैभन्दा भ्रमित पार्ने असफलता हो।
यो टोपोलोजीको नक्कल गर्न उदाहरणको सहकर्मी ठेगाना अर्को मेसिनमा प्रतिलिपि नगर्नुहोस्। उदाहरणका ठेगानाले भूमिका वर्णन गर्छन्, र एउटा ठेगाना दुई भूमिकामा पुनः प्रयोग गर्दा मार्गनिर्देशनले समाधान गर्न नसक्ने ओभरल्याप बन्छ।
खोज, खाता र के बदल्नु हुँदैन
स्वचालित LAN खोज घोषणाहरूमा बनेको सुविधा हो। मार्गनिर्देशित VPN ले ती प्रसारण बोक्नु पर्दैन, त्यसैले LAN सूचीमा प्रविष्टि नहुनुले स्पष्ट निजी ठेगाना काम गर्छ कि गर्दैन भन्नेबारे केही भन्दैन। ठेगाना टाइप गर्नुहोस्, त्यसपछि निर्णय गर्नुहोस्। जोडियो भने, खोजको अन्तराल दोष होइन, प्रयोगमा असुविधा हो, र जाँच गर्नुको सट्टा त्यसै गरी अभिलेख गर्न सकिन्छ।
खेलको सामान्य खाता प्रमाणीकरण र प्रवेश नीति पनि अक्षुण्ण राख्नुहोस्। काम गर्ने निजी मार्गले मार्ग दिन्छ, सदस्यता होइन, र एडाप्टर प्राथमिकताको कुनै पनि मिसावटले क्लाइन्टले प्रयोग गर्नुपर्ने गन्तव्य पहिचान गर्ने कामलाई प्रतिस्थापन गर्दैन।