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 दायरामै हुनुपर्छ भन्ने कुनै नियम छैन; ओभरल्याप नभएको योजना छान्नुहोस् र कुनै फोरम पोस्टले त्यसो गर्यो भनेर टनेल पुनःनम्बर गर्नुको सट्टा सम्बन्धित खेलको प्रतिबन्ध जाँच्नुहोस्।

अन्तमा दुई नतिजा अलग राख्नुहोस्: होस्टमा सामेल हुन सकिन्छ कि र खोज जवाफले अर्को खेलाडीले साँच्चै प्रयोग गर्न सक्ने गन्तव्य घोषणा गर्छ कि। पहिलो पुष्टि नगरी दोस्रो सुधार्नु नै ब्रोडकास्टसँग कहिल्यै सम्बन्ध नभएको समस्याका लागि मानिसहरू ब्रिज धान्न पुग्ने बाटो हो।