OpenVPN मा पहिले नै बनाइएको tun: दुई स्वामित्व मोडेलको तुलना

कसैले tun1 पहिले नै बनाएको छ, प्रोफाइलले dev tun1 भन्छ, र जडान अझै जोडिँदैन। होस्टमा नामको उपस्थितिले लगभग केही भन्दैन, किनकि जोडिने कुरा नेमस्पेस, उपकरणको प्रकार, लिङ्कको मालिक को हो र डेमनलाई के गर्न अनुमति छ भन्नेमा निर्भर गर्छ। उपकरण पुनः प्रयोग गर्दा पूर्वनिर्धारित कन्फिगरेसनले लुकाएको निर्णय पनि थोपिन्छ: कुन घटकले ठेगाना र रुटहरू लेख्छ। दुई व्यवस्थाको असफलताका तरिका कन्फिगरेसनका लाइनभन्दा धेरै फरक हुन्छन्, त्यसैले प्रोफाइल सम्पादन गर्नु अघि निर्णय गर्नुहोस्।

नाम जोडिनु होइन

dev tun1 OpenVPN सँग त्यो नामको इन्टरफेस माग्छ, र परम्परागत युजरस्पेस बिल्डहरूले त्यो खोल्न प्रयास गर्नेछन्। यदि नामले सामान्य tun वा tap ढाँचा पछ्याउँदैन भने प्रोफाइललाई मिल्ने dev-type पनि चाहिन्छ, किनकि प्रकार कहिल्यै स्ट्रिङबाट अनुमान गरिँदैन। TAP उपकरण अर्को लेबलको TUN उपकरण होइन: गलत जोड्दा या त सिधै असफल हुन्छ, या कसैले अपेक्षा नगरेका फ्रेम बोक्ने लिङ्क बन्छ। अरू सबैभन्दा पहिले प्रकार जाँच्नुहोस्, किनकि हरेक पछिल्लो जाँचले दुवै पक्ष यसमा सहमत छन् भनी मान्छ। त्यसपछि, प्रक्रियाले उपकरण साँच्चै खोल्न सक्छ भन्ने पुष्टि गर्नुहोस्, केवल देख्न सक्छ भन्ने होइन।

dev tun1
dev-type tun

नेटवर्क इन्टरफेस र /dev/net/tun फरक वस्तु हुन्: एउटा नेमस्पेसभित्रको लिङ्क हो, अर्को युजरस्पेस प्रोग्रामले जोडिनका लागि प्रयोग गर्ने क्यारेक्टर उपकरण। Linux TUN/TAP कागजातले त्यो जोडिने मार्ग र स्थायी उपकरणको स्वामित्व नियम वर्णन गर्छ। ip link चलाउन सक्ने root शेलले शेलसँग विशेषाधिकार छ भन्ने मात्र प्रमाणित गर्छ, डेमनसँग छ भन्ने होइन। उपकरण नोडको स्वामित्व, सेवाको क्षमता समूह र यो जुन प्रयोगकर्ताअन्तर्गत चल्छ — सबै मिल्नुपर्छ, खोल्ने काम सफल हुनु अघि।

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

लिङ्क कसले कन्फिगर गर्छ: दुई स्वामित्व मोडेल

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

ifconfig-noexec ले ठेगाना मात्र समेट्छ: राउटिङ तालिका अछुत रहन्छ, र रुट कन्फिगरेसन route-noexec को हो। दुई निर्देशनलाई अलग नियन्त्रण र अलग मालिकका रूपमा लिनुहोस्, किनकि एउटा सेट गरेर अर्को मान्नु आधा-कन्फिगर भएका लिङ्कको सामान्य स्रोत हो। प्रत्येक तहका लागि ठ्याक्कै एक मालिक छान्नुहोस्, ठेगाना एउटा ठाउँमा र रुट एउटा ठाउँमा। नेटवर्क प्रबन्धक र VPN सहायकले दुवैले ठेगाना लेख्दा, जडान टुट्दा अर्को पक्ष अझै भर पर्ने अवस्था मेटिन्छ।

महत्त्वपूर्ण नेमस्पेसबाट उपकरण जाँच्नुहोस्

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

ip -details link show dev tun1
ip tuntap show

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

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

दुई प्रकारको स्थायित्व

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

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

केवल स्टार्टअप जाँच्दा के बिग्रन्छ

स्वामित्वको सम्झौता पहिलो परीक्षामा उत्तीर्ण भएर अन्तिममा असफल हुन सक्छ, जसले स्टार्टअपलाई एक्लै कमजोर जाँच बनाउँछ। यसको सट्टा दुई संक्रमण हेर्नुहोस्: नरम रिसेट, र पूर्ण रोकावटपछिको सुरुवात।

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

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