सर्भर कि क्लाइन्ट: दोहोरो भूमिकाको Pi मा कुन OpenVPN युनिट

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

युनिटको नाम त्यसले लोड गर्ने डाइरेक्टरीसँग मिलाउनुहोस्

Upstream 2.6 ले दुई टेम्प्लेट युनिट दिन्छ, [email protected] र [email protected]। सर्भर टेम्प्लेट /etc/openvpn/server मा सुरु हुन्छ र त्यहाँबाट %i.conf लोड गर्छ। क्लाइन्ट टेम्प्लेट /etc/openvpn/client मा सुरु हुन्छ। roaming नामको इन्स्ट्यान्स एकै समयमा दुवै ठाउँमा हुन सक्छ, सर्भर र क्लाइन्टको रूपमा, दुई असम्बन्धित कन्फिगरेसनसहित र स्ट्रिङबाहेक तिनीहरूबीच कुनै कडी नभई।

फाइल प्रणालीको सट्टा systemd लाई सोध्नुहोस्, किनकि प्याकेज बनाउनेहरूले काम गर्ने डाइरेक्टरी वा बाइनरीले पाउने आर्गुमेन्ट बदल्न सक्ने थप फाइलहरू थप्छन्।

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

पहिलो आदेशले प्रत्येक बनाइएको युनिट सूचीबद्ध गर्छ, असफल भई लोड भएर बसेकाहरू पनि। दोस्रोले युनिट फाइल कुनै पनि ओभरराइडसँगै छाप्छ। तेस्रो प्रश्न तय गर्ने दुई तथ्य हेर्ने सबैभन्दा छिटो बाटो हो: प्रक्रिया सुरु हुने डाइरेक्टरी, र त्यसलाई दिइएको कन्फिगरेसन मार्ग।

प्याकेटको दिशाले निर्णय गर्नुहोस्, इन्टरफेसको नामले होइन

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

त्यो भिन्नताले नियम कहाँ पर्छ भनी बताउँछ। अगाडि पठाउने चेनभित्रको इन्टरफेससँग मिल्ने नियमले राउटिङले पहिले नै छानेको ट्राफिकलाई मात्र अनुमति दिन्छ; त्यो कहिल्यै मार्ग छान्दैन। घुमन्ते प्रयोगकर्ताका प्याकेट गलत बाटोबाट बाहिर गएपछि जाँच्नुपर्ने चेन forward हो, output होइन।

सिद्धान्त बनाउनु अघि सकेट हेर्नुहोस्। udp/1194 मा बाँधिएको सर्भरले सुन्ने सकेट देखाउँछ। क्लाइन्टले प्रदायकको ठेगानासँग सम्बन्ध देखाउँछ र सुन्ने केही पनि देखाउँदैन।

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

एउटा इन्स्ट्यान्सको पूर्वनिर्धारित मार्गले अर्कोको जवाफ खोस्न सक्छ

माथिल्लो क्लाइन्टले धकेल्ने redirect-gateway ले मेसिनमा बाँकी सबैसँग प्रतिस्पर्धा गर्ने पूर्वनिर्धारित मार्ग राख्छ, जसमा सर्भरले घुमन्ते प्रयोगकर्ताहरूलाई पठाउने जवाफहरू पनि पर्छन्। OpenVPN ले सुरुङ पहुँचयोग्य रहनका लागि आफ्नै साथी ठेगानामा अपवाद बनाउँछ, तर त्यो अपवादले होटेलको सञ्जालमा बसेको फोनबारे केही भन्दैन।

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

सुरुङको अवस्थाको सट्टा स्थानीय निर्णय परीक्षण गर्नुहोस्, किनकि OpenVPN ले प्याकेट देख्नु अघि कर्नेलले स्रोत र इन्टरफेस छान्छ।

ip route get 203.0.113.44
ip rule show

एउटा भूमिका पुनः सुरु गर्नुहोस् र अर्को टिकिरहेको सिद्ध गर्नुहोस्

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

परिवर्तन अघि रोकिने सर्त लेख्नुहोस्: माथिल्लो सुरुङ गुम्दा घुमन्ते प्रयोगकर्ता अवरुद्ध हुन्छन्, कि Pi को आफ्नै माथिल्लो लिंकमा फर्किन्छ? DNS र IPv6 लाई पनि स्पष्ट उत्तर चाहिन्छ, किनकि धकेलिएको रिजोल्भर प्रायः त्यसलाई उपयोगी बनाएको मार्गभन्दा लामो बाँच्छ।

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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