एक लिनक्स मशीन पर दो VPN: परिणाम मिलाए बिना हर एक को अलग जाँचें
दो हरे आइकन कोई तुलना नहीं हैं। हर टनल को उसके अपने नेमस्पेस में रखें, अपेक्षा पहले लिखें, और परिणाम पर भरोसा करने से पहले पथ साबित करें।
दो हरे कनेक्शन आइकन तुलना जैसे लगते हैं और आमतौर पर संयोग होते हैं। अगर परीक्षण अनुरोध दोनों में से कोई भी टनल इस्तेमाल कर सकता था, तो परिणाम अच्छे से अच्छे हाल में उनमें से एक का वर्णन करता है और बुरे से बुरे हाल में किसी का नहीं। हर अवलोकन को एक नेटवर्क संदर्भ, एक इच्छित गंतव्य और परीक्षण चलने से पहले लिखी गई अपेक्षा दें। अपने आप प्रबंधित लिनक्स मशीन पर, नामित नेटवर्क नेमस्पेस उस अलगाव को खरीदने का सबसे सस्ता तरीका हैं।
दो हरी बत्तियाँ कोई तुलना नहीं हैं
एक नेमस्पेस रूटिंग तालिकाओं, इंटरफ़ेस और नेटवर्क स्टैक की स्थिति को अलग करता है, इसलिए एक के भीतर शुरू हुआ अनुरोध चुपचाप दूसरे की टनल उधार नहीं ले सकता। जो यह अलग नहीं करता वह प्रोसेसर, भौतिक अपलिंक या होस्ट पर चलने वाला रिज़ॉल्वर डेमॉन है। पिछली उसी खाई में इनमें से अधिकांश परीक्षण बिना किसी को पता चले विफल हो जाते हैं। जो लुकअप नेमस्पेस छोड़कर होस्ट के रिज़ॉल्वर से पूछता है, वह ऐसा उत्तर लौटाता है जिसका परीक्षणाधीन टनल से कोई संबंध नहीं है।
यह प्रक्रिया पहले से तैयार और स्वीकृत दो परीक्षण नेमस्पेस, कार्यशील बाहरी कनेक्टिविटी और समर्थित क्लाइंट मानकर चलती है। यह कुछ बनाती नहीं, कुछ दर्ज नहीं करती और कोई कॉन्फ़िगरेशन नहीं बदलती। जब क्लाइंट को पूरा डेस्कटॉप सत्र चाहिए या वह उसके बाहर चलने से इंकार करे, तब अलग वर्चुअल मशीनें ही ईमानदार विकल्प रहती हैं।
पहले रन से पहले अपेक्षा तय करें
हर संदर्भ के लिए तय करें कि सफलता कैसी दिखती है: रिज़ॉल्वर, सेवा का नाम, अपेक्षित पता और टनल गिरने पर माँगा गया व्यवहार। उन नियोजित मानों को उनके अपने स्तंभ में रखें, क्योंकि योजना और अवलोकन मिलाने वाला रिकॉर्ड समय-मुहर वाला कल्पना है। नीचे दी गई जाँच-सूची वही आकार है जो रिकॉर्ड को चाहिए, और पहले कनेक्शन से पहले हर पंक्ति भरने योग्य होनी चाहिए।
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
रिज़ॉल्वर की वायरिंग को उस रिकॉर्ड में अपनी पंक्ति चाहिए, क्योंकि झूठ बोलने की सबसे अधिक संभावना इसी क्षेत्र में है। नेमस्पेस से जुड़ी फ़ाइलें, जैसे /etc/netns/vpn-a/resolv.conf कमांड नेमस्पेस के भीतर चलने पर अपने सामान्य पथों पर दिखती हैं, जैसा कि iproute2 का नेमस्पेस संदर्भ बताता है, लेकिन नाम-सेवा स्विच कॉन्फ़िगरेशन और इसके द्वारा शुरू किया गया कोई भी स्थानीय रिज़ॉल्वर अब भी लुकअप को होस्ट की ओर खींच सकते हैं।
एक समय में एक टनल, दूसरी डिस्कनेक्ट
B के नीचे रहते हुए A को उसके मौजूदा मालिक के माध्यम से जोड़ें, फिर प्रशासनिक संदर्भ से नीति, रूट और चुना गया पथ देखें। नीचे दिए तीन कमांड स्थिति पढ़ते हैं; केवल अंतिम एक नाम-सेवा से संपर्क करता है, और इनमें से कोई भी एप्लिकेशन अनुरोध नहीं भेजता।
sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internalरूट लुकअप गंतव्य के बारे में एक काल्पनिक प्रश्न का उत्तर देता है, इसलिए यह नहीं दिखा सकता कि सेवा ट्रैफ़िक स्वीकार करती है। इन दो प्रकार के साक्ष्यों को अलग स्तंभों में रखें, क्योंकि अस्वीकृत कनेक्शन के साथ स्वस्थ रूट एक वास्तविक और सामान्य परिणाम है। फिर असली एप्लिकेशन के साथ एक हानिरहित अधिकृत अनुरोध भेजें, जिसे A के संदर्भ में उसके सामान्य गैर-विशेषाधिकार प्राप्त उपयोगकर्ता के रूप में शुरू किया गया हो, प्रमाणपत्र सत्यापन और एप्लिकेशन प्रमाणीकरण अक्षुण्ण रखते हुए, और सेवा द्वारा देखे गए स्रोत पते के साथ परिणाम दर्ज करें। A को उसके मालिक के माध्यम से डिस्कनेक्ट करें और B के लिए पूरी बेसलाइन दोहराएँ, अपने किए किसी भी कॉन्फ़िगरेशन बदलाव को नोट करते हुए, वरना दोनों बेसलाइन तुलनीय नहीं रहेंगी।
दोनों ऊपर, फिर एक समय में एक नीचे
स्थिर स्थिति आसान हिस्सा है। दोनों टनल जुड़ी होने पर हर संदर्भ का लुकअप और एप्लिकेशन अनुरोध दोहराएँ, फिर एक टनल तोड़ें और दूसरी जाँचें। जब कनेक्शन का क्रम ही प्रश्न हो तो उल्टे क्रम में फिर से जुड़ें।
sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20कैप्चर उन बहसों को तय करता है जिन्हें एप्लिकेशन परिणाम तय नहीं कर सकता: यह दिखाता है कि अनुरोध उस इंटरफ़ेस से निकला जिसकी आपको अपेक्षा थी या किसी बिल्कुल और से। हर संक्रमण के लिए मालिक की क्रिया, समय-मुहर, रूट परिणाम, नाम परिणाम और एप्लिकेशन परिणाम दर्ज करें। फिर प्रभावित नेमस्पेस के भीतर सुरक्षित-बंद होने की आवश्यकता जाँचें, क्योंकि अलगाव कोई किल स्विच नहीं है। नेमस्पेस दो टनलों को अलग रखता है; जब उसकी प्रोफ़ाइल कहे कि ट्रैफ़िक रुकना चाहिए, तब यह किसी को भी ट्रैफ़िक ढोने से नहीं रोकता।
यह रिकॉर्ड क्या दावा कर सकता है और क्या नहीं
एक पास इस व्यवस्था के लिए, इस होस्ट पर, उस समय उन अवलोकनों को साबित करता है। यह एक डेस्कटॉप रूटिंग तालिका साझा करने वाले दो क्लाइंटों के बारे में कुछ नहीं कहता, और दोनों टनलों के भार ढोते समय थ्रूपुट के बारे में भी कुछ नहीं कहता। ये अलग परीक्षणों वाले अलग प्रश्न हैं, और तुलना उतनी ही अच्छी है जितना हर पंक्ति से जुड़ा संदर्भ।
विफलताओं को रिकॉर्ड में सफलताओं के बगल में रखें, यह चिह्नित करते हुए कि उस समय कौन सी टनल ऊपर थी। जो साफ़ पन्ना मापन के समय की स्थिति छिपाता है वह उसे दिखाने वाले बदसूरत पन्ने से बुरा है। रिकॉर्ड को बाद में दोबारा उपयोगी बनाता है संदर्भ, स्कोर नहीं।
एक मशीन पर दो टनलों की ईमानदार तुलना हो सकती है, पर केवल उतने ही संदर्भों में जितने आपने वास्तव में नियंत्रित किए। उससे आगे कुछ भी बगल में हरा आइकन लगी एक इच्छा है।