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