OpenVPN अझै पुराना रुटहरू धकेल्दै छ? यसले के लोड गर्यो हेर्नुहोस्

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

तलको तुलना प्रक्रियाबाट बाहिरतिर जान्छ, किनकि कुन फाइल लागू छ भन्ने कुरा प्रक्रियालाई मात्र थाहा हुन्छ।

तपाईंले सम्पादन गरेको फाइल र प्रक्रियाले पढ्ने फाइल

unit र यसले बनाएको आदेश लाइनबाट सुरु गर्नुहोस्। systemd होस्टमा systemctl cat openvpn@server ले ExecStart लाइन छाप्छ, र इन्स्टेन्स unit ले सामान्यतया आफ्नो कन्फिगरेसन मार्ग इन्स्टेन्सको नामबाट निकाल्छ, त्यसैले openvpn@office का रूपमा सुरु गरिएको डेमन openvpn@server का रूपमा सुरु गरिएको भन्दा फरक फाइल पढ्छ। यसलाई चलिरहेको प्रक्रियाको argv सँग तुलना गर्नुहोस्। कन्फिगरेसन व्यवस्थापन उपकरणले परिवर्तन गुमाउने अर्को बाटो थप्छ: यसले सही फाइल unit ले कहिल्यै नभनेको ठाउँमा लेख्न सक्छ, अनि सफल डिप्लोय केही नगरेजस्तै देखिन्छ।

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

सर्भरले के धकेल्छ र क्लाइन्टले के स्थापना गर्छ

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

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

धकेलिएको प्रिफिक्स र फर्कने मार्ग फरक समस्या हुन्

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

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

दुवै छेउका तालिका तुलना गर्नुहोस्

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

तीन पहिचान सँगै राख्नुहोस्: कन्फिगरेसन मार्ग, unit वा इन्स्टेन्सको नाम, र तपाईंले परीक्षण गरेको क्लाइन्ट पहिचान।

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

पुनः सुरु गरेपछि पनि रहिरहने रुट समस्या प्रायः रुटिङ समस्या नै हुँदैन; खराबी तपाईं बारम्बार पढिरहने तालिकाभन्दा माथि हुन्छ।