LAN होस्टनाव VPN वर काम करत नाही: सफिक्स, mDNS की झोन?
छोटे नाव शोध सफिक्सवर अवलंबून असू शकते, .local नाव मल्टिकास्टवर आणि कंपनीचे नाव खाजगी झोनवर। फक्त रूट कोणतीही नामकरण सेवा देत नाही।
उपकरणाच्या शेजारी प्रिंटर छोट्या नावाला प्रतिसाद देतो आणि फाइल सर्व्हर टोपणनावाला प्रतिसाद देतो। बोगद्यातून दोन्ही नावे कालबाह्य होतात, तर त्यांचे पत्ते अजूनही काम करतात। रूट आपले काम करत आहे; ज्या नामकरण मार्गामुळे ती छोटी नावे काम करत होती, तो कधीही बोगदा ओलांडला नाही। तीन यंत्रणा हे वर्तन निर्माण करतात आणि प्रत्येकाला वेगळी दुरुस्ती हवी आहे।
नाव कोणत्या यंत्रणेवर अवलंबून आहे हे ओळखून सुरुवात करा।
वेगळ्या पद्धतीने वागणारी तीन प्रकारची नावे
fileserver सारखे एकल-लेबल नाव सामान्यतः रिझोल्व्हर जोडतो त्या DNS शोध सफिक्सवर अवलंबून असते। तो सफिक्स अनेकदा स्थानिक DHCP लीजसोबत येतो, त्यामुळे VPN कडून पत्ता मिळवणाऱ्या दूरस्थ क्लायंटला तो जाणण्याचे कारण नाही। रूट जोडल्याने सफिक्स पोहोचत नाही। छोटे नाव फक्त नाव म्हणून राहणे थांबवते, त्यामागील पत्ता पोहोचण्यायोग्य असला तरी।
.local ने संपणारे नाव सामान्यतः स्थानिक लिंकवर मल्टिकास्ट DNS द्वारे सोडवले जाते, जसे RFC 6762 वर्णन करते। मल्टिकास्ट रूट केलेला बोगदा ओलांडत नाही, जोपर्यंत काही जाणूनबुजून त्याला ब्रिज किंवा प्रॉक्सी करत नाही, त्यामुळे तुम्ही विभाग सोडताच नाव सोडवणे थांबते।
पूर्णपणे पात्र कंपनीचे नाव संस्थेचे रिझोल्व्हर सेवा देत असलेल्या अंतर्गत झोनचे आहे। VPN ते रिझोल्व्हर पुश करतात आणि क्लायंट त्यांचा वापर करण्यासाठी कॉन्फिगर केलेला असतो तेव्हा ते दूरून काम करते। आणि localhost RFC 6761 नुसार विशेष-वापर आहे: ते तुमच्या समोरील मशीनला सूचित करते, कधीही दूरस्थ सेवेला नाही।
रूट बदलण्यापूर्वी रिझोल्व्हर वाचा
कोणत्या नाव सर्व्हरने उत्तर दिले आणि कोणते सफिक्स जोडले गेले ते विचारा। वेगवेगळ्या रिझोल्व्हरमधून तीच क्वेरी वेगळी उत्तरे देते, आणि तोच फरक तुम्हाला हवा असलेला पुरावा आहे।
getent hosts fileserver getent hosts fileserver.corp.example.com nslookup fileserver.corp.example.com dig +search fileserver A resolvectl query fileserver.corp.example.com scutil --dns | head -30
जर पूर्णपणे पात्र क्वेरी सोडवली जाते पण छोटी नाही, तर अयशस्वी सफिक्समध्ये आहे, सर्व्हरमध्ये नाही। जर दोन्हीही सोडवल्या जात नाहीत आणि पत्ता काम करतो, तर क्लायंट अंतर्गत रिझोल्व्हर अजिबात वापरत नाही। रिझोल्व्हर यादीची VPN ने पुश करायला हवे त्याच्याशी तुलना करा, कारण प्रत्येक क्वेरीसाठी स्वतःचा स्थानिक रिझोल्व्हर ठेवणारा क्लायंट अंतर्गत झोन कधीही पाहणार नाही।
योग्य नाव क्लायंटपर्यंत आणा
प्रशासकाकडून दस्तऐवजीकृत दूरस्थ-प्रवेश नाव पूर्णपणे मागा आणि सफिक्सचा अंदाज लावण्याऐवजी प्रोफाइलमध्ये ते वापरा। जर उपयोजन split DNS ला समर्थन देते, तर अंतर्गत डोमेन अंतर्गत सर्व्हरद्वारे सोडवला जाईल असे कॉन्फिगर करा, बाकी सर्व स्थानिक रिझोल्व्हर ठेवेल। क्लायंट समर्थन देतो तेथे VPN कॉन्फिगरेशनद्वारे शोध डोमेन पुश करा।
निकाल क्लायंटवर तपासा, गेटवेवर नाही। सर्व्हरवर लागू केलेली आणि क्लायंटपर्यंत कधीही न पोहोचणारी सेटिंग काहीही बदलत नाही।
प्रमाणपत्राची ओळख अभंग ठेवा
प्रमाणपत्राच्या त्रुटीकडे दुर्लक्ष करणारी पत्ता-आधारित चाचणी फक्त सॉकेट उघडले हे सिद्ध करते। सेवेचे प्रमाणपत्र एका नावासाठी जारी केले जाते, आणि क्लायंट योग्य कारणाने विसंगती नाकारत राहील। जर प्रमाणपत्रात फक्त अंतर्गत नाव सूचीबद्ध असेल, तर तेच नाव वापरा आणि निराकरण दुरुस्त करा, किंवा तुम्ही वापरण्याचा विचार करत असलेल्या पत्त्याचा समावेश असलेले प्रमाणपत्र मिळवा।
ज्या नावाने, रिझोल्व्हरने आणि सफिक्सने यशस्वी कनेक्शन दिले ते नोंदवा। ती नोंद पुढील व्यक्तीला खरे प्रश्न लपवणाऱ्या पत्ता-आधारित पर्यायी उपायाची पुनरावृत्ती करण्यापासून वाचवते।