एउटै होस्टमा OpenVPN सर्भर र क्लाइन्ट: क्लाइन्टहरू किन झर्छन्

पहिले नै VPN सर्भर चलिरहेको मेसिनमा क्लाइन्ट प्रोफाइल थप्नुहोस्, र पहिलो क्षति मूल सेवाकै हुनेछ। नयाँ टनेल कहिल्यै स्थापित नहुन सक्छ, वा सर्भरका विद्यमान क्लाइन्टहरू चुपचाप जवाफ पाउन छाड्दा त्यो माथि आउन सक्छ। दुई टकरावले दुवै नतिजा दिन्छन्: पहिले नै प्रयोगमा रहेको टनेल पूल, र नयाँ क्लाइन्ट-आधाले स्थापना गरेको, सम्पूर्ण तालिका ढाक्ने पूर्वनिर्धारित रुट। यीमध्ये कुनैले पनि OpenVPN त्रुटि सन्देश दिँदैन, त्यसैले असफलतालाई सर्भरको समस्या पढिन्छ।

एउटा मेसिन, दुई भूमिका, र जवाफ कहाँ जानुपर्छ भन्नेमा दुई असंगत जवाफ।

एउटै पूल, दुई सर्भर: कसले जित्छ

प्रत्येक सर्भर इन्स्ट्यान्सलाई आफ्नै टनेल सबनेट चाहिन्छ। server 10.8.0.0 255.255.255.0 जस्तो लाइन दोस्रो कन्फिगरेसनमा प्रतिलिपि गर्दा दुवै इन्स्ट्यान्सले एउटै प्रिफिक्स पाउँछन्, र नतिजा या त सुरु गर्न इन्कार या एक सर्भरका क्लाइन्टले अर्कोले पनि आफ्नो मान्ने ठेगाना पाउने चुपचाप प्रतिस्पर्धा हुन्छ। फरक UDP पोर्ट र फरक यन्त्र नामले सहयोग गर्दैन, किनकि दुवैले ठेगाना-क्षेत्र छुँदैनन्। दोस्रो पूल बदल्नुहोस्, र रुटहरूले यसको उल्लेख गर्ने सबै ठाउँमा बदल्नुहोस्।

सम्पादन गर्नुअघि के सक्रिय छ सूची बनाउनुहोस्: ip -4 addr show ले टनेल यन्त्रहरू सूचीबद्ध गर्छ, ss -lunp ले सुन्नेहरू सूचीबद्ध गर्छ, र systemctl list-units ले युनिटहरूको नाम बताउँछ। टनेल ठेगानामा एक नजरले पूलहरू ठोक्किन्छन् कि भन्ने टुंगो लगाउँछ।

क्लाइन्ट प्रोफाइलले तालिकामा के थप्छ

क्लाइन्ट-आधा जोडिएपछि तुरुन्तै रुट लेख्छ। redirect-gateway def1 ले पूर्वनिर्धारित रुटलाई 0.0.0.0/1 प्लस 128.0.0.0/1 मा विभाजन गर्छ, दुवै नयाँ यन्त्रबाट रुट हुन्छन्, साथै टाढाको सर्भरतर्फ जाने होस्ट रुट जो जानाजान भौतिक इन्टरफेसमा पिन गरिएको हुन्छ। त्यो पिन टनेलले आफ्नै यातायातका लागि बाटो राख्नका लागि हो। बाँकी सबै, स्थानीय सर्भरले आफ्नै क्लाइन्टहरूलाई दिनुपर्ने जवाफसमेत, अब नयाँ पूर्वनिर्धारितलाई पछ्याउँछ र टाढाको लिङ्कबाट बाहिर जान्छ।

त्यसैले दोस्रो टकराव भाँचिएको टनेल होइन। त्यो तालिकाको गलत ठाउँमा बसेको काम गर्ने टनेल हो।

भूमिकाहरू अलग राख्ने तीन उपाय

सबैभन्दा कम हस्तक्षेपको उपायले पूर्वनिर्धारित रुटलाई क्लाइन्ट प्रोफाइलबाट बाहिर राख्छ: टाढाका प्रिफिक्सका लागि route-nopull र स्पष्ट route लाइनहरू, ताकि स्थानीय तालिका तपाईंले मागेको ठाउँमा मात्र बदलियोस्। अर्को कदम स्थानीय टनेल सबनेटलाई छुट दिने नीति-नियम हो, जसले पूर्वनिर्धारित रुट हुँदा पनि स्थानीय क्लाइन्टहरूलाई जवाफ आएको इन्टरफेसबाटै बाहिर जान दिन्छ। सबैभन्दा पूर्ण उपाय क्लाइन्ट भूमिकाका लागि छुट्टै नेटवर्क नेमस्पेस हो, जसले साझा तालिका पूरै हटाउँछ र रेखदेखका लागि दोस्रो राउटिङ सन्दर्भ चाहिन्छ।

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

दुई इन्स्ट्यान्समध्ये कुन दोषी हो

क्लाइन्ट इन्स्ट्यान्स रोक्नुहोस् र मूल क्लाइन्टहरू फेरि जाँच्नुहोस्। तुरुन्तै सुधार भयो भने त्यो राउटिङ हो, सर्भर होइन। क्लाइन्ट फर्काएर ip route get प्रयोग गरी एउटै जवाफ ट्रेस गर्नुहोस्, जसलाई स्रोत र गन्तव्य दुवै ठेगाना दिइएको छ, जसले कर्नेलले छान्ने बाटो देखाउँछ, त्यसपछि tcpdump -ni any port 1194 ले प्याकेटहरूले वास्तवमा कुन इन्टरफेस प्रयोग गर्छ हेर्नुहोस्। सर्भरको स्थिति फाइल, जो हरेक केही सेकेन्डमा status निर्देशनमार्फत लेखिन्छ, जोडिएका क्लाइन्टहरूको सूची र दुवै दिशाका बाइट काउन्टर बोक्छ।

ती काउन्टरहरू एक-अर्काको विरुद्धमा पढ्नुहोस्। बाहिर गएर कहिल्यै नफर्कने ट्राफिक ह्यान्डसेकको समस्या होइन, राउटिङको जवाफ हो।