डायल-इन नंतर सर्व्हरचे नाव त्याच्या VPN पत्त्यावर का रिझॉल्व्ह होते
मल्टीहोम्ड सर्व्हर त्याचा PPP पत्ता प्रकाशित करून LAN क्लायंट्स तोडू शकतो। रजिस्ट्रार दुरुस्त करणे आणि फक्त जुनी नोंद साफ करणे यातून निवडा।
एक ऑफिस फाइल सर्व्हर सकाळभर त्याच्या 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 क्लायंट पुन्हा जोडा, किंवा डायल-इन सत्र नूतनीकरण करा। त्या जीवनचक्र बदलानंतर प्रकाशित नाव पुन्हा तपासा। पुढील कनेक्शनपर्यंतच टिकणारी दुरुस्ती साफसफाई होती, दुरुस्ती नाही, आणि तुम्ही कोणती केली हे जाणणे म्हणजे तिकीट बंद करणे आणि पुढील आठवड्यात ते पुन्हा उघडणे यातील फरक।