OpenVPN वर रिकामी LAN गेम यादी? शोध मार्ग तपासा

दुसऱ्या खेळाडूच्या टनेल पत्त्यावर पिंग पाठवणे आणि त्याचा होस्ट केलेला गेम दिसणे या दोन वेगळ्या कामगिरी आहेत. लॉबीतील यादी सामान्यतः एकाच स्थानिक नेटवर्कसाठी लिहिलेल्या शोध देवाणघेवाणीवर अवलंबून असते, तर गेम सत्र हे पत्ता आणि पोर्टशी सामान्य जोडणी असते. रिकाम्या यादीला राउटिंग अपयश मानल्यास तुम्ही गरज नसलेल्या ब्रिजकडे जाल, म्हणून काहीही बदलण्यापूर्वी दोन्ही प्रश्न वेगळे करा.

सेशनमध्ये सहभागी होणे आणि ते शोधणे वेगळे करा

अपयशी सहभाग राउट, फायरवॉल नियम आणि ऐकणाऱ्या सेवेकडे निर्देश करतो. रिकाम्या यादीसह यशस्वी सहभाग शोधाकडे किंवा जाहिरातीत असलेल्या पत्त्याकडे निर्देश करतो. हे दोन निष्कर्ष पूर्णपणे वेगळ्या कामाकडे नेतात, आणि पहिला जाणीवपूर्वक प्रयत्न केल्याशिवाय तुम्ही त्यांच्यात फरक करू शकत नाही.

VPN संरचना स्पर्श करण्यापूर्वी निकाल लिहून ठेवा. ही संपूर्ण तपासणीतील सर्वात स्वस्त चाचणी आहे आणि ती डिझाइनची अर्धी जागा काढून टाकते. तुम्ही वापरलेला पत्ताही नोंदवा, कारण तो पुढील प्रत्येक चाचणीसाठी संदर्भबिंदू होईल. तुमच्या नोट्समध्ये ती ओळ नसल्यास पुढील तुलना फक्त अंदाज आहे.

टनेलला स्पर्श करण्यापूर्वी थेट सहभाग तपासा

गेम थेट कनेक्शनचा पर्याय देत असल्यास, होस्टचा टनेल पत्ता आणि गेमचा नोंदवलेला पोर्ट वापरा, आणि गेमचे स्वतःचे प्रमाणीकरण तसेच होस्टचे फायरवॉल नियम अशाच ठेवा. यशस्वी सहभाग समस्या शोधापर्यंत मर्यादित करतो. अपयशी सहभागाला अजूनही स्वतःची तपासणी हवी, आणि कोणताही रिले ती सुधारणार नाही.

शोध पोर्ट आणि सेशन पोर्ट एकच क्रमांक आहेत असे गृहीत धरू नका. गेम सामान्यतः एका UDP पोर्टवर जाहीर करतात आणि दुसऱ्यावर खेळाडू स्वीकारतात, आणि चुकीच्या पोर्टसाठी बनवलेला रिले रिकामीच राहणारी यादी देतो.

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

ब्रॉडकास्ट कुठे थांबतो ते समजून घ्या

राउट केलेले TUN टनेल पीअर्समध्ये IP पॅकेट वाहून नेते आणि प्रत्येक पीअरच्या नेटवर्कवर स्थानिक ब्रॉडकास्ट पुन्हा निर्माण करत नाही. मर्यादित ब्रॉडकास्ट पत्ता 255.255.255.255 तो उत्सर्जित करणाऱ्या इंटरफेसच्या आतच राहतो, आणि सबनेटकडे निर्देशित ब्रॉडकास्ट ही वेगळी गोष्ट आहे, राउटरना जाहिरातींनी भरून टाकण्याचा सर्वसाधारण परवाना नाही.

हे डिझाइनचे वैशिष्ट्य आहे, पर्यायाने टाकी लावायची खामी नाही. OpenVPN आणि त्याची client-to-client सेटिंग टनेलमधील पीअर रहदारी नियंत्रित करते आणि ती शोध रिले नाही, अनेक थ्रेडमध्ये याच उद्देशासाठी सुचवली जाते तरी. रिले हा स्वतःची संरचना आणि स्वतःचे अपयश मोड असलेला वेगळा घटक आहे. विद्यमान पर्याय हे आधीच समाविष्ट करतो हे गृहीत धरणे ही या तपासणीच्या अडकण्याची सर्वात सामान्य कारणे आहे.

