Windows VPN DNS गळती: मेट्रिक मार्गावर का जिंकते

एक क्वेरी मशीन सोडून घरच्या राउटरपर्यंत पोहोचते, तर प्रत्येक पॅकेट टनेलमधून जात असते। साहजिक निष्कर्ष असा की मार्ग गहाळ आहे, पण मार्ग सहसा ठीकच असतो। Windows इंटरफेस मेट्रिकवरून कोणत्या इंटरफेसच्या रिझोल्व्हरला विचारायचे हे निवडू शकते, आणि टनेल अडॅप्टर ही तुलना वायरलेसकडून अनेकदा हरते।

एका गळतीसाठी दोन स्पष्टीकरणे

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

क्रमवारीचे स्पष्टीकरण असे सांगते की रहदारी पूर्णपणे टनेलमध्ये आहे आणि क्वेरी तरीही दुसऱ्या रिझोल्व्हरकडे पाठवली जाते। Windows रिझोल्व्हरची निवड क्रम असलेली प्रत्येक-इंटरफेस गुणधर्म म्हणून पाहते, म्हणून चांगल्या मेट्रिकचा भौतिक अडॅप्टर नावासाठी DNS देऊ शकतो, जरी सोडवलेल्या पत्त्याचे पॅकेट टनेलमधून जात असले तरी। दोन्ही स्पष्टीकरणे गळती चाचणी पानावर एकच लक्षण निर्माण करतात, म्हणूनच चाचणी हे निदान नाही। त्यांपैकी एकच मार्ग संपादित करून दुरुस्त होते।

मेट्रिक आणि रिझोल्व्हर एकत्र तुलना करा

टनेल सुरू असताना इंटरफेस, त्यांची मेट्रिक आणि कॉन्फिगर केलेले सर्व्हर नोंदवा। ते दोन वेगळ्या याद्या म्हणून नाही तर तक्ता म्हणून वाचा, कारण प्रश्न कोणता रिझोल्व्हर आधी येतो हा आहे, कोणते रिझोल्व्हर अस्तित्वात आहेत हा नाही।

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

टनेल अडॅप्टरकडे भौतिक अडॅप्टरपेक्षा मोठा आकडा असेल तर त्याच्या रिझोल्व्हरला प्राधान्य मिळत नाही, आणि अंतर्गत नाव भौतिक बाजू जे देते त्याकडे जाईल। तो राउटर कॅशमधून उत्तर देऊ शकतो, क्वेरी पुढे पाठवू शकतो किंवा नाकारू शकतो, आणि या परिणामांपैकी कोणताही तुम्ही ठरवलेली रचना नाही। क्रम हे प्राधान्य आहे, म्हणून तो त्रुटी उठवण्याऐवजी गुपचूप हरतो।

कोणताही रिझोल्व्हर कॉन्फिगर न केलेला टनेल अडॅप्टर तितकाच सामान्य प्रकार आहे। क्लायंट DNS ढकलल्याशिवाय इंटरफेस उभा करतो, म्हणून क्रमाचा प्रश्न उद्भवतच नाही।

टनेल वर आणा आणि पुन्हा तपासा

एलिव्हेटेड शेलमध्ये टनेल इंटरफेसला सर्वात कमी मेट्रिक द्या, किंवा भौतिक अडॅप्टरचे मूल्य वाढवा। दोन्ही प्रत्येक-इंटरफेस सेटिंग्ज आहेत आणि दोन्ही उलटता येतात, जे तुम्ही समोर बसलेले नसाल अशा मशीनमध्ये बदल करताना महत्त्वाचे ठरते।

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

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

मग एक अंतर्गत आणि एक सार्वजनिक नाव विचारा आणि कोणत्या सर्व्हरने उत्तर दिले ते तपासा। Microsoft चे स्वयंचलित मेट्रिकबद्दलचा संदर्भ सर्वात कमी मूल्याला प्राधान्य का मिळते आणि स्वयंचलित वाटप कसे काढले जाते हे स्पष्ट करते।

पुन्हा जोडणीतही ते टिकून राहील असे करा

प्रत्येक जोडणीला पुन्हा तयार होणाऱ्या अडॅप्टरवर हाताने दिलेली मेट्रिक ही नाहीशी होणारी सेटिंग आहे। क्लायंटने इंटरफेस पुन्हा बांधला तर या ओव्हरराइडसाठी जोडणीनंतरची स्क्रिप्ट, धोरण किंवा जोडणीच्या काळात DNS चे मालकी हक्क असलेली क्लायंट कॉन्फिगरेशन लागते।

भौतिक अडॅप्टरवर स्थिरपणे कॉन्फिगर केलेल्या सर्व्हरना तीच टिकाऊपणाची समस्या उलट्या बाजूने आहे। ते काढले जाईपर्यंत त्या इंटरफेससाठी उत्तर देत राहतात, आणि DHCP पुढील भाडेपट्ट्यातून ते पुन्हा भरेल, म्हणून ते काढणे हे मोजमाप आहे, रचना नाही। टिकाऊ रचना अंतर्गत नावजागेसाठी नाव-निराकरण धोरण आहे, किंवा जोडणीच्या कालावधीत DNS आपल्याकडे घेणारा क्लायंट। कोणत्याही प्रकारे, पुन्हा जोडणीपूर्वी आणि नंतर रिझोल्व्हरची यादी नोंदवा, चाचणी संपल्यावर मूळ मेट्रिक पुनर्संचयित करा आणि पूर्वीचे वर्तन परत आले याची खात्री करा।