नेटवर्क नेमस्पेसमा WireGuard: सकेट किन पछि पर्यो

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

लक्षण: सही नेमस्पेस, तर प्याकेट छैनन्

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

कारण यो हो कि अनुप्रयोगका भित्री प्याकेट सारिएको उपकरणसम्म पुग्छन्, र उपकरणले तिनलाई अर्को नेटवर्क सन्दर्भको सकेटबाट पठाउन खोज्छ। यसले प्रयोग गर्ने अन्तर्निहित मार्ग र त्यसमा लागू हुने हरेक फायरवाल नियम उपकरण बनेको नेमस्पेसको हो।

यो सार्ने कामको त्रुटि होइन र पीयरको गलत कन्फिगरेसन पनि होइन। कर्नेल कार्यान्वयन यसै गरी काम गर्छ, र WireGuard का लागि नेमस्पेस कागजातले बनाउने नियम सिधै वर्णन गर्छ।

सकेटको जन्मस्थान किन छ

WireGuard उपकरणसँग यसको इन्क्रिप्टेड ढुवानीका लागि एटा UDP सकेट हुन्छ, र त्यो सकेट उपकरण बन्ने नेमस्पेसमै खुल्छ। लिङ्क आदेशले इन्टरफेस सार्दा देखिने उपकरण सर्छ तर ढुवानी जहाँ सुरु भयो त्यहीँ रहन्छ। त्यसपछि दुई वस्तुका मालिक फरक हुन्छन्।

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

सकेट चाहेको ठाउँमै त्यो बनाउनुहोस्

समाधान यो हो कि उपकरण बाहिर बनाएर सार्नुको सट्टा लक्ष्य नेमस्पेसभित्रै बनाउनुहोस्। स्वीकृत नेमस्पेस पहिले नै छ र नाम प्रयोगमा छैन भनी मान्दै:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

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

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

मार्गका दुवै पक्ष पढ्नुहोस्

उपकरण सही ठाउँमा आएपछि दुवै निर्णय छुट्टाछुट्टै प्रमाणित गर्नुहोस्। अनुप्रयोगको सन्दर्भबाट भित्री खोजबाट सुरु गर्नुहोस्, त्यसपछि सकेटको मालिक सन्दर्भबाट बाहिरी मार्ग जाँच्नुहोस्:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

यदि भित्री खोज टनेलबाट टुङ्गिन्छ र बाहिरी क्याप्चरले इन्क्रिप्टेड आदानप्रदान देखाउन्छ भने दुवै आधा भाग मिल्छन्। यदि क्याप्चर खाली छ भने सकेट अझै अन्तै छ, वा त्यसको नेमस्पेसको अन्तर्निहित मार्ग अन्तिम बिन्दुसम्म पुग्छदैन।

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