डायल-इन के बाद सर्वर का नाम उसके VPN पते पर क्यों रिज़ॉल्व होता है

एक ऑफ़िस फ़ाइल सर्वर पूरी सुबह अपने LAN पते पर जवाब देता है, फिर कोई दूरस्थ उपयोगकर्ता डायल-इन करता है और नाम इसके बजाय टनल पते पर रिज़ॉल्व होने लगता है। DNS में हाथ से कुछ संपादित नहीं किया गया, और यही सुराग है: रिकॉर्ड मशीन ने ही प्रकाशित किया। तीन शर्तें तय करती हैं कि आप रजिस्ट्रार, रिकॉर्ड या क्लाइंट के दृष्टिकोण को ठीक करेंगे, और क्रम गलत होने का अर्थ है कि रिकॉर्ड अगले कनेक्शन के बाद लौट आएगा।

दो पते, एक नाम, तीन शर्तें

मल्टीहोम्ड Windows सर्वर के पास LAN पता, एक या अधिक डायल-इन पते और कभी-कभी दूसरा नेटवर्क कार्ड हो सकता है। हर इंटरफ़ेस अपने पते DNS में पंजीकृत कर सकता है यदि उसके लिए गतिशील पंजीकरण की अनुमति हो। जब PPP अडैप्टर पंजीकृत होता है, तो वही होस्ट नाम ऐसा पता पाता है जहाँ केवल टनल साथी पहुँच सकता है, और LAN क्लाइंट्स उसे वैध उत्तर के रूप में प्राप्त करते हैं।

तीन शर्तें मरम्मत तय करती हैं। पहली, क्या अतिरिक्त पता उसे पाने वाले क्लाइंट्स से पहुँचने योग्य है? दूसरी, क्या कोई उपभोक्ता अभी भी उस पंजीकरण पर निर्भर है? तीसरी, क्या रिकॉर्ड गतिशील है और इसलिए लौट सकता है, या स्थिर है और इसलिए जानबूझकर दर्ज प्रविष्टि है?

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

रजिस्ट्रार बदलने से पहले रिकॉर्ड पढ़ें

समस्या बताने वाले नेटवर्क से सटीक पूर्ण योग्य नाम पूछें और उत्तरों की तुलना सर्वर के वास्तविक इंटरफ़ेस और श्रोताओं से करें। एक नाम का कई पते लौटाना सामान्य है; सवाल यह है कि क्या हर पता उसे पाने वाले क्लाइंट के लिए उपयोगी है।

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

पहली क्वेरी स्थानीय रिज़ॉल्वर का उपयोग करती है, दूसरी सीधे किसी विशिष्ट DNS सर्वर से पूछती है, और तीसरी Windows पर PowerShell से वही करती है। इनकी तुलना पुराने क्लाइंट कैश को आधिकारिक उत्तर से अलग करती है। यदि सीधी क्वेरी पहले ही टनल पता लौटा रही है, तो समस्या स्थानीय कैशिंग में नहीं, प्रकाशित डेटा में है।

रिकॉर्ड का टाइमस्टैम्प लिखें और यह भी कि DNS कंसोल उसे गतिशील दिखाता है या नहीं। वही एक गुण बताता है कि ऊपर की तीन शर्तों में से कौन लागू होती है, और यही पाँच मिनट की सफ़ाई और टिकने वाली मरम्मत के बीच का अंतर है।

प्रकाशक ठीक करें या रिकॉर्ड, पर जानें कौन-सा

यदि रिकॉर्ड गतिशील और अनचाहा है, तो टिकाऊ समाधान उस इंटरफ़ेस को पंजीकृत होने से रोकना है। Windows हर इंटरफ़ेस के लिए पंजीकरण सेटिंग्स देता है, और DNS क्लाइंट सेवा अगले कनेक्शन या पता परिवर्तन पर फिर प्रकाशित करती है। डायल-इन अडैप्टर के लिए पंजीकरण बंद करने से LAN अडैप्टर का पंजीकरण अछूता रहता है, जो आमतौर पर वही है जो आप चाहते हैं।

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

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

जो क्लाइंट नेटवर्क विफल हुआ उससे सत्यापित करें

सत्यापन उसी नेटवर्क पर है जिसने लक्षण बताया, सर्वर पर नहीं। क्लाइंट रिज़ॉल्वर कैश को उसके समर्थित तंत्र से साफ़ करें, फिर मूल लुकअप और नाम से मूल सेवा कनेक्शन दोहराएँ।

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

पहला कमांड Windows रिज़ॉल्वर कैश साफ़ करता है, और दूसरा दिखाता है कि नाम फिर कैश हुआ या नहीं और कौन-सा पता संग्रहीत हुआ। सर्वर का स्वयं से सफल कनेक्शन LAN क्लाइंट के बारे में कुछ साबित नहीं करता, और अनचाहे पते का मार्ग हटाना DNS जो प्रकाशित करता है उसे ठीक नहीं करता।

अंत में, जो घटना पहले पता लाती थी उसे दोहराएँ: VPN क्लाइंट फिर कनेक्ट करें, या डायल-इन सत्र नवीनीकृत करें। उस जीवनचक्र परिवर्तन के बाद प्रकाशित नाम फिर जाँचें। जो मरम्मत केवल अगले कनेक्शन तक टिके वह सफ़ाई थी, मरम्मत नहीं, और आपने कौन-सी की यह जानना टिकट बंद करने और अगले हफ़्ते उसे फिर खोलने के बीच का अंतर है।