एउटै OpenVPN क्लाइन्टमा दुई सेवा ठेगाना: iroute र lo

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

उपनाम स्थानीय छ, स्वामित्व टाढा छ

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

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

तपाईंका नोटहरूमा पनि दुई दायरा अलग राख्नुहोस्। उदाहरणका ठेगानाहरू अभिलेखन मान हुन्, र तिनलाई साँचो LAN सँग ओभरल्याप गर्नु काम गर्ने सेटअपलाई बिग्रिएको देखाउने सबैभन्दा छिटो उपाय हो।

क्लाइन्टमा ठेगाना स्थायी रूपमा थप्नुहोस्

सेवा ठेगानालाई होस्ट प्रिफिक्ससहित लूपब्याकमा राख्नुहोस्, ताकि होस्टले यसलाई पुग्नुपर्ने सबनेटको रूपमा नभई स्थानीय इनपुटको रूपमा लिन्छ। ip address add 10.66.0.10/32 dev lo एउटा ठेगानाका लागि त्यो गर्छ, र दोस्रो ठेगानाका लागि आदेश दोहोर्याउँदा दुई सेवा मोडेल हुन्छन्।

यसलाई एक पटकको परीक्षणको रूपमा चलाउनुहोस्, त्यसपछि होस्टको नेटवर्क कन्फिगरेसनको स्वामित्व भएको ठाउँमा सार्नुहोस्, किनकि रनटाइम थप रिबुटमा हराउँछ र पुनः जडानहरूबीच प्रतिलिपिहरू जम्मा हुन्छन्। नेटवर्कपछि क्रमबद्ध systemd इकाइ एउटा विकल्प हो, र वितरणको नेटवर्क म्यानेजर अर्को। तपाईंले जे रोज्नुभए पनि, एप्लिकेसन बाइन्ड हुनुअघि ठेगाना हुनैपर्छ, नत्र सेवा गलत सकेटमा उठ्छ। म्यानुअल आदेशपछि होइन, रिबुटपछि ip address show dev lo ले जाँच्नुहोस्।

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

हबले वास्तवमै पढ्ने CCD फाइलमा यसको दाबी गर्नुहोस्

सर्भरमा स्वामित्वको घोषणा प्रमाणित सामान्य नामले छानिएको प्रति-क्लाइन्ट फाइलमा जान्छ, client-config-dir ले नाम दिएको डाइरेक्टरीभित्र। लाइन iroute 10.66.0.10 255.255.255.255 हो, प्रति ठेगाना एक, र यसले सर्भरलाई त्यो गन्तव्यका लागि कुन पियरले ट्राफिक लिनुपर्ने बताउँछ।

दुई विवरणले यसलाई चुपचाप तोड्छन्। फाइलको नाम सर्भरले वास्तवमै प्रयोग गर्ने नामसँग मिल्नुपर्छ, जो username-as-common-name खेलमा हुँदा फरक हुन्छ। र iroute क्लाइन्ट कन्फिगरेसन डाइरेक्टरी कन्फिगर गरिएको TUN मोडमा मात्र लागू हुन्छ, त्यसैले ब्रिज गरिएको तैनाथीमा त्यही लाइनले केही गर्दैन। विद्यमान फाइलमा लाइनहरू थप्नुहोस्, त्यसलाई प्रतिस्थापन नगर्नुहोस्, किनकि यसमा पहिले नै स्थिर ठेगाना वा push विकल्पहरू हुन सक्छन्। OpenVPN 2.6 सन्दर्भ ले डाइरेक्टरी र स्वामित्व निर्देश दुवैको अभिलेख गर्छ।

हबको आफ्नै कर्नेललाई पनि ती गन्तव्यहरूसम्म मार्ग चाहिन्छ, स्थानीय रूपमा उत्पन्न ट्राफिक टनेल प्रक्रियामा प्रवेश गर्न। सर्भर कन्फिगरेसनमा route 10.66.0.10 255.255.255.255 ले सर्भर आफैंले उत्पन्न गर्ने ट्राफिक समेट्छ, जबकि अन्य क्लाइन्टहरूलाई गन्तव्य आफैं सिक्न push "route 10.66.0.10 255.255.255.255" चाहिन्छ।

राउटिङ र अधिकार अलग रहन्छन्। धकेलिएको मार्गले क्लाइन्टलाई प्याकेट कहाँ पठाउने भन्छ र केही दिँदैन; सेवाले अझै कलरलाई आफ्नै सर्तमा स्वीकार गर्नुपर्छ।

इनपुट नीति र जवाफ मार्ग जाँच्नुहोस्

उपनाममा ठेगाना दिइएको प्याकेट स्वामित्व भएको होस्टमा स्थानीय इनपुटको रूपमा पुग्छ, त्यसैले प्रश्न यो हो कि स्थानीय फायरवालले त्यो स्रोत र पोर्टलाई अनुमति दिन्छ कि दिँदैन। पूरै ठेगाना खोल्नुको सट्टा VPN स्रोत दायराबाट विशेष सेवा पोर्टलाई अनुमति दिनुहोस्।

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

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

ठेगाना र स्वामित्व अलग-अलग जाँच्नुहोस्

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

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