VPN DNS काम करतो, पण .local नावे अजूनही अपयशी होतात: ती कोण सोडवतो?

एकाच VPN वर दोन मशिन, एकच होस्टनाव, आणि त्यापैकी फक्त एकच ते सोडवते: फरक सहसा टनेलमध्ये नसतो, तर कोणत्या रिझॉल्व्हरने उत्तर दिले यात असतो. Linux डेस्कटॉपवर ते नाव नाव सेवा स्विचमधून, systemd-resolved च्या स्टबमधून, किंवा अनुप्रयोगाने सोबत आणलेल्या रिझॉल्व्हरमधून जाऊ शकते, आणि त्यापैकी प्रत्येक त्याच सफिक्सवर आपला नियम लागू करते. नियम वेगळे होतात ते सफिक्सवरच, कारण .local तटस्थ लेबल नाही. काहीही कोणत्या क्रमाने चालते हे बदलण्यापूर्वी अपयशी प्रोग्राम प्रत्यक्षात कोणता मार्ग घेतो ते शोधा.

दोन रिझॉल्व्हर, दोन वेगळी उत्तरे

पारंपरिक glibc शोध nsswitch.conf च्या hosts: ओळीतून जातो आणि एक उत्तर देईपर्यंत प्रत्येक मॉड्यूलला यामधून त्या विचारतो. स्टब लिसनरद्वारे systemd-resolved शी बोलणारा क्लायंट त्याऐवजी एकाच प्रक्रियेला विचारतो, आणि ती प्रक्रिया प्रत्येक लिंकसाठीचे धोरण अधिक स्वतःची विशेष प्रकरणे लागू करते. स्वतःचा रिझॉल्व्हर आणणारा किंवा तसे करणारी लायब्ररी लिंक करणारा अनुप्रयोग दोन्ही टाळू शकतो. त्यामुळे एका होस्टनावाचे एका मशिनवर तीन मालक असू शकतात, आणि त्यापैकी फक्त एकाला VPN चा हेतू काय होता हे माहीत असते.

काहीही बदलण्यापूर्वी मालक ओळखा, कारण तिघांपैकी प्रत्येकासाठी उपाय वेगळा आहे. एकाच डेस्कटॉपवरील ब्राउझर आणि कमांड-लाइन साधन कायदेशीरपणे असहमत असू शकतात, आणि ती असहमतीच सूचना आहे, बग नाही. ब्राउझर नाव सोडवत असेल आणि साधन न सोडवत असेल, तर तुम्ही रिझॉल्व्हर मार्ग डीबग करत आहात, VPN मार्ग नाही. मार्ग स्वतंत्रपणे तपासा, जेणेकरून राउटिंग दोष नाव सेवा दोष म्हणून ग्रहण केला जाणार नाही. दोन्ही सहमत असतील, तर दोष होस्टच्या वर आहे आणि येथील रिझॉल्व्हर संरचना आणखी एका संपादनाला पात्र नाही.

कोणत्या आदेशाने प्रत्यक्षात तुमच्या रिझॉल्व्हरला विचारले

दोन फक्त-वाचनीय आदेश संबंधित प्रश्नांची उत्तरे देतात, आणि त्यांची तुलना संरचना वाचण्यापेक्षा जलद समस्या स्थानिकीकृत करते. खरे अंतर्गत नाव वापरा आणि आउटपुट खाजगी ठेवा, कारण अंतर्गत नोंदी अंतर्गतच राहतात. दोन्ही त्या सत्रात चालवा ज्यात अपयशी प्रोग्राम चालतो:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

पहिला संरचित मॉड्यूल्सद्वारे विचारतो, जे सामान्य प्रोग्राम अनुभवतो. दुसरा थेट systemd-resolved ला विचारतो आणि उत्तर दिलेली लिंक, प्रोटोकॉल व सर्व्हर नोंदवतो. सर्व्हरला पत्त्यावरून विचारणे फक्त सर्व्हरकडे नोंद आहे हे सिद्ध करते, कारण अनुप्रयोगाने त्याला कधी विचारले का याबद्दल ते काहीही सांगत नाही. VPN वाहणारी लिंक आणि ती दावा करणारे डोमेन वाचा, नंतर ती यादी अपयशी नावातील सफिक्सशी तुलना करा.

का .local तुमचा unicast झोन वगळते

