VPN वर NXDOMAIN म्हणजे टनेल बंद पडणे नाही

एक अपयशी लुकअप टनेल कोसळल्याचा पुरावा म्हणून वाचणे मोहक वाटते, विशेषतः जेव्हा नाव दहा मिनिटांपूर्वी काम करत होते। उत्तर काहीतरी वेगळे सांगते। NXDOMAIN हा पूर्ण झालेला DNS व्यवहार आहे, ज्यात रिझॉल्व्हरने सांगितले की विचारलेले नाव अस्तित्वात नाही; तुटलेली टनेल सामान्यतः शांतता, टाइमआउट किंवा चुकीच्या सर्व्हरकडे रिझोल्यूशनचा प्रयत्न निर्माण करते। wireshark शिवायची युक्तिवादाची आवृत्ती एक क्वेरी, एक उत्तरदाता आणि एक उत्तर कोड आहे, आणि कोणत्याही कॉन्फिगरेशन बदलापूर्वी हा त्रिकट नोंदवणे योग्य आहे।

उत्तर प्रत्यक्षात काय सिद्ध करते

DNS असे परिणाम वेगळे करते जे क्लायंट अनेकदा एकाच अपयशात एकत्र करतात। अस्तित्वात नसलेले नाव NXDOMAIN कोडसह नकारात्मक उत्तर देते, तर अस्तित्वात असलेले पण मागितलेल्या प्रकारचे रेकॉर्ड नसलेले नाव रिकाम्या उत्तर विभागासह यशस्वी उत्तर देते। दोन्ही एखाद्या अनुप्रयोगाला निरुपयोगी वाटतात, आणि त्यापैकी एकच नाव चुकीचे असल्याचा अर्थ देतो।

हा फरक दुरुस्ती कुठे असावी हे ठरवतो। A रेकॉर्ड असलेल्या होस्टवर AAAA रेकॉर्ड नसणे म्हणजे होस्ट नसणे नाही, आणि त्याचा पाठलाग करण्यासाठी प्रमाणपत्र पुन्हा जारी करणे किंवा टनेल पुन्हा बांधणे हे उपलब्ध एकमेव सुगावा वाया घालवते। हा फरक पुढील पावलाचे स्वरूपही ठरवतो: नामकरणाची समस्या झोनमध्ये दुरुस्त होते, आणि प्रकाराची समस्या योग्य रेकॉर्ड मागून किंवा पत्ता कुटुंबच नाही हे स्वीकारून दुरुस्त होते।

गैरसमज: खाजगी नाव नसणे म्हणजे टनेल अपयशी

हा गैरसमज टिकतो कारण या दोन घटना बऱ्याचदा एकत्र येतात। क्लायंट VPN ला जोडतो, ऑपरेटिंग सिस्टम आधीच विश्वासात घेतलेला रिझॉल्व्हर ठेवते, आणि आता आवश्यक असलेले अंतर्गत नाव खाजगी झोनबद्दल कधीही न ऐकलेल्या सर्व्हरला विचारले जाते। तो सर्व्हर प्रामाणिकपणे आणि नकारात्मकपणे उत्तर देतो। टनेल पॅकेट वाहत आहे; उत्तर फक्त अशा नावाच्या जागेबद्दल आहे ज्याची सेवा उत्तरदाता देत नाही।

split-horizon रचना हे नेहमीचे करतात: तेच झोन नाव सार्वजनिक आणि अंतर्गत स्वरूपात वेगळ्या सामग्रीसह अस्तित्वात असते, आणि खाजगी रेकॉर्ड फक्त अंतर्गत रिझॉल्व्हरला माहीत असतात। म्हणून अधिकृत दिसणारे नकारात्मक उत्तर मिळणे हा कोणत्या रिझॉल्व्हरने उत्तर दिले याचा पुरावा आहे, इंटरफेसच्या स्थितीचा पुरावा नाही।

निकाल दोन कॉन्फिगरेशन तपशील ठरवतात। टनेलने अंतर्गत रिझॉल्व्हर ढकलणे किंवा निवडणे आवश्यक आहे, आणि क्लायंटने ती निवड शोधल्या जाणाऱ्या नावावर लागू करणे आवश्यक आहे। तुम्ही टाइप केलेल्या रेकॉर्डपेक्षा थोडा वेगळा प्रत्यय नाव देणारा प्रति-डोमेन नियम क्वेरी सार्वजनिक मार्गावर पाठवेल, आणि उत्तर बरोबर पण निरुपयोगी असेल।

योग्य नावासह योग्य रिझॉल्व्हरला विचारा

निकाल नोंदवण्यापूर्वी उत्तरदाता नोंदवा। कोणत्या सर्व्हरने उत्तर दिले हे न दाखवणारा लुकअप धोरणाची समस्या आणि नावाच्या जागेची समस्या वेगळी करू शकत नाही, आणि दोन्हींच्या दुरुस्त्या असंबंधित आहेत।

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

पहिल्या दोन ओळी स्थानिक रिझॉल्व्हरने काय ठरवले आणि कोणाला विचारेल हे दाखवतात। +search लुकअप अनुप्रयोग शोध प्रत्यय जोडतो तेव्हा काय करतो याचे पुनरुत्पादन करतो, जे अनेकदा निदान साधनात टाइप केलेली क्वेरी नसून खरी क्वेरी असते। शेवटची ओळ क्लायंट धोरण टाळून अंतर्गत सर्व्हरला थेट विचारते; ते यशस्वी होऊन साधा लुकअप अपयशी होत असेल, तर झोन ठीक आहे आणि क्वेरींचे राउटिंग नाही।

नकारात्मक कॅशिंग दुरुस्तीनंतरचा विलंब स्पष्ट करते

नकारात्मक उत्तरे रचनेनुसार कॅश होतात, आणि RFC 2308 नकारात्मक कॅशचे आयुष्य झोनच्या अधिकार रेकॉर्डवरून कसे काढले जाते ते वर्णन करते। म्हणून रेकॉर्ड किंवा रिझॉल्व्हर नियम दुरुस्त केल्याने क्लायंटवर तात्काळ बदलाची हमी मिळत नाही, आणि कॅश केलेले उत्तर परत देत राहणारा लुकअप पुन्हा प्रयत्न करून नवीन काही सिद्ध होत नाही। फक्त वेगळा उत्तरदाता, वेगळे नाव किंवा रिकामी केलेली कॅश ताजा पुरावा देते।

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

नाव मार्गापासून वेगळे करा

नाव अपेक्षित खाजगी पत्त्यावर रिझॉल्व्ह झाल्यावर DNS विषय म्हणून संपते आणि पुढचा प्रश्न अनुप्रयोगाचा मार्ग होतो। लुकअपना उत्तर देणारा पण कनेक्शन नाकारणारा होस्ट वेगळ्या समस्येने ग्रस्त असतो, आणि योग्य उत्तरानंतरही रिझॉल्व्हर समायोजित करत राहणे हा घटनेला तीन असंबंधित बदल मिळवून देण्याचा मार्ग आहे। दोन्ही जुळतात असे गृहीत धरण्यापूर्वी रिझॉल्व्ह झालेल्या पत्त्याची सेवा प्रत्यक्षात ज्या पत्त्यावर ऐकते त्याच्याशी तुलना करा।

नोंद ठेवा: क्वेरी, उत्तरदाता, कोड आणि रिझॉल्व्ह झालेला पत्ता। ती नोंदच पुढील अहवाल पडताळणीयोग्य करते, आणि तोच निदान आणि हळू वाटलेल्या टनेलबद्दलच्या कथेतला फरक आहे।