मेज़बान के रूट छुए बिना नेमस्पेस में VPN राउटिंग जाँचें
तीन अनुकरणित भूमिकाएँ, तीन अलग संदर्भ और हर लिंक पर एक veth. मेज़बान को छूने से पहले नेमस्पेस लैब की तुलना मेज़बान-रूट लैब से करें।
दो लैब एक ही VPN टोपोलॉजी का मॉडल बना सकती हैं और पूरी तरह अलग तरीकों से विफल हो सकती हैं: एक नेटवर्क नेमस्पेस में रहती है, दूसरी मेज़बान के अपने रूट पर। नेमस्पेस संस्करण हर इंटरफ़ेस, रूट और सॉकेट को ऐसे संदर्भ में रखता है जिसे आप हटा सकते हैं, जबकि मेज़बान संस्करण तेज़ी से शुरू होता है और पीछे स्थिति छोड़ देता है। यही बची हुई स्थिति कारण है कि एक महीने बाद दूसरी लैब को दोहराना कठिन है। पहले सफ़ाई की तुलना करें, क्योंकि यह तय करती है कि आप प्रयोग दो बार चला सकते हैं या नहीं।
एक ही लैब बनाने के दो तरीके, और कब कौन जीतता है
मेज़बान-रूट लैब में आप जिस मशीन पर काम कर रहे हैं उसमें एक टनल इंटरफ़ेस और रूट जोड़ते हैं, इसलिए प्रयोग आपके shell, आपके पैकेज प्रबंधक और हर दूसरे कनेक्शन के साथ भाग्य साझा करता है। नेमस्पेस लैब में हर भूमिका को इंटरफ़ेस, पते, रूट और सॉकेट का अपना स्टैक मिलता है, और नेमस्पेस हटाने से वह सब हट जाता है। कोई भी मॉडल अधिक सही नहीं है, क्योंकि वे अलग सवालों के जवाब देते हैं। जब विषय राउटिंग और फ़ॉरवर्डिंग हो तो नेमस्पेस चुनें, और जब विषय यह हो कि एक डेस्कटॉप क्लाइंट कैसे एकीकृत होता है तो मेज़बान लैब चुनें।
| Aspect | Namespace lab | Host-route lab |
|---|---|---|
| Isolation | Full stack per role | Shares the host stack |
| Cleanup | Delete named namespaces | Manual route and rule removal |
| Realism | Strong for routing | Needed for GUI clients |
दोनों को मिलाना आम गलती है: केवल मेज़बान क्लाइंट के सामने जाँची गई नेमस्पेस लैब दोनों में से किसी भी व्यवस्था के बारे में कुछ साबित नहीं करती। पहला लिंक बनाने से पहले तय करें कि आप कौन सा सवाल पूछ रहे हैं।
हर भूमिका के लिए एक संदर्भ, जानबूझकर जुड़ा हुआ
हर भूमिका के लिए एक नेमस्पेस बनाएँ और हर veth जोड़ी का हर सिरा उस संदर्भ में ले जाएँ जो उसका मालिक है। पहले चार कमांड आकार देखने के लिए पर्याप्त हैं:
ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns clientलैब को ऐसी श्रेणियाँ दें जो मेज़बान पर किसी से भी ओवरलैप न हों, और शुरू करने से पहले लिख लें कि कौन सा नेमस्पेस किस पते का मालिक है। काम करती लैब को दो अलग रास्ते चाहिए: एक बाहरी रास्ता ताकि VPN एंडपॉइंट अपने साथी तक पहुँचे, और सुरक्षित संसाधन के लिए वापसी रास्ता। इन्हें दो निर्णयों के रूप में मॉडल करें, क्योंकि केवल बाहर जाने वाला आधा हिस्सा बनाने वाली लैब हैंडशेक परीक्षण पास करती है और एप्लिकेशन परीक्षण में विफल होती है।
फ़ॉरवर्डिंग भूमिका वह जगह है जहाँ लैब दिलचस्प होती हैं
एक भूमिका को फ़ॉरवर्ड करना होता है, जिसका अर्थ है उस नेमस्पेस के अंदर फ़ॉरवर्डिंग सक्षम करना और वह नियम जोड़ना जो डिज़ाइन को चाहिए। फ़ॉरवर्डिंग स्थिति हर नेमस्पेस के लिए होती है, इसलिए मेज़बान की सेटिंग लैब के लिए अप्रासंगिक है और लैब की सेटिंग बाहर नहीं रिसती, जैसा कि नेटवर्क नेमस्पेस दस्तावेज़ बताते हैं। WireGuard दस्तावेज़ित करता है कि एक इंटरफ़ेस और उसका बाहरी सॉकेट अलग-अलग नेमस्पेस में रह सकते हैं, जो एक उपयोगी युक्ति और खुद को उलझाने का शानदार तरीका है। यह न मानें कि इंटरफ़ेस हटाने-बढ़ाने से कनेक्शन का हर हिस्सा एक जैसे खिसकता है।
परीक्षण पैकेट के बाद फ़ॉरवर्डिंग काउंटर जाँचें, क्योंकि कभी न मिला नियम और पैकेट गिराने वाला नियम रूट तालिका में एक जैसे दिखते हैं। केवल काउंटर उन्हें अलग करते हैं।
आधार रेखा दर्ज करें, फिर एक रूट तोड़ें
यह दर्ज करके शुरू करें कि क्या मौजूद है, हर पंक्ति के बगल में संदर्भ लिखकर। नेमस्पेस पढ़ें, फिर वह रूट जो एक परीक्षण गंतव्य उनमें से किसी एक के अंदर लेगा, फिर उस लिंक पर काउंटर जो उसे ढोता है:
ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-gतीसरा कमांड वह है जिसे लोग छोड़ देते हैं, और सबूत वहीं रहता है: गिराए गए और त्रुटि काउंटर बताते हैं कि पैकेट फ़ॉरवर्डिंग भूमिका तक पहुँचा या नहीं। बदलाव के बाद वही तीन दृश्य कैप्चर करें, और सबूत आपकी याद नहीं, diff होने दें। फिर ठीक एक चीज़ तोड़ें, या रूट हटाकर या फ़ॉरवर्डिंग पथ पर इनकार नियम जोड़कर, और अपने अनुमानित लक्षण की पुष्टि करें: बिना उत्तर के पूरा हुआ हैंडशेक, या टाइमआउट की जगह नाम समाधान में विफलता। जो लैब केवल सफलता दिखाती है वह बहुत कम सिखाती है।
सफ़ाई ही अगली बार चलाने को दोहराने योग्य बनाती है
सफ़ाई को उन्हीं संसाधनों तक सीमित रखें जिनके नाम आपने दिए, क्योंकि पूरी फ़ायरवॉल रीसेट या मेज़बान रूट हटाना पुनरुत्पादनशीलता नहीं, दूसरी घटना है। टोपोलॉजी, सटीक कमांड और वे अवलोकन जिनकी आपको अपेक्षा थी, सहेजें, ताकि अगली बार वही विफलता दोबारा पैदा हो, न कि यह अनुमान लगाना पड़े कि पिछली स्थिति किस संदर्भ में थी। उस रिकॉर्ड के बिना लैब एक कहानी है, प्रक्रिया नहीं।
लैब के लिए स्थानीय रूप से बनाए गए क्रेडेंशियल इस्तेमाल करें, और उत्पादन खातों को साझा उदाहरणों से दूर रखें। फिर हर नेमस्पेस हटाएँ और पुष्टि करें कि मेज़बान दृश्य अपरिवर्तित है, यही इस मॉडल को चुनने का पूरा कारण है। जिस लैब को आप साफ़ तौर पर हटा नहीं सकते वह अतिरिक्त चरणों वाला मेज़बान परिवर्तन है।