एका OpenVPN क्लायंटवर दोन सेवा पत्ते: iroute आणि lo

अ‍ॅप्लिकेशन त्याच्या टनेल पत्त्यावर उत्तर देते, आणि तुम्ही त्यासाठी दस्तऐवजीकृत केलेला पत्ता कुठेही जात नाही। OpenVPN लॉगमध्ये काहीही तक्रार करत नाही, पीअर जोडलेले दिसते, आणि हब नेमका एक क्लायंट सूचीबद्ध करते। दरी ही आहे की क्लायंटवरील दुसरा पत्ता दोन वेगळ्या गोष्टी आहेत: होस्टने त्याचा मालक असणे आवश्यक आहे, आणि हबला कोणता पीअर त्याचा मालक आहे हे माहीत असणे आवश्यक आहे। एक दुसऱ्याशिवाय हाताळल्यास रहदारी एकतर हबवर मरते किंवा घराच्या मार्गाशिवाय पोहोचते।

उपनाव स्थानिक, मालकी दूरची

टनेल पत्त्यावर वाटाघाटी होते, त्यामुळे हँडशेक दरम्यान दोन्ही टोके तो शिकतात। अतिरिक्त सेवा पत्त्यावर अजिबात वाटाघाटी होत नाही, म्हणून तो जोडल्याने हबवर स्वतःहून काहीही बदलत नाही। क्लायंट ताबडतोब पत्त्याचा मालक होऊ शकतो आणि सर्व्हर ती रहदारी तरीही त्याच्या डीफॉल्ट मार्गावर पाठवेल किंवा ती टाकून देईल। दोन नोंदी, दोन वेगळ्या ठिकाणी तयार कराव्या लागतील।

क्लायंटवर पत्ता होस्टचा आहे, आणि लूपबॅक हे अशा सेवा ओळखीचे नैसर्गिक घर आहे जी कधीही भौतिक लिंकवर दिसू नये। हबवर पीअर-ते-प्रीफिक्स मॅपिंग ही स्वतंत्र घोषणा आहे जी फक्त सर्व्हर वाचतो। दोन्हीपैकी कोणतीही नोंद दुसरीचा अर्थ देत नाही।

तुमच्या नोट्समध्येही दोन्ही श्रेणी वेगळ्या ठेवा। उदाहरणातील पत्ते दस्तऐवजीकरण मूल्ये आहेत, आणि त्यांना खऱ्या LAN शी ओव्हरलॅप करणे हा कार्यरत सेटअप तुटलेला दिसण्याचा सर्वात जलद मार्ग आहे।

क्लायंटवर पत्ता कायमस्वरूपी जोडा

सेवा पत्ता होस्ट प्रीफिक्ससह लूपबॅकवर ठेवा, जेणेकरून होस्ट त्याला पोहोचायच्या सबनेटऐवजी स्थानिक इनपुट म्हणून वागवेल। ip address add 10.66.0.10/32 dev lo एका पत्त्यासाठी ते करते, आणि दुसऱ्या पत्त्यासाठी आदेश पुन्हा चालवल्यास दोन सेवा मॉडेल होतात।

हे एकवेळच्या चाचणी म्हणून चालवा, नंतर होस्टच्या नेटवर्क कॉन्फिगरेशनचे मालक असलेल्यामध्ये हलवा, कारण रनटाइम जोड रीबूटवर नाहीशी होते आणि पुन्हा जोडण्यांदरम्यान प्रत एकत्र होतात। नेटवर्कनंतर क्रमबद्ध systemd युनिट एक पर्याय आहे, आणि वितरणाचा नेटवर्क मॅनेजर दुसरा। तुम्ही जे निवडाल ते असो, अ‍ॅप्लिकेशन बाइंड होण्यापूर्वी पत्ता असणे आवश्यक आहे, अन्यथा सेवा चुकीच्या सॉकेटवर उठते। मॅन्युअल आदेशानंतर नाही, रीबूटनंतर ip address show dev lo ने तपासा।

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

हब प्रत्यक्षात जी CCD फाइल वाचतो तिथे त्याची मागणी करा

