OpenVPN मा रुट कहाँ रहनुपर्छ: क्लाइन्टमा कि सर्भरमा?
सर्भर कन्फिगमा नाङ्गो रुटले सर्भर बदल्छ, क्लाइन्ट होइन। क्लाइन्ट फाइल, विश्वव्यापी push वा एउटा क्लाइन्टका लागि push छान्नुहोस् र के पुग्यो जाँच्नुहोस्।
तपाईं सर्भर कन्फिगरेसनमा route 10.60.0.0 255.255.255.0 थप्नुहुन्छ, पुनः सुरु गर्नुहुन्छ, ल्यापटप फेरि जोड्नुहुन्छ, र त्यो ल्यापटपबाट सबनेट अझै पुग्न सकिँदैन। लाइन स्वीकार भयो, सेवा सफा रूपमा सुरु भयो, र लगमा केही पनि गलत देखिँदैन। भएको कुरा यो हो कि रुट तपाईंले सम्पादन गरेको मेसिनमै स्थापना भयो: गेटवे अब त्यो प्रिफिक्समा पुग्न सक्छ भन्ने ठान्छ, जबकि क्लाइन्टलाई केही भनिएन। स्थान नै पूरा प्रश्न हो, र त्यही लाइन बस्न सक्ने चार ठाउँ छन्।
चार ठाउँ र प्रत्येक कसलाई मिल्छ
रुट क्लाइन्टको आफ्नै कन्फिगरेसनबाट थप्न सकिन्छ, विश्वव्यापी push मार्फत हरेक क्लाइन्टलाई दिन सकिन्छ, क्लाइन्ट-विशिष्ट फाइलमार्फत एउटा क्लाइन्टलाई दिन सकिन्छ, वा सर्भरको आफ्नै राउटिङ सन्दर्भमा लेख्न सकिन्छ।
ती चार अवस्थाले लगभग समान सिनट्याक्स प्रयोग गर्छन् र पूर्ण रूपमा फरक नतिजा दिन्छन्। पहिलो तीनले क्लाइन्टले टनेलमा के पठाउँछ भन्नेमा असर गर्छन्; चौथोले सर्भर नेटवर्कमा कसरी पुग्छ भन्नेमा असर गर्छ, जुन सर्भरलाई आफैं मार्ग चाहिँदा उपयोगी र वितरण ठानिए हानिकारक हुन्छ।
लाइन लेख्नु अघि चारमध्ये कुन चाहिन्छ निर्णय गर्नुहोस्, त्यसपछि प्राप्तकर्ता पुष्टि गर्नुहोस्।
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
नाङ्गो सर्भर रुटले मानिसलाई किन अचम्मित पार्छ
सर्भर कन्फिगरेसन भनेको प्रशासकहरूले पहिले हेर्ने ठाउँ हो, र त्यहाँको रुट निर्देशन VPN नेटवर्कको बारेमा भनाइजस्तो पढिन्छ। त्यस्तो होइन। OpenVPN ले यसलाई डेमन चलिरहेको मेसिनमा स्थानीय रुट स्थापना मान्छ, जुन तपाईंले ip route प्रयोग गरी गरेर पछि बिर्सने त्यही प्रकारको परिवर्तन हो।
वितरणका लागि रुट push गर्नुपर्छ, र push का लागि क्लाइन्टले तान्नुपर्छ। तानिएका विकल्प निष्क्रिय गरेर सुरु गरिएको क्लाइन्टले प्रस्ताव पूर्ण रूपमा बेवास्ता गर्छ। सर्भर फाइल फेरि लेख्नु अघि त्यो हात मिलाउने कार्यको दुवै छेउ जाँच्नुहोस्, किनकि सर्भरको लग गुनासो गर्दैन: उसको तर्फबाट प्रस्ताव पठाइएको थियो। स्वीकार गरिएको रुट पनि अर्को जडानमा मात्र लागू हुन्छ, तपाईं पहिले नै रहेको सत्रमा कहिल्यै होइन।
दुवैलाई छुट्टाछुट्टै कार्यका रूपमा देख्नेबित्तिकै असफलता रहस्यमय रहन छोड्छ: सर्भर प्रिफिक्समा पुग्छ, क्लाइन्ट पुग्न सक्दैन, र दुवै भनाइ एउटै समयमा सत्य हुन्छन्।
प्रति-क्लाइन्ट फाइलहरू र ती मिल्ने पहिचान
क्लाइन्ट-विशिष्ट फाइललाई सर्भरले प्रमाणित गरेको पहिचानको नाम दिइन्छ, जुन पूर्वनिर्धारित रूपमा प्रमाणपत्रको सामान्य नाम हो। डेस्कटप क्लाइन्टमा मैत्रीपूर्ण जडान नाम त्यो मान होइन, र नमिल्दा कहिल्यै नपढिने फाइल बन्छ।
सर्भरले वास्तवमा प्रयोग गर्ने डाइरेक्टरी जाँच्नुहोस्, त्यसपछि फाइलको नाम प्रमाणित पहिचानसँग ठ्याक्कै मिल्छ भनी पुष्टि गर्नुहोस्, ठूला र साना अक्षरसमेत।
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/त्यो फाइलभित्र पनि रुट push गर्नुपर्छ, किनकि प्रति-क्लाइन्ट सन्दर्भ त्यो क्लाइन्टको सत्रमा लागू हुने विकल्पहरूको समूह हो, स्थानीय राउटिङ तालिका होइन। त्यहाँको नाङ्गो रुटको समस्या विश्वव्यापी फाइलको नाङ्गो रुटजस्तै हुन्छ।
क्लाइन्टको आफ्नै फाइल र त्यसको मालिक उपकरण
क्लाइन्टको कन्फिगमा राखिएको रुट त्यो क्लाइन्ट जोडिँदा स्थापना हुन्छ र विच्छेद हुँदा हटाइन्छ, जुन स्थिर गन्तव्यका लागि सही जीवनचक्र हो।
यदि नेटवर्क म्यानेजर प्रोफाइलको मालिक छ भने, उसले ती विकल्पहरू एक पटक आयात गरेर आफ्नै प्रतिलिपि राख्न सक्छ। पछि डाउनलोड गरिएको फाइल सम्पादन गर्दा केही बदलिँदैन, जुन "रुट छ तर लागू हुँदैन" को सामान्य कारण हो।
तपाईंले डाउनलोड गरेको फाइलको सट्टा सक्रिय प्रोफाइल जाँच्नुहोस्, र म्यानेजरले देखाउने आयातित सेटिङहरू जाँच्नुहोस्। त्यसपछि जोडिएर कुनै विशेष ठेगानाले कुन मार्ग प्रयोग गर्छ भनी सिस्टमलाई सोध्नुहोस्, रुट पाठ फाइलमा थियो भनेर टनेल जित्यो भनी मान्नुको सट्टा।
क्लाइन्टमा प्रमाणित गर्नुहोस्, त्यसपछि फर्किने मार्ग जाँच्नुहोस्
गन्तव्यको बारेमा क्लाइन्टको आफ्नै राउटिङ तालिकालाई सोध्नुहोस्, सर्भरको होइन। प्रिफिक्सभित्रको एउटा होस्टको खोजीले कुन इन्टरफेस र अर्को हप प्रयोग हुनेछ देखाउन पर्याप्त हुन्छ।
ip route get 10.60.0.10खोजीले टनेलतर्फ संकेत गर्छ भने वितरण काम गर्यो र बाँकी समस्या अन्यत्र छ। यदि यो पूर्वनिर्धारित गेटवेतर्फ संकेत गर्छ भने, रुट स्थापना भएन, क्लाइन्ट-साइड विकल्पले फिल्टर गर्यो, वा क्लाइन्टले प्रयोग नगर्ने प्रोफाइलको हो।
वितरण काम गर्यो र तैपनि केही प्रतिक्रिया दिँदैन भनी मान्नुहोस्: तब गेटवेमा फर्वार्डिङ, विपक्षीको फर्किने मार्ग र तिनीहरूबीचको कुनै पनि फायरवाल जाँच्नुहोस्। रुटले मार्ग छान्छ, यसले पहुँच दिँदैन।