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 सूची में प्रविष्टि न होना इस बारे में कुछ नहीं कहता कि स्पष्ट निजी पता काम करता है या नहीं। पता लिखें, फिर निर्णय लें। यदि जुड़ता है, तो खोज का अंतराल उपयोगिता की परेशानी है, खराबी नहीं, और जाँच करने के बजाय उसे ऐसे ही प्रलेखित किया जा सकता है।
खेल का सामान्य खाता प्रमाणीकरण और प्रवेश नीति भी अक्षुण्ण रखें। काम करने वाला निजी मार्ग मार्ग देता है, सदस्यता नहीं, और एडाप्टर प्राथमिकता की कोई भी अदला-बदली उस गंतव्य की पहचान की जगह नहीं ले सकती जो क्लाइंट को उपयोग करना चाहिए।