ip netns exec और DNS: नेमस्पेस के अंदर नाम क्यों विफल होते हैं

एक कमांड VPN नेमस्पेस के अंदर 10.8.0.5 तक बिना किसी शिकायत के पहुँच जाता है, और वही कमांड उसी क्षण विफल हो जाता है जब वह होस्टनाम का उपयोग करता है। नेमस्पेस के अपने इंटरफ़ेस, रूट और सॉकेट हैं; उसकी अपनी रिज़ॉल्वर फ़ाइल नहीं है। जब तक कोई वहाँ एक न रखे, अंदर का प्रोसेस होस्ट की /etc/resolv.conf पढ़ता है और ऐसे सर्वर से पूछता है जो उस नेटवर्क स्टैक से पहुँच से बाहर हो सकता है।

यह रूटिंग की समस्या नहीं, फ़ाइल-चयन की समस्या है, और ठीक इसीलिए संख्यात्मक गंतव्य अब भी काम करता है।

वह रिज़ॉल्वर दृश्य जाँचें जो प्रोसेस को वास्तव में मिलता है

यह न मानें कि आपने जो शेल इस्तेमाल किया वह उस प्रोसेस के बराबर है जिसे आप डीबग कर रहे हैं। एक ग्राफ़िकल एप्लिकेशन, एक systemd यूनिट और एक कंटेनर में से हर एक भिन्न माउंट या नेटवर्क संदर्भ में प्रवेश कर सकता है। उसी लॉन्च पथ से लुकअप चलाएँ, और अंदर से रिज़ॉल्वर फ़ाइल प्रिंट करें।

ip netns add से बने नेमस्पेस के लिए केवल-पढ़ने की जाँच छोटी है:

ip netns exec vpn cat /etc/resolv.conf

ध्यान दें कि परिणाम पहुँच योग्य पता, कोई loopback स्टब, या भिन्न पहुँच वाले स्थान की ओर इशारा करने वाला सिम्बॉलिक लिंक बताता है या नहीं।

exec सहायक वास्तव में क्या माउंट करता है

ip-netns टूल हर नेमस्पेस का कॉन्फ़िगरेशन /etc/netns/NAME/ के अंतर्गत दस्तावेज़ करता है। जब वह कोई प्रोसेस लॉन्च करता है, तो सहायक एक माउंट नेमस्पेस बनाता है और उन फ़ाइलों को उनके सामान्य पथों के ऊपर bind-mount करता है, ताकि प्रोसेस नेमस्पेस-विशिष्ट प्रति देखे। यह इसी विशिष्ट लॉन्चर की सुविधा है। किसी दूसरे मार्ग से, जैसे unshare या कंटेनर रनटाइम के ज़रिए, नेटवर्क नेमस्पेस में प्रवेश करना इसे अपने आप दोहराता नहीं है।

यहाँ जाल loopback रिज़ॉल्वर है: 127.0.0.53 का अर्थ नेमस्पेस का अपना loopback है, होस्ट का स्टब नहीं। जो स्टब केवल होस्ट नेमस्पेस में सुनता है वह नए में सेवा नहीं बनता।

ऐसा रिज़ॉल्वर चुनें जहाँ तक नेमस्पेस पहुँच सके

फ़ाइल जिस भी सर्वर का नाम ले, उसे अब भी उस नेमस्पेस से एक रूट चाहिए। कोई सार्वजनिक रिज़ॉल्वर सार्वजनिक नामों का उत्तर दे सकता है और फिर भी आंतरिक ज़ोन के लिए विफल हो सकता है, क्योंकि निजी सेवा केवल टनल से पहुँच योग्य है। रूट को पते के साथ ही जाँचें, लुकअप विफल हो जाने के बाद नहीं।

अपना रिज़ॉल्वर रखने वाले एप्लिकेशन, जैसे DNS over HTTPS इस्तेमाल करने वाला कोई, फ़ाइल को पूरी तरह अनदेखा कर सकते हैं। यदि टूल की अपनी DNS सेटिंग है, तो resolv.conf बदलने से उस पर असर नहीं पड़ेगा, और नेमस्पेस कभी समस्या थी ही नहीं।

फ़ाइल सही जगह लिखें

/etc/netns/NAME/resolv.conf के अंतर्गत नेमस्पेस-विशिष्ट फ़ाइल बनाएँ और लॉन्चर को उसे प्रस्तुत करने दें। इसे न्यूनतम रखें: एक या दो पहुँच योग्य सर्वर और कार्य के लिए ज़रूरी खोज डोमेन। प्रोसेस के एक समूह के लिए सोचा गया दृश्य ठीक करने के लिए होस्ट की जनरेट की गई रिज़ॉल्वर फ़ाइल संपादित न करें, क्योंकि इससे मशीन का हर एप्लिकेशन बदल जाता है। यदि होस्ट रिज़ॉल्वर मैनेजर इस्तेमाल करता है, तो उससे लड़ने के बजाय उसी मैनेजर के ज़रिए नेमस्पेस का पथ कॉन्फ़िगर करें।

रनबुक में फ़ाइल की सामग्री दर्ज करें। वरना अगला व्यक्ति होस्ट के रिज़ॉल्वर को जाँचेगा, काम करता उत्तर देखेगा और निष्कर्ष निकालेगा कि नेमस्पेस ठीक है।

पूरा पथ फिर से जाँचें

नेमस्पेस के अंदर संख्यात्मक पते, आंतरिक नाम और सार्वजनिक नाम के साथ परीक्षण करें। यह क्रम पहुँच को रिज़ॉल्यूशन से अलग करता है और आंतरिक ज़ोन को सार्वजनिक से अलग करता है। फिर नेमस्पेस दोबारा बनाएँ और दोहराएँ, क्योंकि केवल चल रहे इंस्टेंस में मौजूद फ़ाइल उसके साथ गायब हो जाती है।

पुष्टि करें कि फ़ाइल शेल को नहीं, प्रोसेस को मिल रही है। ऐसा लुकअप जो इंटरैक्टिव शेल से काम करता है और सेवा से विफल होता है, माउंट-संदर्भ से जुड़ा निष्कर्ष है, और अगली घटना से पहले उसे शून्य से दोबारा खोजने के बजाय लिख लेना बेहतर है।