तुमची /etc/hosts नोंद VPN च्या DNS पर्यंत का पोहोचत नाही

तुम्ही /etc/hosts मध्ये एक नाव जोडले, VPN ला जोडले आणि नोंद सर्वांना दिसेल अशी अपेक्षा केली। तसे होत नाही, आणि आश्चर्य सहसा दुसऱ्या लक्षणासह येते: नाव तुमच्या मशीनवर रिझोल्व्ह होते आणि सहकाऱ्याच्या मशीनवर अयशस्वी होते, जे तुटलेल्या VPN DNS सेवेसारखे दिसते आणि प्रत्यक्षात hosts फाइल ती ज्या उद्देशाने तयार केली होती तेच करत असते। hosts फाइल स्थानिक नाव-रिझोल्यूशन कॉन्फिगरेशन आहे, झोन अपडेट नाही, आणि सामान्य VPN कनेक्शनमध्ये काहीही ती अपलोड करत नाही।

Hosts हे स्थानिक ओव्हरराइड आहे, झोन अपडेट नाही

फाइल म्हणजे नाव-सेवा लायब्ररी DNS सर्व्हरला विचारण्यापूर्वी किंवा त्याऐवजी पाहतात अशा मॅपिंगची यादी। 10.40.0.20 build.corp.example सारखी ओळ फक्त त्या एका मशीनवरील अनुप्रयोग काय निष्कर्ष काढतात ते बदलते। ती रेकॉर्ड तयार करत नाही, बोगद्यातून प्रवास करत नाही, आणि बोगदा ज्या DNS सर्व्हरकडे निर्देश करतो त्याला तिच्या अस्तित्वाची कल्पनाही नसते।

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

दोन आदेश, दोन वेगवेगळे घटक

हा वाद थांबवण्याचा सर्वात वेगवान मार्ग म्हणजे फरक दोन आदेशांमध्ये दृश्यमान करणे, दोन्ही hosts नोंद असलेल्या क्लायंटवर चालवले जातात:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

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

क्रम कॉन्फिगर करण्यायोग्य आहे, आणि विशिष्ट वितरणाबद्दल काहीही निष्कर्ष काढण्यापूर्वी तो तपासणे योग्य आहे। /etc/nsswitch.conf मधील hosts: ओळ पहा; hosts: files dns आधी फाइल्स पाहतो। फक्त क्रम बदलण्यासाठी ते उदाहरण कार्यरत कॉन्फिगरेशनवर कॉपी करू नका, कारण वास्तविक सिस्टम्स उदाहरणात नसलेले अतिरिक्त स्रोत आणि सशर्त सेवा नोंदी अनेकदा सूचीबद्ध करतात।

systemd-resolved चाचणी अस्पष्ट करतो

systemd-resolved वापरणाऱ्या सिस्टममध्ये स्थानिक स्टब hosts डेटाबेसमधूनही नावे पुरवतो। म्हणून 127.0.0.53 ला क्वेरी करणे ही दूरच्या सर्व्हरची स्वतंत्र चाचणी नाही, जरी ती DNS क्वेरीसारखी दिसते आणि तशीच वागते। रिझोल्व्हरला काय माहीत आहे आणि कोणत्या सर्व्हरना विचारेल हे तुम्ही याद्वारे निश्चित करू शकता:

resolvectl query build.corp.example
resolvectl status

status आउटपुट प्रत्येक लिंकसाठी DNS सर्व्हरना नावे देते, आणि अशा प्रकारे VPN लिंकला रिझोल्व्हर मिळाला का हे कळते। तो प्रश्न hosts नोंदीपासून वेगळा आहे आणि खाजगी नाव एका व्यक्तीऐवजी प्रत्येक वापरकर्त्यासाठी अयशस्वी होते तेव्हा विचारण्यायोग्य प्रश्न तोच आहे।

अनुप्रयोग आणखी एक स्तर जोडू शकतात। स्वतःच्या DNS-over-HTTPS सेटिंग्ज असलेला ब्राउझर, स्वतःच्या रिझोल्व्हर कॉन्फिगरेशन असलेला कंटेनर, किंवा प्रक्रियेच्या संपूर्ण आयुष्यभर लुकअप कॅश करणारे रनटाइम—प्रत्येकजण सिस्टमपेक्षा वेगळे उत्तर देऊ शकतात। एकच आदेश मशीनवरील प्रत्येक प्रोग्रामचे वर्णन करतो असे गृहीत धरण्याऐवजी तुम्हाला महत्त्वाचा असलेला अनुप्रयोग तपासा।

VPN मध्ये नाव प्रत्यक्षात काय सामायिक करते

खाजगी नाव सर्वांसाठी कार्य करायचे असेल तर सर्वांच्या रिझोल्व्हरला पोहोचता येईल असा मालक आवश्यक आहे। स्वच्छ उत्तर म्हणजे नोंद व्यवस्थापित झोनमध्ये प्रकाशित करणे आणि तो झोन VPN च्या इच्छित DNS मार्गाने रिझोल्व्ह करण्यायोग्य करणे। मग नोंदीकडे सत्याचा एकच स्रोत, ऑडिट ट्रेल आणि जीवनचक्र असते, आणि कोणत्या लॅपटॉपवर स्थानिक ओव्हरराइड आहे हे कोणालाही लक्षात ठेवावे लागत नाही।

hosts फाइल्स वितरित करणे हा कायदेशीर पर्याय आहे, आणि ते नाव-सेवा नसून एंडपॉइंट व्यवस्थापन आहे। तुम्ही तो निवडल्यास, फाइल फ्लीट व्यवस्थापित करणाऱ्याने तैनात, आवृत्तीबद्ध आणि काढून टाकली पाहिजे, आणि डिझाइनमध्ये तसेच वर्णन केले पाहिजे। “VPN ते सांभाळते” हे त्या प्रक्रियेचे वर्णन नाही।

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

रिझोल्व्ह झालेले नाव मार्ग नाही

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

म्हणून जेव्हा अहवाल “नाव रिझोल्व्ह होते पण सेवा पोहोचण्यायोग्य नाही” असतो, तेव्हा सिस्टम लुकअपची VPN DNS सर्व्हरला केलेल्या स्पष्ट क्वेरीशी तुलना करा, नंतर मिळालेला पत्ता सेवा प्रत्यक्षात वापरत असलेल्या पत्त्याशी तपासा। systemd-resolved संदर्भ तो ज्या स्थानिक स्रोतांकडे पाहतो त्यांचे दस्तऐवजीकरण करतो, आणि त्या तुलनेसाठी आवश्यक नकाशा हाच आहे।

नंतर ओव्हरराइड त्याच्या मालकामार्फत दुरुस्त करा। तुमच्या स्वतःच्या hosts फाइलमधून एक ओळ काढल्याने तैनाती स्क्रिप्टकडून तीच ओळ मिळालेल्या बारा लॅपटॉपसाठी काहीही होत नाही, आणि लोकांना प्रत्यक्षात असलेली या समस्येची आवृत्ती हीच आहे।