resolvectl आउटपुटमधून प्रत्येक लिंकचे VPN DNS राउटिंग कसे वाचावे
resolvectl status प्रत्येक लिंकसाठी सर्व्हर, डोमेन आणि डीफॉल्ट रूट दाखवते। ते एकत्र वाचा, नंतर नाव विचारा आणि कोणत्या लिंकने उत्तर दिले ते नोंदवा.
resolvectl status चालवा आणि तुम्हाला प्रत्येक लिंकसाठी ब्लॉक्सची भिंत मिळेल, प्रत्येकाकडे स्वतःचे सर्व्हर आणि स्वतःची डोमेन ओळ असते। राउटिंग ठरवणारी ओळ डोमेन यादी आहे, नेमसर्व्हरचा पत्ता नाही, कारण स्थानिक स्टब प्रत्येक प्रश्न त्या लिंककडे पाठवतो जी नावाचा दावा करते। उत्तर वाचण्यापूर्वी ते दावे वाचा, नंतर नाव विचारा आणि कोणत्या लिंकने ते तयार केले ते तपासा। योग्य लिंककडून चुकीचे उत्तर ही वेगळी समस्या आहे चुकीच्या लिंककडून योग्य उत्तरापेक्षा।
प्रत्येक लिंक-ब्लॉक तुम्हाला काय सांगतो
प्रत्येक ब्लॉक रिझोल्व्हर त्या इंटरफेससाठी वापरणारे सर्व्हर, डोमेन यादी आणि लिंक डीफॉल्ट रूट आहे का हे सूचीबद्ध करतो। डोमेन यादी दाव्यांचा संच आहे आणि रिझोल्व्हर सर्वात लांब प्रत्ययाची जुळणी लावतो: host.corp.example साठीचा प्रश्न corp.example असलेली लिंक, फक्त डीफॉल्ट रूट असलेल्या लिंकपेक्षा आधी दावा करते। एकाच प्रत्ययाचा दावा करणाऱ्या दोन लिंक निकाल प्राधान्य आणि क्रमावर सोडतात, म्हणून प्रतींकडे आधी लक्ष देणे योग्य। सध्याची सर्व्हर ओळ सूचीतील कोणता सर्व्हर त्या क्षणी वापरात आहे ते दाखवते।
/etc/resolv.conf मधील 127.0.0.53 सारखा स्टब पत्ता फक्त स्टब पुढे आहे हे सांगतो। तो उत्तर दिलेल्या वरच्या स्रोताचे नाव घेत नाही, म्हणून केवळ resolv.conf वर आधारित निदान अडकते।
तीन प्रकारच्या डोमेन नोंदी योग्यरित्या वाचा
| नोंद | कशाचा दावा करते | सामान्य चूक |
|---|---|---|
| corp.example | राउटिंग डोमेन आणि शोध प्रत्यय: त्याखालील नावे या लिंककडे जातात, आणि स्ट्रिंग नग्न नावांना जोडली जाते | काढून टाकले कारण राउटिंग तरीही काम करत असल्याचे दिसते |
| ~corp.example | फक्त रूट: त्याखालील नावे या लिंककडे जातात, पण प्रत्यय जोडला जात नाही | राउटिंगसाठी आवश्यक असल्याचे गृहीत धरले |
| ~. | डीफॉल्ट रूट: दुसऱ्या कोणत्याही लिंकशी न जुळणाऱ्या प्रश्नांचा दावा करते | विभाजित प्रोफाइलवर सक्रिय ठेवले, त्यामुळे सार्वजनिक नावे टनेलचे अनुसरण करतात |
टिल्डा शोधाचे वर्तन बदलतो, राउटिंग नाही। टिल्डाशिवाय नोंद राउटिंग डोमेन आणि शोध डोमेन दोन्ही आहे, म्हणून त्याखालील नावे त्या लिंककडे पाठवली जातात आणि एक-लेबल नावांना प्रत्यय जोडला जातो। टिल्डा नोंद तोच प्रत्यय राउट करते पण त्याला शोध यादीबाहेर ठेवते। म्हणून टिल्डा काढल्याने कोणती नग्न नावे सुटतात ते बदलते, आणि म्हणून टिल्डा नसणे ही शोधाची समस्या आहे, विभाजित DNS ची अयशस्वीता नाही।
डीफॉल्ट रूट नोंद दुसऱ्या कोणत्याही लिंकशी न जुळणाऱ्या सर्वांचा दावा करते। पूर्ण-टनेल प्रोफाइल सामान्यतः ती हवी असते आणि विभाजित प्रोफाइल सामान्यतः नको असते, कारण मग सार्वजनिक नावे खाजगी रिझोल्व्हरकडे जातात आणि तिथे अयशस्वी होऊ शकतात। प्रोफाइलमधील फ्लॅग कॉपी करण्याऐवजी प्रोफाइलच्या हेतूच्या विरुद्ध तक्ता वाचा। जेव्हा दोन लिंक एकाच प्रत्ययाचा दावा करतात, तेव्हा दुसरे काही संपादित करण्यापूर्वी प्राधान्याचा प्रश्न सोडवा।
नाव विचारा आणि कोणत्या लिंकने उत्तर दिले ते पहा
query उप-आदेश पत्ता, प्रोटोकॉल आणि उत्तर तयार करणारी लिंक किंवा व्याप्ती छापतो। खाजगी प्रत्ययाने दावा करावा असे एक नाव आणि एक सामान्य सार्वजनिक नाव तपासा, नंतर नोंदवलेल्या स्रोतांची तुलना करा। खाजगी नाव वायरलेस लिंककडून उत्तर देत असेल, तर दावा नाही किंवा टनेल बंद आहे; विभाजित प्रोफाइलमध्ये सार्वजनिक नाव टनेलकडून उत्तर देत असेल, तर डीफॉल्ट रूट खूप रुंद आहे। या दोन अपयशीता ब्राउझरमध्ये सारखी आणि या आउटपुटमध्ये उलट दिसतात।
resolvectl status
resolvectl query host.corp.example
नोंदवलेल्या प्रोटोकॉलकडेही लक्ष द्या, कारण कॅशे किंवा होस्ट-फाइलमधून उत्तर कोणत्याही वरच्या स्रोताला न विचारता येऊ शकते। कॅशेमधून आलेले उत्तर नाव कधीतरी सुटले होते हे सिद्ध करते, सध्याचे धोरण ते योग्यरित्या राउट करते हे नाही।
नाव राउटिंग पॅकेट राउटिंगपासून वेगळे ठेवा
रिझोल्व्हरचा निर्णय मार्ग तयार करत नाही। निवडलेल्या सर्व्हरला अजूनही स्वतःच्या पत्त्यापर्यंत रूट लागतो, आणि परत मिळालेल्या पत्त्याला अजूनही खाजगी नेटवर्कमध्ये रूट लागतो, म्हणून योग्य DNS धोरण कधीच न उघडणाऱ्या कनेक्शनसोबत राहू शकते। नाव सुटले पण ॲप्लिकेशन अयशस्वी झाले, तर पुन्हा DNS बदलण्याऐवजी पत्ता आणि मार्ग तपासा। नाव सुटणे आणि पोहोचणे हे दोन वेगळ्या मालकांचे दोन प्रश्न आहेत।
ॲप्लिकेशन स्वतःच्या सुरक्षित DNS सेटिंगवर किंवा बंडल केलेल्या रिझोल्व्हरवरून सिस्टम रिझोल्व्हरला पूर्णपणे टाळू शकतात। resolvectl निकाल सिस्टम मार्ग वर्णन करतो, आणि त्याकडे दुर्लक्ष करणारा ब्राउझर तुम्ही करता त्या प्रत्येक चाचणीशी विसंगत ठरेल। धोरण तुटलेले आहे असा निष्कर्ष काढण्यापूर्वी ती सेटिंग तपासा।
नाव ज्या पत्त्यावर सुटले तो लिंकच्या बाजूला नोंदवा। चुकीच्या पत्त्याकडे निर्देश करणारे योग्य नाव म्हणजे राउटिंग नाही, रेकॉर्डची समस्या।
लिंक बदलल्यानंतर पुन्हा तपासा
पुन्हा जोडणी किंवा वायरलेस बदल लिंकची स्थिती पुन्हा बांधतो, आणि नेटवर्क मॅनेजर हाताने सेट केलेल्या सर्वांवर स्वतःचे डोमेन आणि सर्व्हर पुन्हा बसवू शकतो। नंतर तीच दोन नावे विचारा आणि नोंदवलेल्या आधाररेषेशी तुलना करा। हातचे संपादन गायब झाले असेल, सुधारणा कनेक्शन प्रोफाइलमध्ये असावी शेल आदेशात नाही। आधी आणि नंतर नोंदवणे हेच ते दृश्यमान करते।
अहवालाला आवश्यक असलेली नावे आणि सर्व्हर संदर्भच सामायिक करा, कारण अंतर्गत प्रत्यय टोपोलॉजी उघड करतात। systemd-resolved चे डोमेन राउटिंग दस्तऐवज सर्वात लांब जुळणीचा नियम आणि टिल्डाचे वर्तन समाविष्ट करते, आणि एकदा वाचल्यास वरील तक्त्यातील बहुतेक चुका टळतात: systemd-resolved मधील प्रश्न राउटिंग।