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 अंतर्गत नेमस्पेस-विशिष्ट फाइल तयार करा आणि लॉन्चरला ती सादर करू द्या। ती किमान ठेवा: एक किंवा दोन पोहोचण्यायोग्य सर्व्हर आणि कामाला लागणारे शोध डोमेन। प्रक्रियांच्या एका गटासाठी ठेवलेले दृश्य दुरुस्त करण्यासाठी होस्टची तयार केलेली रिझोल्व्हर फाइल संपादित करू नका, कारण त्यामुळे मशीनवरील प्रत्येक ॲप्लिकेशन बदलते। होस्ट रिझोल्व्हर मॅनेजर वापरत असल्यास, त्याच्याशी भांडण्याऐवजी त्या मॅनेजरमार्फत नेमस्पेसचा मार्ग संरचित करा।

फाइलचा आशय रनबुकमध्ये नोंदवा। नाहीतर पुढची व्यक्ती होस्टचा रिझोल्व्हर तपासेल, काम करणारे उत्तर पाहील आणि नेमस्पेस ठीक आहे असा निष्कर्ष काढेल।

संपूर्ण मार्ग पुन्हा तपासा

नेमस्पेसच्या आत संख्यात्मक पत्ता, अंतर्गत नाव आणि सार्वजनिक नाव वापरून चाचणी करा। हा क्रम पोहोचक्षमतेला रिझोल्युशनपासून वेगळा करतो आणि अंतर्गत झोन सार्वजनिक झोनपासून वेगळे करतो। नंतर नेमस्पेस पुन्हा तयार करा आणि पुनरावृत्ती करा, कारण फक्त चालू इन्स्टन्समध्ये असलेली फाइल त्याच्यासोबत नाहीशी होते।

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