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 रेंज में ही बैठें; बिना ओवरलैप वाली योजना चुनें और किसी फ़ोरम पोस्ट ने ऐसा किया इसलिए टनल को फिर से क्रमांकित करने के बजाय उस ख़ास गेम के प्रतिबंध जाँचें।

अंत में दोनों नतीजे अलग रखें: होस्ट में शामिल हो सकते हैं या नहीं, और डिस्कवरी उत्तर ऐसा गंतव्य घोषित करता है या नहीं जिसे दूसरा खिलाड़ी सचमुच इस्तेमाल कर सके। पहले की पुष्टि किए बिना दूसरे को ठीक करना वही तरीका है जिससे लोग ऐसी समस्या के लिए ब्रिज बनाए रखते हैं जो कभी ब्रॉडकास्ट के बारे में थी ही नहीं।