एउटै Linux होस्टमा दुई OpenVPN सुरुङ: मार्ग कसको?

दुई प्रोफाइल जोडिएका छन्, र तीमध्ये एउटा अर्कोका लागि भएको ट्राफिक चुपचाप बोकिरहेको छ। Linux होस्टले दुवै OpenVPN क्लाइन्ट एकैचोटि सजिलै चलाउन सक्छ। जुन गर्न सक्दैन त्यो हो — कुन प्रक्रियाले कुन प्रिफिक्स दाबी गर्न पाउँछ भन्ने तपाईंको तर्फबाट तय गर्नु। त्यो निर्णय दोस्रो सुरुङ माथि आउनुअघि लिनुपर्छ, कुनै स्रोतले जवाफ दिन छोडेपछि होइन।

दोस्रो लिंकले गर्नुपर्ने कामबाट सुरु गर्नुहोस्

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

यी तीन फरक कन्फिगरेसन हुन्, र ती मिसिन्छन् किनभने तीनवटै एउटै तरिकाले सुरु हुन्छन्: दोस्रो प्रोफाइल र सफल जडान। पहिले इच्छित मिलाइ लेख्नुहोस्, त्यसपछि त्यतातिर कन्फिगर गर्नुहोस्। मनसायको एक वाक्यले एक घण्टाको प्याकेट क्याप्चर बचाउँछ।

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

पहिलो आदेशले चलिरहेका इन्स्टेन्सहरू सूचीबद्ध गर्छ, म्यानेजरबाहिर हातले सुरु गरिएकासमेत। दोस्रोले हालको पूर्वनिर्धारित दाबी छाप्छ, र त्यो त्यो अवस्था हो जुन तपाईंले पछि व्याख्या गर्नुपर्नेछ।

ओभरल्याप हुने पूल राउटिङअघि नै फुट्छन्

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

स्थानीय LAN पनि हेर्नुहोस्। एउटा सुरुङले खोल्ने 192.168.1.0/24 नम्बरको घरायसी LAN ले पनि त्यही अस्पष्टता निम्त्याउँछ, र लक्षण हो — जडान कहिल्यै नसकिँदै समाधान हुने होस्टनाम। मार्गहरू छाप्नुअघिसम्म त्यो नाम समाधान खराबीजस्तो देखिन्छ।

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

क्लाइन्ट छुनुअघि दुवै आउटपुटलाई दुई सर्भर कन्फिगरेसनसँग तुलना गर्नुहोस्। प्रिफिक्सहरू ओभरल्याप भए, रोक्नुहोस् र पुनःक्रमाङ्कन गर्नुहोस्, किनभने जतिपटक रिस्टार्ट गरे पनि तिनीहरू अलग हुँदैनन्।

हरेक प्रोफाइललाई यसको युनिट र हरेक प्रिफिक्सलाई मालिक दिनुहोस्

हरेक प्रोफाइलले आफ्नै इन्स्टेन्स नाम र आफ्नै कन्फिगरेसन फाइल पाउँछ, त्यसैले office नामको इन्स्टेन्सले office.conf लोड गर्छ भने lab नामकोले lab.conf लोड गर्छ। डाइरेक्टरी सूचीमा भरोसा गर्नुको सट्टा सेवा म्यानेजरमार्फत त्यो म्यापिङ पुष्टि गर्नुहोस्, किनभने drop-in ले कुन फाइल लोड हुन्छ परिवर्तन गर्न सक्छ। म्यापिङ गलत भयो भने तपाईं नचलिरहेको प्रोफाइल ट्युन गर्दै हुनुहुन्छ।

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

मार्कहरूले जवाफहरूलाई आएको इन्टरफेसमै राख्छन्

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

प्रभावित इन्टरफेसका लागि सामान्यतया ढिलो रिभर्स-पाथ फिल्टरिङ हलुका गर्नुपर्छ, किनभने जवाफ मुख्य तालिकाले कहिल्यै नछान्ने लिंकबाट वैध रूपमा आउँछ। मार्कहरू साँघुरो राख्नुहोस् ताकि तिनले सुरुङहरूको आफ्नै इन्क्रिप्टेड ट्राफिक कहिल्यै नसमातून्, जसले सुरुङलाई यसैभित्रबाट पठाउनेछ।

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

अर्को थप्नुअघि विद्यमान नियमहरू पढ्नुहोस्। दोहोरिएका प्राथमिकता र बिर्सिएका तालिकाहरू नै मार्क नीतिको कुनै असर नभएको जस्तो देखिने सामान्य कारण हुन्।

एउटा लिंक रोकेर अलगाव प्रमाणित गर्नुहोस्

दुवै सुरुङ माथि हुँदा हरेक इन्टरफेसको ठेगाना, हरेक सुरुङपछाडिको एउटा होस्टसम्मको मार्ग, र असम्बन्धित गन्तव्यले लिने बाटो अभिलेख गर्नुहोस्। एउटा तालिका पढ्नुको सट्टा कर्नेलसँग खोजी माग्नुहोस्, किनभने एउटा तालिकाले कहिल्यै अन्तिम निर्णय देखाउँदैन।

त्यसपछि एउटा इन्स्टेन्स रोक्नुहोस् र अर्को चलिरहँदा त्यसको इन्टरफेस र मार्ग हराउँदै गएको हेर्नुहोस्। बाँचेकोमा भङ्ग हुनुको अर्थ दुवैले अझै कसैले नछुट्याएको उपकरण नाम, मार्ग वा फायरवाल नियम साझा गरिरहेका छन्।

रोकिएको प्रोफाइल फर्काएर त्यही जाँच दोहोर्याउनुहोस्। रिबुटपछिको पहिलो स्टार्टमा मात्र सुरुङ बाँच्यो भने तपाईं राउटिङ डिजाइन होइन, जीवनचक्र दोष हेर्दै हुनुहुन्छ।