OpenVPN iroute विरुद्ध कर्नेल रूट: कोणता गहाळ आहे?

10.77.20.0/24 साठीचे पॅकेट OpenVPN सर्व्हरवर दोन वेगळे निर्णय घेते: ऑपरेटिंग सिस्टमने ते VPN इंटरफेसला सुपूर्द करायचे आहे, आणि OpenVPN ला कोणता जोडलेला क्लायंट त्या प्रीफिक्सचा मालक आहे हे माहीत असायचे आहे। कर्नेल रूट नसल्यास पॅकेट टनेलच्या आधीच पडते, आणि पीअर रूट नसल्यास ते नंतर पडते। दूरच्या LAN वरून दोन्ही अपयश सारखीच दिसतात, आणि तुमच्याकडे कोणते आहे हे निदान करायला प्रत्येक बाजूला एक आदेश लागतो।

क्लासिक युझरस्पेस डेटा मार्गात कर्नेल रूट पॅकेटला टनेल प्रक्रियेत नेते आणि iroute त्या प्रक्रियेला सांगते की कोणत्या पीअरने ते घ्यायचे आहे। एकही दुसऱ्याची जागा घेत नाही, आणि त्यातील फक्त एकच असलेली संरचना पहिल्या ping पर्यंत योग्य वाटेल।

दोन निर्णय, एक रूट नाही

10.77.20.0/24 एका क्लायंटच्या मागे असलेल्या साइट-टू-साइट लिंकची कल्पना करा। सर्व्हरचा कर्नेल रूट, उदाहरणार्थ ip route add 10.77.20.0/24 dev tun0, जुळणारी पॅकेट टनेल उपकरणाकडे पाठवतो। त्यानंतर OpenVPN क्लायंट संरचना डिरेक्टरीतील iroute नोंदींपासून बनवलेले स्वतःचे अंतर्गत तक्ते पाहते, कोणते पीअर कनेक्शन ती घेईल हे ठरवण्यासाठी। कर्नेल रूट नसल्यास पॅकेट कधीच प्रक्रियेपर्यंत पोहोचत नाही, आणि पीअर रूट नसल्यास ते प्रक्रियेपर्यंत पोहोचते आणि कुठेही जात नाही।

ती विभागणी विसरणे सोपे आहे, कारण क्लायंट प्रोफाइलमधील एक रूट ओळ दोन्ही कामे करते असे वाटू शकते। ती करत नाही: रूट पुश करणे क्लायंटना टनेलमधून काय पाठवायचे ते सांगते, तर iroute सर्व्हरला सांगते की क्लायंटच्या मागील पत्ता-श्रेणी कोणाची आहे। ते वेगवेगळ्या फाइलींमध्ये राहतात, वेगवेगळ्या बाजू वाचतात, आणि विरुद्ध दिशांनी अपयशी होतात।

iroute कुठे राहते आणि काय सांगते

नोंद क्लायंटच्या common_name नावाच्या प्रति-क्लायंट फाइलमध्ये, client-config-dir अंतर्गत, iroute 10.77.20.0/24 अशी जाते। फाइलनावाचे जुळणे सौंदर्याचे नाही: OpenVPN प्रमाणित ओळख शोधते आणि नेमक्या त्या नावाची फाइल वाचते, म्हणून site-a नावाची फाइल फक्त ज्याचे सामान्य नाव site-a आहे अशा क्लायंटवरच लागू होते। अशी फाइल नसलेल्या क्लायंटना पूर्णपणे नाकारायचे असेल तर ccd-exclusive जोडा, प्रत्येक क्लायंट साइट गेटवे असताना हे योग्य सेटिंग आहे। प्रत्येक गेटवेसाठी एक फाइल ठेवा आणि तुम्ही प्रत्यक्षात जारी करता त्या प्रमाणपत्र विषयाच्या नावाने तिचे नाव ठेवा।

दूरच्या LAN ला दोष देण्यापूर्वी सर्व्हरवरून नोंद तपासा। स्थिती फाइल जोडलेल्या क्लायंटना त्यांच्या सामान्य नावांसह सूचीबद्ध करते, आणि --verb 4 वर चालणारा सर्व्हर पीअर जोडला जाताना iroute स्थापित होण्याची नोंद ठेवतो। जोडणीच्या वेळी काहीही दिसत नसल्यास फाइल चुकीच्या डिरेक्टरीत आहे किंवा चुकीची ओळख सांगते।

सापळा: फाइल आहे, ओळख चुकीची

चुकीच्या पीअरला जोडलेला बरोबर दिसणारा iroute गहाळ फाइलपेक्षा जास्त वेळ वाया घालवतो, कारण डिस्कवर सर्व काही बरोबर दिसते। प्रमाणपत्रांची पुनर्नामकरण, दुहेरी सामान्य नावे, आणि प्रभावी ओळख बदलणारे username-as-common-name हे सर्व ते घडवतात। सर्व्हरने कोणती ओळख प्रमाणित केली ते तपासा, तुम्ही अपेक्षित असलेली नाही: स्थिती आउटपुट अधिकृत आहे, तर फाइलनाव फक्त शोध-की आहे।

रूट आपल्या मालकापेक्षा जास्त काळ टिकू शकतो। स्थिर रूट आणि iroute नोंदी उपलब्धतेची हमी नाही, प्रीफिक्स वर्णन करतात, म्हणून रहदारी सध्या डिस्कनेक्ट असलेल्या पीअरकडे जात राहू शकते।

पीअरच्या पलीकडील मार्ग पूर्ण करा

पीअरची मालकी मार्गाच्या मध्यभागी आहे, शेवटी नाही। क्लायंटने टनेलमधून पॅकेट आपल्या LAN मध्ये पाठवावी लागतात, म्हणजे त्या होस्टवर IP पाठवणी सक्रिय असावी आणि जाण्यास परवानगी देणारा फायरवॉल नियम असावा। दूरच्या LAN मधील होस्टना टनेल पत्त्यासाठी परतीचा मार्ग हवा: एकतर गेटवेकडे परत निर्देश करणारा रूट, किंवा क्लायंटच्या बाजूला जाणीवपूर्वक तयार केलेली NAT रचना। वितरणाचा डीफॉल्ट गृहीत धरण्याऐवजी sysctl net.ipv4.ip_forward ने क्लायंटवरील पाठवणी सेटिंगची पुष्टी करा।

इतर VPN क्लायंटना त्या सबनेटपर्यंत पोहोचायचे असेल तर रचना पुन्हा वाढते: सर्व्हरला client-to-client लागतो, आणि त्या क्लायंटनी प्रीफिक्स टनेलमधून रूट करावा लागतो। यातील काहीही सर्व्हरच्या स्वतःच्या रूट तक्त्यातून येत नाही।

सर्व्हरकडून नाही, तर खऱ्या स्रोताकडून एक गंतव्य तपासा। असंबंधित LAN होस्टवरून क्लायंटच्या मागील होस्टपर्यंत ping एकाच हालचालीत परतीचा मार्ग, पाठवणी नियम आणि पीअर मालकी तपासते, तर यशस्वी handshake फक्त ओळख सिद्ध करतो। नंतर मालक पीअर डिस्कनेक्ट करा आणि रूट काय करतो ते नोंदवा, कारण तेच उत्तर तुमची अपयश-पद्धत आहे।