LAN होस्टनेम VPN पर काम नहीं करता: सफ़िक्स, mDNS या ज़ोन?

डिवाइस के पास प्रिंटर एक छोटे नाम पर जवाब देता है और फ़ाइल सर्वर एक उपनाम पर जवाब देता है। सुरंग से होकर दोनों नाम समय-सीमा पार कर जाते हैं, जबकि उनके पते अब भी काम करते हैं। रूट अपना काम कर रहा है; जिस नेमिंग पथ ने उन छोटे नामों को काम कराया था, वह कभी सुरंग पार नहीं कर पाया। तीन तंत्र यह व्यवहार पैदा करते हैं, और हर एक को अलग सुधार चाहिए।

यह पहचानकर शुरू करें कि नाम किस तंत्र पर निर्भर है।

तीन तरह के नाम जो अलग व्यवहार करते हैं

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 कॉन्फ़िगरेशन के ज़रिए खोज डोमेन पुश करें।

परिणाम क्लाइंट पर जाँचें, गेटवे पर नहीं। सर्वर पर लागू कोई सेटिंग जो कभी क्लाइंट तक नहीं पहुँचती, कुछ नहीं बदलती।

प्रमाणपत्र की पहचान अक्षुण्ण रखें

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

जिस नाम, रिज़ॉल्वर और सफ़िक्स ने सफल कनेक्शन दिया, उसे दर्ज करें। वह रिकॉर्ड अगले व्यक्ति को उस पता-आधारित वैकल्पिक उपाय को दोहराने से बचाता है जो असली समस्या छिपाता है।