मार्गावरील 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 आणि दुसर्या बाजूला दूरचे नेटवर्क असल्यास, समस्या दुहेरीपणा नाही तर पत्ता अतिव्यापन आहे, आणि कोणतीही पुसणी दोन्ही अर्थ एकाच वेळी खरे करू शकत नाही। त्या प्रकरणासाठी दोन नेटवर्कपैकी एकासाठी वेगळी योजना लागते। कोणत्याही एकाला हात लावण्यापूर्वी कोणती बाजू पुनर्क्रमांकित होईल ते ठरवा।