मार्गित OpenVPN बोगद्यावरून नावांचा शोध का अयशस्वी होतो

यजमान पत्त्याने ping ला उत्तर देतो आणि नावाने प्रत्येक शोधात अयशस्वी होतो। बोगदा सुरू आहे आणि मार्ग अस्तित्वात आहे, त्यामुळे नैसर्गिक निष्कर्ष असा की VPN चुकीच्या पद्धतीने संरचित आहे। अधिक उपयुक्त निष्कर्ष असा की तो शोध कधीच मार्गण्यायोग्य नव्हता: मार्गित बोगदा unicast IP वाहतो, तर ती क्वेरी ब्रॉडकास्ट होती जी पलीकडे नसलेल्या सेगमेंटचा शोध घेत होती। स्तरांतील विसंगती दिसताच उपाय स्वतः खर्चाच्या क्रमाने लागतात।

गैरसमज: नावे अयशस्वी होतात म्हणून बोगदा तुटलेला आहे

लक्षण खात्रीलायक आहे कारण नावाच्या स्तरावरील सर्व काही कार्यरत आहे। पत्ते मार्गित होतात, इंटरफेस सुरू आहे, आणि समकक्ष ping ला उत्तर देतो। अयशस्वी झालेली गोष्ट अशी शोध-यंत्रणा आहे जिला बिंदू-ते-बिंदू दुव्यावरून कधीच मार्ग नव्हता, आणि हे तुटलेल्या बोगद्यापेक्षा वेगळे विधान आहे। या दोन विधानांचे विभाजन हाच निदानाचा मोठा भाग आहे।

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

उपायाचे नाव घेण्यापूर्वी अयशस्वी झालेल्या यंत्रणेचे नाव घ्या। ब्रॉडकास्ट वापरणाऱ्या शोधाला सेगमेंट लागते, तर रिझॉल्व्हर वापरणाऱ्या शोधाला विचारण्यासाठी पत्ता लागतो।

TUN काय वाहतो आणि काय वाहत नाही

TUN उपकरण एक IP इंटरफेस आहे, आणि तेच त्याला मार्गण्यायोग्य बनवते। OpenVPN क्लायंटला पत्ता आणि मार्गांचा संच देते, आणि त्यानंतर क्लायंट समकक्षाला डेटाग्राम पाठवतो। त्या प्रतिमानात प्रत्येक यजमान प्रत्येक फ्रेम ऐकतो असे सामायिक दुवे तयार करणारे काहीही नाही।

शोधाचा रहदारी त्या प्रतिमानात अजिबात बसत नाही। जुन्या Windows नाव-क्वेऱ्या, SSDP घोषणा आणि mDNS विनंत्या एकाच गंतव्याकडे नाही तर सेगमेंटमधील सर्वांकडे पाठवल्या जातात। मार्गित दुव्याकडे पाठवण्यासाठी «सर्व» नसतात। यांपैकी प्रत्येक यंत्रणा सामायिक माध्यम गृहीत धरते।

त्यामुळे बोगदा निरोगी असू शकतो तर शोध पूर्णपणे अयशस्वी होऊ शकतो। कोणी VPN बंद असल्याचे सांगितल्यावर हेच वाक्य धरून ठेवायचे आहे।

ब्रिजिंग सीमा काढून कार्य करते

TAP उपकरण फ्रेम वाहते, आणि पूल ते खऱ्या LAN सेगमेंटला जोडतो। मग क्लायंटकडे त्या सेगमेंटवर पत्ता असतो आणि तो त्याचा ब्रॉडकास्ट रहदारी ऐकतो। म्हणूनच ब्रिजिंग नावाची समस्या बरी करते असे वाटते। ते क्लायंटला पत्ते देण्यासाठी त्या सेगमेंटवर अवलंबूनही करते।

उपाय म्हणजे मार्गण सीमा काढून टाकणे, बोगद्यातील नावांची नवीन क्षमता नव्हे। सेगमेंट जे ब्रॉडकास्ट करते ते आता दुव्यालाही ओलांडते।

छोट्या प्रयोगशाळेसाठी ही योग्य देवघेव आहे। विखुरलेल्या कर्मचाऱ्यांसाठी असे क्वचितच होते।

DNS आणि WINS पुश करणे हा अरुंद उपाय आहे

क्लायंटला विचारण्यासाठी ठराविक जागा द्या। dhcp-option DNS आणि dhcp-option DOMAIN अंतर्गत नावे झोन ओळखणाऱ्या सर्व्हरकडे वळवतात, आणि अजूनही NetBIOS वर अवलंबून असलेल्या Windows क्लायंटला त्याच पद्धतीने WINS सर्व्हर मिळू शकतो। बोगदा मार्गित राहतो आणि सेगमेंट आपल्या जागी राहते।

दोन अटी हे कार्य करेल का हे ठरवतात। नमूद केलेल्या सर्व्हरने झोनसाठी उत्तर देणे आवश्यक आहे, आणि क्वेरीला बोगद्यातून परवानगी असणे आवश्यक आहे।

रिझॉल्व्हर क्लायंटवरून तपासा, सर्व्हरच्या स्वतःच्या शेलवरून नाही। स्थानिक पातळीवर कार्य करणारा रिझॉल्व्हर बोगदा काय वाहतो याबद्दल काहीही सांगत नाही।

कोणता स्तर अयशस्वी झाला ते शोधा

प्रथम पत्त्याला ping करा, नंतर नाव रिझॉल्व्ह करा आणि कोणत्या सर्व्हरने उत्तर दिले ते वाचा। झोन होस्ट न करणाऱ्या सर्व्हरचे नकारात्मक उत्तर, यंत्रातून कधीच न गेलेल्या क्वेरीपेक्षा वेगळे दिसते। रिझॉल्व्ह होणारे पण जोडण्या नाकारणारे नाव पूर्णपणे तिसरी समस्या आहे।

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