systemd-resolved चा संदर्भ सांगतो की .local ने संपणारी बहु-लेबल नावे, mDNS सक्षम असताना सामान्य unicast DNS ऐवजी सहसा multicast DNS कडे जातात. RFC 6762 ती नावजागा link-local multicast साठी राखून ठेवतो, त्यामुळे एखादा कॉर्पोरेट झोन बरोबर नोंद ठेवू शकतो जी त्या सफिक्ससाठी कधीही विचारली जात नाही. टनेल रिझॉल्व्हरला उत्तम प्रकारे राउट करू शकते आणि तरीही शर्यतीत हरू शकते. कॅशमधून यशस्वी ping आत्ताच झालेल्या शोधाबद्दल काहीही सांगत नाही.

एक दस्तऐवजीकृत अपवाद आहे, आणि तो यापैकी बहुतेक प्रकरणे सोडवतो: जेव्हा लिंक त्या सफिक्सला शोध डोमेन किंवा राउटिंग डोमेन म्हणून घोषित करते, तेव्हा डेमन ते unicast मार्गावर ठेवतो आणि multicast विशेष प्रकरण वगळतो. हे प्रत्येक लिंकचे धोरण आहे, जागतिक प्राधान्य नाही. एकाच VPN सर्व्हरसह दोन मशिन वेगळे वागू शकतात जेव्हा एक नेटवर्क प्रोफाइल डोमेन घोषित करते आणि दुसरे नाही, म्हणून तुम्हाला आठवत असलेल्या प्रोफाइलऐवजी सक्रिय प्रोफाइल वाचा.

अरुंद अपवाद जागतिक पुनर्रचनेला हरवतो

तुम्ही नाव बदलू शकत नाही अशा विद्यमान झोनसाठी, रिझॉल्व्हर आणि VPN मालकांना तो डोमेन वाहणाऱ्या कनेक्शनवर घोषित करायला सांगा. त्या एका सफिक्ससाठी राउटिंग-डोमेन नोंद आणि इच्छित सर्व्हर पत्ता हा नामनिर्देशित मालकासह छोटा बदल आहे, आणि तो हाताने संपादित फाइलमध्ये नाही, लिंकसोबत राहतो.

डिस्कनेक्टनंतरही तो टिकतो, कारण लिंक परत आल्यावर लिंक धोरण पुन्हा लागू होते. सामायिक nsswitch.conf संपादित करणे मोहक आणि अधिक खर्चिक पर्याय आहे, कारण ते मशिनवरील प्रत्येक नावासाठी शोध वर्तन बदलते, स्थानिक शोधासह. multicast डेमन अक्षम करणेही समतुल्य नाही: ते स्थानिक वर्तन काढून टाकते पण कोणत्याही रिझॉल्व्हरला कॉर्पोरेट झोन शिकवत नाही. सेवा वारसाहक्काने न मिळता नवीन असेल, तर ती तुमची संस्था नियंत्रित करणाऱ्या उपडोमेनखाली ठेवा आणि स्पर्धा पूर्णपणे टाळा. नाव फर्मवेअरमध्ये निश्चित असेल किंवा लेबलवर छापलेले असेल तर अरुंद अपवाद निवडा, आणि क्लायंट अजूनही तुमच्या नियंत्रणात असेल तर नवीन उपडोमेन निवडा.

बदलानंतर काय सिद्ध करायचे

सुधारणा अनुप्रयोगाच्या स्वतःच्या शोधाने सिद्ध करा, चाचणीसाठी स्थापित केलेल्या साधनाने नाही, आणि त्याच्या वतीने उत्तर देऊ शकणारी कोणतीही कॅश रिकामी करा. नंतर रिझॉल्व्हर मार्ग आणि उत्तर देणारी लिंक तपासा. शेवटी स्थानिक शोध बदलापूर्वीप्रमाणेच वागतो का ते तपासा, कारण दिसणे थांबलेला प्रिंटर हाच तो भाग आहे जो लोकांना शेवटी लक्षात येतो. हे तीन आदेश नाव, मार्ग आणि TLS ओळख याच क्रमाने तपासतात:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

चुकीच्या प्रमाणपत्रासह बरोबर पत्ता कठोर क्लायंटला अजूनही अपयशी करतो, म्हणून निराकरण चालले की अनुप्रयोग ज्या नावाची अपेक्षा करतो ते तपासा. सेवा केवळ कार्यालयीन श्रेणीतून नाही, VPN पत्त्यावरूनही कनेक्शन स्वीकारते याची खात्री करा. डोमेन व्याप्ती, सर्व्हर आणि मालक कनेक्शनच्या दस्तऐवजीकरणात लिहा. अन्यथा हे अपयश भेटणारी पुढची व्यक्ती तुम्ही नुकतेच टाळलेले तेच जागतिक संपादन करेल.