Minecraft च्या सर्व्हर यादीत VPN एंडपॉइंट टाइप करणे तर्कसंगत वाटते आणि प्रत्येक वेळी अयशस्वी होते, कारण तो पत्ता सुरंग संपवतो, खेळ होस्ट करत नाही।त्याच VPN ला जोडलेल्या खेळाडूकडे खेळाच्या होस्टपर्यंत आधीच मार्ग आहे, म्हणून नोंदीने होस्ट आणि खेळ ज्या पोर्टवर ऐकतो तो नमूद करणे आवश्यक आहे।हे दोन बरोबर केले तर उर्वरित समस्या सामान्य सेवा-उपलब्धता आहे, पहिल्या दृष्टीक्षेपात वाटते त्यापेक्षा खूप लहान तपासणी यादी।

दोन पत्ते, दोन कामे

एक पत्ता सार्वजनिक पायाभूत सुविधा आहे: सहकाऱ्यांमध्ये कूटबद्ध पॅकेट वाहून नेणारा वाहतूक एंडपॉइंट।दुसरा म्हणजे समर्पित सर्व्हर चालवणाऱ्या मशीनचा खाजगी पत्ता।ते परस्पर बदलता येत नाहीत, आणि एकाच्या जागी दुसरा ठेवल्यास जोडणी नाकारली जाते किंवा फायरवॉल समस्येसारखा वाटणारा कालबाह्य होतो।

RoleAddressWhere it belongs
Public transport endpoint203.0.113.40VPN client configuration, never the game
Game host on the VPN10.60.0.20Server address field, with the port
Player peer10.60.0.30Assigned 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 यादीत नोंद नसणे हे स्पष्ट खाजगी पत्ता कार्य करतो का याबद्दल काहीही सांगत नाही।पत्ता टाइप करा, नंतर निर्णय घ्या।जोडणी झाल्यास, शोधातील तूट ही दोष नसून वापरण्याची अडचण आहे, आणि तपासण्याऐवजी ती तशीच नोंदवता येते।

खेळाचे सामान्य खाते प्रमाणीकरण आणि प्रवेश धोरणही अभंग ठेवा।कार्यरत खाजगी मार्ग मार्ग देतो, सदस्यत्व नाही, आणि अडॅप्टर प्राधान्यांची कोणतीही उलथापालथ क्लायंटने वापरायचे असलेले गंतव्य ओळखण्याची जागा घेत नाही।

संबंधित लेख