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

बदल फक्त तेव्हाच स्वीकारा जेव्हा तीन गोष्टी एकाच वेळी खऱ्या असतात: नवीन येणारे जोडणी पूर्ण होते, पुढे पाठवलेले अनुप्रयोग इच्छित निर्गमातून त्याच्या गंतव्यस्थानी पोहोचते, आणि दोन्ही प्रक्रिया अजूनही त्यांच्या अपेक्षित सहकाऱ्याची नोंद देतात। तीनपैकी एक अपयशी झाल्यास, तुम्ही चुकीचे इन्स्टन्स किंवा चुकीचा मार्ग बदलला आहे, आणि पुढचे पाऊल दुसरे काही पुन्हा सुरू करणे नाही तर युनिट पुन्हा वाचणे आहे।