VPN का लागि Linux नेटवर्क नेमस्पेस: तिनीहरूले के अलग गर्दैनन्

VPN लाई यसको आफ्नै नेमस्पेस भित्र सुरु गर्नुहोस्, त्यहाँ एउटा अनुप्रयोग चलाउनुहोस्, र ट्राफिक अझै होस्टको रुटबाट बाहिर जान्छ। केही पनि बिग्रिएको छैन: नेमस्पेसले यसमा प्रवेश गर्ने प्रक्रियाहरूलाई मात्र नियन्त्रण गर्छ, र चुहावट त्यो प्रक्रियाबाट आयो जुन कहिल्यै प्रवेश गरेन। इन्टरफेस, ठेगाना, रुट, फायरवाल नियम र सकेट नेमस्पेसको स्वामित्वमा हुन्छन्। फाइल, खाता र पहिले नै चलिरहेका सेवाहरू होइनन्, र अधिकांश आश्चर्यहरू यहीँबाट आउँछन्।

नेमस्पेसले के स्वामित्व राख्छ, र सकेट कहाँ जन्मन्छ

इन्टरफेसलाई नेमस्पेसमा सार्नुहोस् र होस्टले त्यो गुमाउँछ; भित्र सुरुङ बनाउनुहोस् र होस्टले देख्न सक्दैन। यही नेमस्पेसले सीमित VPN को कार्यविधि हो: यन्त्र र त्यसतर्फ देखाउने रुटहरू त्यस्तो सन्दर्भमा बस्छन् जहाँ केवल छानिएका प्रक्रियाहरू मात्र पुग्न सक्छन्। होस्टले आफ्नो पूर्वनिर्धारित रुट राख्छ, त्यसैले बाहिरको सबै अछुत रहन्छ।

WireGuard का लागि निर्माणको सन्दर्भ हालको स्थानजत्तिकै महत्त्वपूर्ण छ: UDP सकेट इन्टरफेस बनाइएको नेमस्पेसमै बाँधिन्छ, यन्त्र अन्तै सरेपछि पनि। इन्क्रिप्ट गरिएका प्याकेटहरू कुन राउटिङ तालिका पछ्याउँछन् भन्ने त्यही जन्मस्थानमा निर्भर हुन्छ। सकेट साथीतर्फ रुट नभएको सन्दर्भमा रह्यो भने इन्टरफेसले खोज्छ र हात मिलाउने कार्य कहिल्यै बाहिर जाँदैन। पहिले यसको जन्मस्थान, त्यसपछि हालको स्थान जाँच्नुहोस्।

नेमस्पेसले के अलग गर्दैन

यहाँ केहीले पनि फाइल प्रणाली, खाता वा गोप्य कुरा अलग गर्दैन, र तपाईंले नेमस्पेस बनाउनुभयो भनेर यीमध्ये कुनै पनि सीमा देखिँदैन। रिजोल्भर कन्फिगरेसन एउटा फाइल हो, त्यसैले भित्रको प्रक्रियाले अझै होस्ट रिजोल्भरतर्फ देखाउने सेटिङ पढ्न र त्यसले सङ्केत गर्ने रुटबाट आफ्नो प्रश्न बाहिर पठाउन सक्छ। अनुरोध पहिले नै चलिरहेको ब्रोकर वा प्रणाली सेवालाई सुम्पने अनुप्रयोगले पूर्ण रूपमा अर्को सन्दर्भको प्रक्रिया समावेश गर्छ। दुवै यस्ता अनुरोध हुन् जसको जवाफ दिन सीमा कहिल्यै बनेको थिएन।

समाधान /etc/netns/<name>/resolv.conf मा प्रति-नेमस्पेस फाइल हो, वा तयार पारिएको फाइलको bind mount, जुन भित्रबाट पुग्न सकिने रिजोल्भरतर्फ देखाउँछ। होस्टमा /etc/resolv.conf सम्पादन गर्दा नेमस्पेसले देख्ने कुरामा केही पनि बदलिँदैन।

प्रक्रियाहरूको राखाइ नै नियन्त्रण हो

तपाईंले पाउने अलगाव ठ्याक्कै भित्र सुरु गरिएका प्रक्रियाहरूको अलगाव हो। नेमस्पेसको exec सहायकमार्फत सुरु गरिएको शेल, र यसले उत्पन्न गर्ने सबै भित्रै रहन्छ; होस्ट सत्रबाट सुरु गरिएको डेस्कटप अनुप्रयोग रहँदैन। सन्दर्भ बनाउनुहोस्, यन्त्र सार्नुहोस्, त्यसपछि दुवै पक्ष प्रमाणित गर्नुहोस्:

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

नेमस्पेसको भित्रबाट पहिलो wg show र होस्टबाट दोस्रो पढ्नुहोस्, र तीमध्ये एउटाले मात्र साथीको सूची दिने अपेक्षा राख्नुहोस्। दुवैले दिए यन्त्र कहिल्यै सरेन; कुनैले नदिए त्यो अन्तै गयो। सुरु गर्ने सेवा प्रबन्धक भए सम्पादन गर्नुपर्ने unit फाइल हो, डेस्कटप सर्टकट होइन। नेमस्पेस सेटिङ नभएको unit ले डिमनलाई होस्ट सन्दर्भमा सुरु गर्छ र डिजाइनलाई चुपचाप रद्द गर्छ।

अनुप्रयोगको सन्दर्भबाट परीक्षण गर्नुहोस्

अनुप्रयोगले प्रयोग गर्ने त्यही बाइनरी र त्यही प्रयोगकर्ताद्वारा नेमस्पेस भित्र जाँच चलाउनुहोस्। DNS र दुवै ठेगाना परिवार समावेश गर्नुहोस्, किनकि तपाईंले कहिल्यै नसोचेको IPv6 रुट बाहिर जाने सामान्य बाटो हो। आफ्नै शेलबाट गरिएको परीक्षणले तपाईंको शेल अलग छ भन्ने मात्र प्रमाणित गर्छ।

त्यसपछि होस्टमा त्यही जाँच चलाउनुहोस् र उत्तरहरू फरक छन् भनी पुष्टि गर्नुहोस्: भित्र सुरुङको ठेगाना र अभिप्रेत निकास, बाहिर होस्ट रुट र कार्यालय निकास, र रिजोल्भर नामले। नेमस्पेसहरूलाई प्रोटोकलको सट्टा परिनियोजनअनुसार नाम दिनुहोस्, ताकि सफाइ स्क्रिप्टले दुईलाई भ्रमित नगरोस्।

फर्वार्डिङ, असफलता नीति र सफाइ

गेटवेका लागि फर्वार्डिङ जानाजानी खोल्नुहोस् र सुरुङ खस्दा के हुनुपर्छ भनी निर्णय गर्नुहोस्। नेमस्पेसले भित्र स्थापना गरिएका रुटहरू अवरोध गर्दैन, त्यसैले होस्टतर्फ वैकल्पिक रुट बनाए त्यो प्रयोग हुनेछ। यो नीति निर्णय हो, र कुनै अवरोधले परीक्षण गर्नुअघि यो लेखिनुपर्छ।

नेमस्पेसका नाम, इन्टरफेस र कन्फिगरेसन कसको हो भन्ने अभिलेख राख्नुहोस्, ताकि सफाइले परिनियोजनले बनाएको मात्र हटाओस्। रोलब्याकका क्रममा होस्ट नेटवर्किङ रिसेट गर्दा सफाइ अवरोधमा परिणत हुन्छ। पृष्ठ network_namespaces(7) छोटो छ र त्यो बाटो डिजाइन गर्नुअघि पढ्न लायक छ।