एउटा 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 गरिएको मार्गले रोमिङ प्रयोगकर्ताका सार्वजनिक ठेगाना ढाक्छ भने, सर्भरले उनीहरूतर्फ उत्पन्न गर्ने जवाफहरू underlay बाट बाहिर जानुको सट्टा नयाँ मार्ग पछ्याउँदै अपस्ट्रिम टनेलमा प्रवेश गर्न सक्छन्। मानिसहरू प्रायः प्रदायकतर्फको टनेल अझै चल्छ भनी पुष्टि गरेर त्यहीँ रोकिन्छन्, किनकि त्यो ट्राफिक टनेलकै आफ्नै यातायात हो र बाँकी सबै गलत व्यवहार गर्दा पनि बगिरहन्छ।
स्रोत वा mark आधारित नीति नै दुई प्रवाह अलग राख्ने उपाय हो। OpenVPN को Linux mark विकल्पले डेमनका आफ्नै इन्क्रिप्टेड प्याकेटमा फायरवाल mark लगाउँछ, जसलाई राउटिङ नियमले त्यसपछि समर्पित तालिकामा पठाउन सक्छ। सर्भरका बाहिरी जवाफ सधैं एउटै underlay ठेगानाबाट बाहिर जाँदा स्रोत ठेगानाले पनि उत्तिकै राम्रो काम गर्छ। दुवै दृष्टिकोणलाई यसले छान्ने तालिकामा वैध मार्ग र प्रदायकको endpoint का लागि अपवाद चाहिन्छ, नत्र टनेल आफै माथि आउँदैन।
कुनै पनि नियम लेख्नुअघि जवाफ वास्तवमा कुन बाटो जान्छ भनी कर्नेललाई सोध्नुहोस्। तलका ठेगानाहरू Pi को underlay ठेगाना र एउटा रोमिङ प्रयोगकर्ताको सार्वजनिक ठेगानाका लागि प्लेसहोल्डर हुन्।
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तपाईं हेर्न चाहनुभएको कुरा हो — क्लाइन्ट भूमिका बन्द हुँदा लिसनर अझै बाँधिएको, टनेल उपकरण अझै उपस्थित र लग नयाँ त्रुटिबाट मुक्त। क्लाइन्ट रोक्दा सर्भरका विद्यमान प्रयोगकर्तातर्फका जवाफ पनि कट्छ भने, दुवै भूमिकाले एउटामा मात्र सीमित हुनुपर्ने कुरा साझा गरिरहेका छन्। प्रत्येक परिवर्तनले कुन इन्स्टेन्स, कुन कन्फिग फाइल र कुन प्रवाहको मालिकलाई छोयो लेख्नुहोस्, नत्र यो होस्ट अर्को पटक डिबग गर्ने व्यक्तिले त्यही खोज शून्यबाट दोहोर्याउनेछ।