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