सर्वर या क्लाइंट: दोहरी भूमिका वाले 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

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