OpenVPN iroute र कर्नेल रुट: कुन चाहिँ हराइरहेको छ?

10.77.20.0/24 का लागि प्याकेटले OpenVPN सर्भरमा दुई अलग निर्णय लिन्छ: अपरेटिङ सिस्टमले यसलाई VPN इन्टरफेसमा सुम्पनुपर्छ, र OpenVPN ले कुन जोडिएको क्लाइन्ट त्यो प्रिफिक्सको मालिक हो भनी जान्नुपर्छ। कर्नेल रुट नभए प्याकेट टनेलअघि नै खस्छ, र पीयर रुट नभए त्यसपछि खस्छ। दुवै असफलता टाढाको LAN बाट एउटै देखिन्छन्, र तपाईंसँग कुन छ भनी निदान गर्न हरेक तर्फ एक आदेश चाहिन्छ।

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

दुई निर्णय, एक रुट होइन

10.77.20.0/24 एउटै क्लाइन्टको पछाडि रहेको साइट-देखि-साइट लिङ्कको कल्पना गर्नुहोस्। सर्भरको कर्नेल रुट, उदाहरणका लागि ip route add 10.77.20.0/24 dev tun0, मिल्ने प्याकेटहरू टनेल उपकरणमा पठाउँछ। त्यसपछि OpenVPN ले क्लाइन्ट कन्फिगरेसन डिरेक्टरीका iroute प्रविष्टिबाट बनेको आफ्नै आन्तरिक तालिका हेर्छ, कुन पीयर जडानले ती लिन्छ भनी निर्णय गर्न। कर्नेल रुट नभए प्याकेट कहिल्यै प्रक्रियासम्म पुग्दैन, र पीयर रुट नभए यो प्रक्रियासम्म पुग्छ र कतै जाँदैन।

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

iroute कहाँ पर्छ र के भन्छ

प्रविष्टि क्लाइन्टको common_name का आधारमा नामाकरण गरिएको प्रति-क्लाइन्ट फाइलमा, client-config-dir मुनि, iroute 10.77.20.0/24 का रूपमा जान्छ। फाइल नामको मिलान सजावटी होइन: OpenVPN प्रमाणित पहिचान खोज्छ र ठ्याक्कै त्यही नामको फाइल पढ्छ, त्यसैले site-a नामको फाइल त्यो क्लाइन्टमा मात्र लागू हुन्छ जसको सामान्य नाम site-a छ। यस्तो फाइल नभएका क्लाइन्टलाई पूर्ण रूपमा अस्वीकार गर्नुपर्ने भए ccd-exclusive थप्नुहोस्, प्रत्येक क्लाइन्ट साइट गेटवे हुँदा यो सही सेटिङ हो। प्रत्येक गेटवेका लागि एक फाइल राख्नुहोस् र तपाईंले साँच्चै जारी गर्ने प्रमाणपत्र विषयको नामबाट त्यसको नाम राख्नुहोस्।

टाढाको LAN लाई दोष दिनुअघि सर्भरबाट प्रविष्टि जाँच्नुहोस्। स्थिति फाइलले जोडिएका क्लाइन्टहरूलाई तिनका सामान्य नामसहित सूचीबद्ध गर्छ, र --verb 4 मा चल्ने सर्भरले पीयर जोडिँदा iroute स्थापना भएको लग गर्छ। जोडिने बेला केही नदेखिए फाइल गलत डिरेक्टरीमा छ वा गलत पहिचानको नाम दिइरहेको छ।

जाल: फाइल छ, पहिचान गलत

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

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

पीयरभन्दा परको बाटो पूरा गर्नुहोस्

पीयरको स्वामित्व बाटोको बीचमा हो, अन्त्यमा होइन। क्लाइन्टले टनेलबाट प्याकेट आफ्नो LAN मा फर्वार्ड गर्नुपर्छ, अर्थात् त्यो होस्टमा IP फर्वार्डिङ सक्रिय हुनुपर्छ र फायरवाल नियमले पार जान दिनुपर्छ। टाढाको LAN का होस्टलाई टनेल ठेगानाका लागि फर्किने बाटो चाहिन्छ: या त गेटवेतिर फर्कने रुट, वा क्लाइन्ट पक्षमा जानाजान डिजाइन गरिएको NAT। वितरणको पूर्वनिर्धारित मान मान्नुको सट्टा sysctl net.ipv4.ip_forward ले क्लाइन्टमा फर्वार्डिङ सेटिङ पुष्टि गर्नुहोस्।

अन्य VPN क्लाइन्टले त्यो सबनेटमा पुग्नुपर्ने भए व्यवस्था फेरि बढ्छ: सर्भरलाई client-to-client चाहिन्छ, र ती क्लाइन्टले प्रिफिक्स टनेलबाट रुट गर्नुपर्छ। यीमध्ये केही पनि सर्भरको आफ्नै रुट तालिकाबाट आउँदैन।

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