सर्व्हरवर मालकीची घोषणा प्रमाणित सामान्य नावाने निवडल्या जाणाऱ्या प्रति-क्लायंट फाइलमध्ये जाते, client-config-dir ने नाव दिलेल्या डिरेक्टरीच्या आत। ओळ iroute 10.66.0.10 255.255.255.255 आहे, प्रति पत्ता एक, आणि ती सर्व्हरला सांगते की त्या गंतव्यासाठी कोणत्या पीअरने रहदारी घ्यावी।

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

हबच्या स्वतःच्या कर्नेललाही त्या गंतव्यांपर्यंत मार्ग आवश्यक आहे, स्थानिकरीत्या तयार झालेली रहदारी टनेल प्रक्रियेत प्रवेश करण्यासाठी। सर्व्हर कॉन्फिगरेशनमधील route 10.66.0.10 255.255.255.255 सर्व्हर स्वतः निर्माण करतो ती रहदारी व्यापते, तर इतर क्लायंटना गंतव्य स्वतः शिकण्यासाठी push "route 10.66.0.10 255.255.255.255" आवश्यक आहे।

राउटिंग आणि अधिकृतता वेगळी राहतात। ढकललेला मार्ग क्लायंटला पॅकेट कुठे पाठवायचे ते सांगतो आणि काहीही देत नाही; सेवेला अजूनही कॉलरला तिच्या अटींवर स्वीकारायचे आहे।

इनपुट धोरण आणि उत्तर मार्ग तपासा

उपनावाला पाठवलेला पॅकेट मालक होस्टवर स्थानिक इनपुट म्हणून पोहोचतो, म्हणून प्रश्न असा की स्थानिक फायरवॉल तो स्रोत आणि पोर्ट परवानगी देतो का। संपूर्ण पत्ता उघडण्याऐवजी VPN स्रोत श्रेणीतून विशिष्ट सेवा पोर्टला परवानगी द्या।

उत्तरांना कॉलरपर्यंत परतण्याचा मार्ग आवश्यक आहे। सामान्य टनेल पूलमधील कॉलरसाठी तो मार्ग आधीच आहे, कारण टनेल उपकरण तो वाहतो। दुसऱ्या राउटेड नेटवर्कमागील कॉलरला त्या नेटवर्कचा परतीचा मार्गही आवश्यक आहे, आणि इथेच असममित सेटअप पॅकेट गमावतात।

त्याच पोर्टवर वेगळ्या पत्त्याला बांधलेल्या दुसऱ्या श्रोत्याकडे लक्ष द्या, कारण कर्नेल जुळणाऱ्या सॉकेटला देतो आणि निकाल यादृच्छिक वाटतात। ss -lntp ने तपासा आणि बांधलेला पत्ता सेवा उपनाव आहे याची खात्री करा। इथे स्रोत NAT आवश्यक नाही, आणि ते जोडल्यास तुमचे लॉग ज्या कॉलर ओळखीवर अवलंबून आहेत ती लपते।

पत्ते आणि मालकी वेगळी तपासा

दोन टप्प्यांत तपासा। प्रथम मालक होस्ट स्वतःकडून त्याच्या उपनावावरील सेवेपर्यंत पोहोचू शकतो याची खात्री करा, ज्यामुळे बाइंड आणि फायरवॉल समस्या राउटिंगपासून वेगळ्या होतात। नंतर अ‍ॅप्लिकेशनच्या स्वतःच्या प्रमाणीकरणाचा वापर करून खऱ्या VPN कॉलरकडून तपासा। पहिले उत्तीर्ण होऊन दुसरे अयशस्वी झाल्यास, गहाळ तुकडा हबच्या बाजूला आहे।

जोडणीनंतरही टिकणाऱ्या अयशस्वी पद्धतींचीही तपासणी करा: टनेल बंद असतानाही उपनाव नेमून दिलेले राहते, आणि पीअर अनुपस्थित असतानाही हब त्याचा मार्ग ठेवतो। कोणतीही वस्तू एकटी सेवा पोहोचण्यायोग्य असल्याचे सिद्ध करत नाही, म्हणून दोन-टप्प्यांची चाचणी लॅपटॉपवरून एका पिंगपेक्षा चांगली आहे।