मल्टिकास्ट शोधाला वेगळ्या पत्ता वर्गासह तीच समस्या आहे, आणि त्याला ब्रॉडकास्ट अपवादाऐवजी मल्टिकास्ट राउटिंग किंवा रिले हवा.

रिले न्याय्य असतो तेव्हा तो अरुंद ठेवा

स्वयंचलित शोध आवश्यक असल्यास, आधी प्रत्यक्ष देवाणघेवाण ओळखा: ब्रॉडकास्ट की मल्टिकास्ट, गंतव्य पत्ता, UDP पोर्ट, तो पाठवणारा इंटरफेस, आणि उत्तरातील पत्ता. या पाच तथ्यांपुरता मर्यादित प्रोटोकॉलला साजेसा रिले संपूर्ण Ethernet विभाग वाढवण्यापेक्षा खूपच अरुंद आहे.

पॅकेट न बदलता पुढे पाठवणे तरीही अपुरे ठरू शकते. पेलोड प्राप्तकर्त्याला अशा पत्त्याशी जोडण्यास सांगत असेल जिथे तो पोहोचू शकत नाही, तर रिले निरुपयोगी उत्तर देतो, म्हणून कोणताही रिले तयार होण्यापूर्वी गेमचा स्वतःचा इंटरफेस किंवा जाहीर पत्ता सेटिंग तपासली पाहिजे.

रिले तो आवश्यक असलेल्या इंटरफेस आणि पीअर्सपुरता मर्यादित करा, आणि उत्तरे विनंतीकर्त्याला कसे शोधतात ते ठरवा. असंबंधित ब्रॉडकास्टची पुनरावृत्ती इतर स्थानिक सेवा उघड करते आणि नंतर डीबग करणे कष्टप्रद असे लूप तयार करते.

डिझाइनला Ethernet आवश्यक असेल तेव्हाच ब्रिज करा

Ethernet फ्रेम्स TAP च्या आत प्रवास करतात, म्हणून TAP टनेल जाणीवपूर्वक ब्रिज केलेल्या ब्रॉडकास्ट डोमेनचा भाग असू शकते. फक्त dev tun चे dev tap मध्ये रूपांतर करणे तो ब्रिज बांधत नाही, सर्व्हर संरचना सुसंगत करत नाही आणि अनुप्रयोगाला नवीन इंटरफेस निवडायला लावत नाही. OpenVPN ब्रिजिंग मार्गदर्शक एका रिकाम्या लॉबीसाठी उपचार नाही, तर व्यापक मांडणी वर्णन करतो.

ब्रिजिंग पत्ता योजनाही सपाट करते, म्हणूनच हा निर्णय अधीरतेपलीकडील कारणास पात्र आहे. वेगळे असलेली दोन नेटवर्क एक होतात, आणि दोन्ही बाजूंची प्रत्येक सेवा दुसऱ्या बाजूचे ब्रॉडकास्ट पाहू लागते. तो परिणाम कोणीही तो सुरू करण्यापूर्वी बदल-नोंदीत असायला हवा. गेम क्लायंट 192.168 श्रेणीतच असावेत असा कोणताही नियम नाही; ओव्हरलॅप नसलेली योजना निवडा आणि फोरम पोस्टने तसे केले म्हणून टनेलचे पुनर्क्रमांकन करण्याऐवजी त्या विशिष्ट गेमचे निर्बंध तपासा.

शेवटी दोन्ही निष्कर्ष वेगळे ठेवा: होस्टमध्ये सहभागी होता येते का, आणि शोध उत्तर दुसऱ्या खेळाडूला खरोखर वापरता येईल असे गंतव्य जाहीर करते का. पहिल्याची पुष्टी न करता दुसरे सुधारणे म्हणजे ब्रॉडकास्टशी कधीही संबंध नसलेल्या समस्येसाठी लोक ब्रिज सांभाळतात तो मार्ग.