रूट पर 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 और दूसरी ओर दूरस्थ नेटवर्क है, तो समस्या दोहराव नहीं बल्कि पता अतिव्यापन है, और कोई भी मिटाना दोनों अर्थों को एक साथ सत्य नहीं बना सकता। उस मामले के लिए दोनों में से एक नेटवर्क की अलग योजना चाहिए। किसी को भी छूने से पहले तय करें कि कौन-सा पक्ष पुनःक्रमांकित होगा।