OpenVPN को "File exists" मार्गमा फाइल समस्या होइन

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

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

क्लाइन्टले वास्तवमा के मागिरहेको थियो

असफलता अघि, क्लाइन्टले थप्न खोजेको मार्ग रेकर्ड गर्छ, सामान्यतया गन्तव्य, नेटमास्क, गेटवे र कहिलेकाहीँ मेट्रिक वा तालिकाको रूपमा। त्यो लाइन नै अनुरोध हो। त्यसपछिको त्रुटि कर्नेलको जवाफ हो, र दुवैलाई सँगै पढ्नुपर्छ।

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

राउट सहायकको गैर-शून्य निकास स्थिति यसको तलको पाठभन्दा कम सूचनामूलक हुन्छ, किनकि विभिन्न कर्नेल प्रतिक्रियाहरूले गैर-शून्य स्थिति उत्पन्न गर्छन्। सही सन्देश राख्नुहोस्; अवस्थित प्रविष्टि र पुग्न नसकिने गेटवेबीचको भिन्नताले अर्को कुन खण्ड लागू हुन्छ भनेर निर्धारण गर्छ।

अवस्थित मार्ग पढ्नुहोस्, मात्र ठेगाना होइन

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

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

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

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

उपसर्गका हुन सक्ने चार मालिक

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

हरेक मालिकलाई फरक सुधार चाहिन्छ। जोडिएको मार्ग तपाईंको मेट्ने होइन; त्यो हटाउँदा टनेल प्रयोगयोग्य हुनु अघि स्थानीय पहुँच भाँचिन सक्छ, र कर्नेलले त्यसलाई फर्काइदिन्छ। प्रबन्धकको स्वामित्वको मार्ग त्यही प्रबन्धकमार्फत बदल्नुपर्छ, अर्को पुनःजडानले रद्द गर्ने हातले लेखिएको ip route del ले होइन।

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

block-local ले फरक प्रश्नको जवाफ दिन्छ

प्रोफाइलले सबै ट्राफिक टनेलबाट पठाउँदा, स्थानीय सञ्जालको के हुने भन्ने क्लाइन्टले निर्णय गर्नुपर्छ। block-local झण्डाले स्थानीय LAN लाई टनेलबाट मार्गस्थ गरेर त्यो निर्णय बदल्छ, साथै LAN गेटवेका लागि अभिलेखित अपवाद कायम राख्छ; यो ट्राफिक नीतिको छनोट हो जसको पहुँचमा देखिने परिणाम हुन्छ।

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

कुन गन्तव्य स्थानीय रहने भन्ने निर्णयका रूपमा यसलाई लिनुहोस्, जो जानाजानी लिइएको र लेखिएको हो। लग चिन्ताजनक देखिँदा यो प्रयास गर्ने स्विच होइन।

चक्र बन्द गर्नुहोस्: दोहोरोलाई यसको स्रोतमै हटाउनुहोस्

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

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

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

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