एउटै होस्टमा OpenVPN को सर्भर चल्दा क्लाइन्ट अड्किन्छ
एउटै होस्टमा दुई OpenVPN इन्स्ट्यान्स एउटै स्थानीय पोर्ट र एउटै रुट तालिकाका लागि भिड्छन्। पोर्ट पिन गर्नुहोस्, यन्त्रहरू अलग गर्नुहोस् र कुन तालिका जित्छ जाँच्नुहोस्।
मसँग एउटा ल्याब मेसिन थियो जसले टाढाको साइटबाट टनेल स्वीकार गर्थ्यो र सँगै विक्रेताको नेटवर्कमा डायल पनि गर्थ्यो। आउटबाउन्ड प्रोफाइल हप्तासम्म चलेको थियो। इनबाउन्ड सर्भर थपिएपछि, आउटबाउन्ड जोडियो र त्यसपछि केही सेकेन्डभित्र ट्राफिक पठाउन छोड्यो, वा ठेगाना पहिले नै प्रयोगमा छ भन्ने त्रुटिसँग सुरु हुन इन्कार गर्यो। कन्फिग फाइलहरू परिवर्तन भएका थिएनन्; होस्टले पोर्ट र रुटबारे आफ्नै राय भएको दोस्रो OpenVPN प्रक्रिया मात्र पायो।
यो असफलता अनियमित होइन, र यो प्रमाणीकरणको समस्या होइन। एउटै मेसिनमा दुई डेमन एउटै स्थानीय सकेट र एउटै रुटिङ तालिकाका लागि प्रतिस्पर्धा गर्छन्, र अन्तिममा सुरु हुने वा पुनः जोडिने सामान्यतया जित्छ। यी दुई टक्करमध्ये तपाईंसँग कुन छ भन्ने थाहा हुनुले पहिले कहाँ हेर्ने भन्ने निर्धारण गर्छ।
लक्षण उल्टो पढ्नुहोस्
टनेल कहिले मर्छ भन्नेबाट सुरु गर्नुहोस्। सुरुमा बाइन्ड त्रुटिले सुन्ने पक्षतिर संकेत गर्छ: केही पहिले नै त्यो पोर्टको मालिक छ, र OpenVPN त्यो साझा गर्नुको सट्टा सुरु हुन इन्कार गर्छ। माथि आएर त्यसपछि चुप हुने टनेलले रुटिङतिर संकेत गर्छ, किनकि अर्को इन्स्ट्यान्सले राखेको रुटले बाहिरी जडानका प्याकेटहरूलाई तिनको बाटोबाट तान्न सक्छ।
दुवै अवस्थाले एउटै प्रयोगकर्ता गुनासो उत्पन्न गर्छन्, त्यसैले पुनः प्रयास लूप र वाचडग स्क्रिप्टले केही ठीक गर्दैनन्। तिनीहरू क्लाइन्टलाई फेरि उही द्वन्द्वमा जोड्छन्। पहिलो उपयोगी प्रश्न यो हो कि ट्राफिक रोकिँदा प्रक्रिया अझै चलिरहेको छ कि छैन।
प्रत्येक इन्स्ट्यान्सका लागि एउटा सकेट र एउटा यन्त्र
सुन्ने सर्भरले आफ्नो पोर्ट बाइन्ड गर्छ; आउटबाउन्ड क्लाइन्टलाई पनि आफ्नो इन्क्याप्सुलेटेड ट्राफिकका लागि स्थानीय पोर्ट चाहिन्छ। जब दुवै एउटै होस्टमा बस्छन्, क्लाइन्टको पूर्वनिर्धारित व्यवहार सर्भरको पोर्टसँग ठोक्किन सक्छ। क्लाइन्टको स्थानीय पोर्ट पिन गर्न सकिन्छ, र जहाँ साथीलाई निश्चित स्रोत पोर्ट चाहिँदैन त्यहाँ बाइन्डिङ छोड्न सकिन्छ:
lport 1195
nobind
dev tun1ती संख्याहरू उदाहरण हुन्, आवश्यकता होइन। महत्त्वपूर्ण कुरा यो हो कि क्लाइन्टले सर्भरको पोर्टका लागि प्रतिस्पर्धा गर्न छोड्छ र प्रत्येक इन्स्ट्यान्सले छुट्टै टनेल यन्त्र पाउँछ। tun0 साझा गर्ने दुई डेमन, तिनका पोर्ट फरक भए पनि, एकअर्काको यन्त्र अवस्था माथि लेख्छन्, त्यसैले प्रत्येक टनेलका लागि एउटा यन्त्र वैकल्पिक होइन।
nobind क्लाइन्ट पक्षको हो। सर्भरले अझै बाइन्ड गर्न र सुन्नुपर्छ, त्यसैले लाइन सर्भर कन्फिगमा प्रतिलिपि नगर्नुहोस्, र जसको साथी निश्चित स्रोत पोर्टमा फिल्टर गर्छ त्यस्तो क्लाइन्टमा बाइन्डिङ बन्द नगर्नुहोस्।
पूर्वनिर्धारित रुटका लागि एउटा मालिक छान्नुहोस्
केवल एउटा जडानले पूर्वनिर्धारित रुट स्थापना गर्न सक्छ। यदि दुवै प्रोफाइलले सबै ट्राफिक रिडाइरेक्ट गर्छन् भने, दोस्रो जडानले पहिलोलाई चुपचाप प्रतिस्थापन गर्छ, र पहिलो टुटेको देखिन्छ। या त आउटबाउन्ड टनेल विभाजित राख्नुहोस् र विक्रेताका प्रिफिक्स मात्र पठाउनुहोस्, वा त्यसलाई छुट्टै रुटिङ तालिका दिनुहोस्।
ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2माथिका ठेगाना र तालिका नम्बर प्लेसहोल्डर हुन्। नियम थपेपछि तुरुन्तै, VPN सर्भरको आफ्नै ठेगाना अझै सामान्य तालिकाबाट समाधान हुन्छ भनी पुष्टि गर्नुहोस्; बाहिरी ट्रान्सपोर्ट समात्ने तालिकाले जुन टनेलको रक्षा गर्नुपर्ने थियो त्यसैलाई तोड्छ, र त्यसपछिको पुनः जडान लूप अविश्वसनीय प्रदायकजस्तो देखिन्छ।
पुनः जडान र रिबुट सहनुपर्ने सेटअपका लागि, नेटवर्क नेमस्पेस बढी बलियो सीमा हो। दोस्रो क्लाइन्ट आफ्नै नेमस्पेसमा आफ्नै इन्टरफेस र रुटसँग चल्छ, र सीमा पार गर्नुपर्ने सेवाहरू मात्र खुला गरिन्छन्। होस्टले एउटा पूर्वनिर्धारित रुट राख्छ, र नेमस्पेसको पुनः जडानले त्यो पुनः लेख्न सक्दैन।
स्थिति लाइनले होइन, तालिकाले प्रमाणित गर्नुहोस्
जोडिएको रिपोर्ट गर्ने क्लाइन्टले आफ्नो नियन्त्रण च्यानल मात्र प्रमाणित गर्छ। प्रत्येक जडान अघि र पछि रुटिङ अवस्था क्याप्चर गर्नुहोस्, त्यसपछि कर्नेललाई सोध्नुहोस् कि वास्तविक गन्तव्यले कुन यन्त्र प्रयोग गर्नेछ:
ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194दोस्रो टनेल सुरु हुँदा विक्रेताको ठेगानाका लागि छानिएको यन्त्र परिवर्तन भयो भने, तपाईंसँग रुट टक्कर छ। दुवै प्रक्रिया एउटै स्थानीय पोर्टमा देखिए भने, तपाईंसँग सकेट टक्कर छ। दोस्रोबिना पहिलो ठीक गर्दा असफलता अर्को पुनः जडानतिर मात्र सर्छ।
पोर्ट, यन्त्र, तालिका र रुट मालिक होस्टको रनबुकमा लेख्नुहोस्। अन्यथा तेस्रो टनेल थप्ने अर्को व्यक्तिले उही टक्कर फेरि पत्ता लगाउनेछ, र देखिने एकमात्र प्रमाण अरू कसैको डेमन पुनः सुरु नहुँदासम्म चल्ने जडान हुनेछ।