कोणती लिंक उत्तर देते: स्प्लिट-टनेल VPN DNS साठी राउटिंग डोमेन

सामान्य ब्राउझिंग स्थानिक लिंकवर ठेवा, तर कंपनीची नावे टनेल पुरवतो त्या DNS सर्व्हरमार्फत सोडवली जातात। VPN चा डीफॉल्ट राउट बंद केल्यास पहिला अर्धा भाग मिळतो आणि दुसरा अर्धा न बांधलेला राहतो। पुढे येते गहाळ सेटिंग, तिचा अर्थ बदलणारे विरामचिन्ह आणि कोणत्या लिंकीने प्रत्यक्षात उत्तर दिले हे दाखवणारी एकमेव आज्ञा। संपूर्ण मजकुरात NetworkManager आणि systemd-resolved गृहीत धरले आहेत, कारण गोंधळ सहसा याच जोडीपासून सुरू होतो।

पहिली पायरी: राउट रिझॉल्व्हरपासून वेगळे करा

ipv4.never-default राउटिंगच्या प्रश्नाला उत्तर देते आणि हे कनेक्शन सर्व IPv4 रहदारीसाठी मार्ग म्हणून बसवण्यापासून NetworkManager ला रोखते। DNS राउटिंग डोमेन वेगळ्या प्रश्नाला उत्तर देते: जुळणाऱ्या सफिक्ससाठी क्वेरी कोणत्या लिंकीच्या नाव सर्व्हरना मिळते। एकही दुसऱ्याला सूचित करत नाही, आणि प्रोफाइल वर्षानुवर्षे एक बाळगू शकते तर दुसरे गहाळ असते। फक्त-राउट म्हणजे टनेल कंपनीचे सबनेट वाहते आणि त्याचा रिझॉल्व्हर कंपनीच्या नावांना उत्तर देतो, बाकी सर्व अडलेले राहते।

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

दुसरी पायरी: प्रोफाइलमध्ये फक्त-राउटिंग डोमेन जोडा

कनेक्शनचे नाव corp-vpn आहे, कंपनीचा सफिक्स internal.example आहे, आणि टनेलचा रिझॉल्व्हर आधीच पोहोचण्यायोग्य आहे असे समजा। आधी सध्याची मूल्ये वाचा, कारण खालील आज्ञा आधीच नोंदी असू शकणाऱ्या प्रॉपर्टी बदलतात।

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

सुरुवातीचे टिल्ड फक्त-राउटिंग डोमेन दर्शवते, म्हणून जुळणाऱ्या क्वेऱ्या या लिंकीच्या सर्व्हरकडे जातात आणि सफिक्स लहान नावांना जोडला जात नाही। टिल्ड काढल्यास तीच स्ट्रिंग शोध सफिक्सही होते, हा वेगळा परिणाम लोक क्वचितच हेतूने करतात। वरील दोन्ही सेटिंग्ज IPv4 आहेत, म्हणून दुहेरी-स्टॅक प्रोफाइलला ipv6.never-default आणि ipv6.dns-search मध्ये तोच राउटिंग डोमेन हवा, अन्यथा IPv6 बाजू डीफॉल्ट राउट वापरत राहते आणि तिथे अंतर्गत नावे अयशस्वी होतात।

तिसरी पायरी: कोणत्या लिंकीने उत्तर दिले ते resolvectl ला विचारा

resolvectl status चालवा आणि प्रत्येक लिंकीचे DNS सर्व्हर व डोमेन वाचा, नंतर विचारण्याची परवानगी असलेल्या खऱ्या अंतर्गत नावावर resolvectl query host.internal.example चालवा। दुसरी आज्ञा ही राउटिंग डोमेन आपले काम करत असल्याचा एकमेव थेट पुरावा आहे, कारण ती उत्तर देणाऱ्या लिंकीचे नाव घेते। फक्त स्थिती यादी संरचना सिद्ध करते; क्वेरी सोडवणे सिद्ध करते।

systemd-resolved सर्वात जुळणारे राउटिंग डोमेन निवडते, म्हणून दुसऱ्या लिंकीवरील अधिक विशिष्ट डोमेन अजूनही शर्यत जिंकू शकते। क्वेरी अपेक्षित नसलेल्या लिंकीकडून परत आल्यास, VPN च्या DNS सर्व्हरला स्पर्श करण्यापूर्वी डोमेन याद्या वाचा। ~. रूट डोमेन सर्वांशी जुळते, आणि ते आधीच असल्यास तुमचे विशिष्ट डोमेन स्वतःच्या नावांसाठी अजूनही जिंकते तर लिंक तुम्ही मागितले त्यापेक्षा खूप जास्त उत्तर देते। हेतू फक्त कंपनीची नावे असल्यास ती रूट नोंद काढून टाका किंवा अरुंद करा।

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

चौथी पायरी: नाव सोडवले जाते पण सेवा नाही

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

या प्रश्नासोबत फिरणारा Samba बदल प्रवेश स्तराशी संबंधित आहे, DNS निवडीशी नाही। नाव-सोडवणीच्या बिघाडावर तो लागू करणे म्हणजे छोट्या समस्येला दुसरी मिळण्याचा मार्ग।

पाचवी पायरी: गहाळ डोमेन दुरुस्त करण्यासाठी रिझॉल्व्हर बदलू नका

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

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