एक Pi, दोन OpenVPN इन्स्टन्स: प्रत्येक युनिट काय वाचते
एका Pi वरचे दोन OpenVPN डेमन वेगळ्या कॉन्फिग फाइल्स वाचतात आणि वेगळ्या हुक्समधून बाहेर पडतात। प्रत्येक इन्स्टन्स नकाशावर आणा, नंतर पेलोड मार्ग स्वतंत्रपणे तपासा।
प्रोफाइलला हात लावण्यापूर्वी OpenVPN प्रक्रिया मोजा। रोमिंग वापरकर्ते स्वीकारतानाच अपस्ट्रीम सेवेला डायल करणारा Pi दोन डेमन चालवतो, आणि त्यातील प्रत्येक जण तुम्ही टाइप केलेल्या इन्स्टन्स नावाने निवडलेली कॉन्फिग फाइल वाचतो। पॅकेज टेम्प्लेट्स नंतर प्रत्येक डेमनला स्वतःची कार्यरत डिरेक्टरी, स्वतःची रनटाइम स्थिती फाइल आणि स्वतःचे टनेल उपकरण देतात। हे विभाजन चुकीचे केल्यास, चालू असलेली प्रक्रिया कधीही उघडत नाही अशा फाइलमधील बरोबर सेटिंग बदलण्यात तुम्ही एक संध्याकाळ घालवाल।
प्रत्येक इन्स्टन्स नाव स्वतःची फाइल निवडते
OpenVPN 2.6 सोबत येणाऱ्या युनिट फाइल्समध्ये, स्टार्ट आर्ग्युमेंट्समध्ये @ चिन्हानंतरच्या मजकुराने भरला जाणारा इन्स्टन्स प्लेसहोल्डर असतो। सर्व्हर टेम्प्लेट सर्व्हर कॉन्फिग डिरेक्टरीतून चालते आणि तिथल्या %i.conf विरुद्ध आपला आर्ग्युमेंट सोडवते, तर क्लायंट टेम्प्लेट क्लायंट डिरेक्टरीतून तेच करते। त्यामुळे [email protected] सर्व्हर डिरेक्टरीतील admits.conf वाचते आणि [email protected] क्लायंट डिरेक्टरीतील uplink.conf वाचते, आणि त्या नावांपैकी कोणाचाही दुसऱ्या डिरेक्टरीत काही अर्थ नाही।
पॅकेजने अपस्ट्रीम डीफॉल्ट्स ठेवले आहेत असे गृहीत धरण्याऐवजी मशीनवरच नकाशा तपासा। डिस्ट्रिब्युशनचा drop-in कार्यरत डिरेक्टरी किंवा कॉन्फिग आर्ग्युमेंट पूर्णपणे बदलू शकतो।
systemctl cat [email protected]
systemctl cat [email protected]त्या आउटपुटमधील WorkingDirectory ओळ आणि कॉन्फिग आर्ग्युमेंट वाचा, कारण कोणती फाइल लोड होते हे फक्त सक्रिय युनिट ठरवते। ExecStart ला --config जोडणारा drop-in, टेम्प्लेटचा मार्ग बरोबर दिसत असूनही टेम्प्लेटवर जिंकतो। स्थानिक ओव्हरराइड सुरू आहे का हे जाणून घ्यायचे असेल तर फ्रॅगमेंट आणि drop-in चे मार्ग विचारा। दोन्ही भूमिका एकाच फाइलवर सोडवल्या गेल्या तर, एकच प्रक्रिया सर्व्हर आणि क्लायंट दोन्ही होण्याचा प्रयत्न करत आहे, आणि त्या फाइलमधील नंतरचा पर्याय शांतपणे जिंकतो।
स्थानिक वाहतूक आणि फॉरवर्ड केलेला पेलोड वेगळ्या हुक्सना भिडतात
सर्व्हरचे प्रत्येक रोमिंग वापरकर्त्याशी असलेले एन्क्रिप्टेड कनेक्शन Pi वरच तयार होते, म्हणून त्याची बाहेरील उत्तरे स्थानिक आउटपुट हुकमधून बाहेर पडतात। क्लायंटचे अपस्ट्रीम पीअरशी असलेले कनेक्शनही स्थानिकरीत्या तयार केलेले आउटपुट आहे, जरी ते दूरच्या नेटवर्कपर्यंत पोहोचत असले तरी। फॉरवर्ड केलेला पेलोड तिसरी श्रेणी आहे, आणि कर्नल पॅकेटसाठी बाहेर जाणारे उपकरण आधीच निवडल्यानंतरच त्याची जुळवणी करतो।
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
फॉरवर्ड चेनमध्ये बाहेर जाणाऱ्या इंटरफेसशी जुळणारा नियम, राउटिंगने आधीच त्या इंटरफेसला दिलेले पॅकेट परवानगी देऊ शकतो किंवा टाकून देऊ शकतो, पण तो कधीही इंटरफेस निवडत नाही। एक होस्ट एक टनेल संपवून दुसरे सुरू करतो तेव्हा, वापरकर्त्यांचा पेलोड अपस्ट्रीम टनेलमध्ये पाठवणारे धोरण आणि Pi च्या स्वतःच्या एन्क्रिप्टेड उत्तरांचे रक्षण करणारे धोरण या दोन वेगळ्या निर्णय असतात। ते योगायोगाने एकाच भौतिक NIC वर येतात, म्हणूनच त्यांचा गोंधळ होतो।
हा फरक सामान्य अर्धा-अपयश स्पष्ट करतो। वापरकर्ते जोडले जातात, हँडशेक पूर्ण होतो, आणि तरीही त्यांचा रहदारी चुकीच्या मार्गाने बाहेर पडतो, कारण हँडशेक स्थानिक होता आणि पेलोड फॉरवर्ड होता आणि दोन्हींपैकी फक्त एकच तपासला गेला।
आयात केलेला मार्ग तुमच्या वापरकर्त्यांना जाणारी उत्तरे गिळू शकतो
क्लायंट प्रोफाइलची सुरक्षा सेटिंग अपस्ट्रीम Pi च्या राउटिंग टेबलमध्ये काय push करू शकते हे ठरवते, आणि रुंद रीडायरेक्ट हा पर्याय कार्यरत दुहेरी-भूमिका होस्टला बिघडलेल्या होस्टमध्ये बदलतो। push केलेला मार्ग रोमिंग वापरकर्त्यांच्या सार्वजनिक पत्त्यांना व्यापत असल्यास, सर्व्हर त्यांच्याकडे तयार करणारी उत्तरे अंडरलेमधून बाहेर पडण्याऐवजी नव्या मार्गाने अपस्ट्रीम टनेलमध्ये जाऊ शकतात। लोक अनेकदा प्रदात्याकडे जाणारे टनेल अजूनही चालू आहे याची खात्री करून तिथेच थांबतात, कारण ती रहदारी टनेलची स्वतःची वाहतूक असते आणि बाकी सर्व चुकीचे वागत असतानाही ती वाहत राहते।
स्रोत किंवा mark आधारित धोरण हा दोन प्रवाह वेगळे ठेवण्याचा मार्ग आहे। OpenVPN चा Linux mark पर्याय डेमनच्या स्वतःच्या एन्क्रिप्टेड पॅकेटवर फायरवॉल mark लावतो, जो नंतर राउटिंग नियम समर्पित टेबलमध्ये पाठवू शकतो। सर्व्हरची बाहेरील उत्तरे नेहमी एकाच अंडरले पत्त्यावरून बाहेर पडत असतील तर स्रोत पत्तेही तितकेच चांगले काम करतात। दोन्ही दृष्टिकोनांना तो निवडत असलेल्या टेबलमध्ये वैध मार्ग आणि प्रदात्याच्या endpoint साठी अपवाद आवश्यक आहे, अन्यथा टनेल स्वतःच वर येत नाही।
कोणताही नियम लिहिण्यापूर्वी उत्तर प्रत्यक्षात कोणत्या मार्गाने जाईल हे कर्नलला विचारा। खालील पत्ते Pi च्या अंडरले पत्त्यासाठी आणि एका रोमिंग वापरकर्त्याच्या सार्वजनिक पत्त्यासाठी प्लेसहोल्डर आहेत।
ip rule show
ip route get 198.51.100.7 from 192.0.2.10विभाजन तपासा, नंतर एका वेळी एक भूमिका थांबवा
तीन प्रवाह स्वतंत्रपणे तपासा, कारण यशस्वी हँडशेक इतर दोनांबद्दल काहीही सिद्ध करत नाही। नवीन आंतरिक कनेक्शन स्वीकारा, एक परवानगी असलेले अॅप्लिकेशन अपस्ट्रीम निर्गमातून पाठवा, आणि दोन्ही प्रक्रिया अजूनही त्यांच्या पीअर्पर्यंत पोहोचतात याची खात्री करा।
नंतर क्लायंट भूमिका थांबवा आणि सर्व्हर भूमिका काय टिकवून ठेवते ते पहा। एका इन्स्टन्ससाठी असलेला पण दोन्हींवर लागू झालेला मार्ग किंवा mark नियम शोधण्याचा हा सर्वात स्वस्त मार्ग आहे।
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerतुम्हाला हे पाहायचे आहे की क्लायंट भूमिका बंद असताना लिसनर अजूनही बांधलेला आहे, टनेल उपकरण अजूनही आहे आणि लॉग नव्या त्रुटींपासून मुक्त आहे। क्लायंट थांबवल्याने सर्व्हरची विद्यमान वापरकर्त्यांना जाणारी उत्तरेही तुटत असतील, तर दोन्ही भूमिका अशा गोष्टी सामायिक करतात जी एकाच भूमिकेपुरती मर्यादित असायला हवी होती। प्रत्येक बदलाने कोणत्या इन्स्टन्सला, कोणत्या कॉन्फिग फाइलला आणि कोणत्या प्रवाहाच्या मालकाला स्पर्श केला ते नोंदवा, अन्यथा हा होस्ट पुढे डीबग करणारी व्यक्ती तेच शोध शून्यापासून पुन्हा करेल।