दोन उपकरणे, एक OpenVPN प्रमाणपत्र: पुन्हा जोडणीचा लूप

दर अर्ध्या मिनिटाला वर येऊन पुन्हा सुरू होणारी टनेल सामान्यतः सिफर किंवा MTU ची समस्या नसते। ती एकच ओळख दोन वेळा वापरली जात असते। सर्व्हर ओळखीचे सामाईक नाव पाहतो, नवीन सत्र सर्वात नवीन म्हणून घेतो, आणि जुने उपकरण आपले जागेवर बदल झाले आहे हे शोधते। क्लायंटच्या बाजूने हे निष्क्रियतेची मुदत संपल्यासारखे आणि पुन्हा सुरू झाल्यासारखे दिसते, म्हणूनच तपासणी इतक्या वेळा चुकीच्या ठिकाणाहून सुरू होते।

पुन्हा सुरू होण्याच्या अंतराने सुरुवात करा

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

दुसऱ्या उपकरणाच्या तुलनेत पुन्हा सुरुवात कधी झाली ते तपासा। नवीन लॅपटॉप, फोन किंवा राखीव मशीनवर कॉपी केलेली प्रोफाइल ही नेहमीची कारणे आहेत, आणि वेळ सामान्यतः कोणी ती सेट केलेल्या दिवसाशी जुळते।

अंतर आणि कारण लिहून ठेवा। दोन्ही पुरावे आहेत, आणि दोन्ही स्वस्तात गोळा करता येतात।

सर्व्हरने दुसऱ्या लॉगिनबद्दल काय सांगितले ते वाचा

तुम्ही नियंत्रित करता त्या सर्व्हरवर लॉग सामाईक नाव सांगतो आणि दुसरे कनेक्शन येत असल्याचे दाखवतो। duplicate-cn नसल्यास ते आगमन त्याच नावाचे विद्यमान सत्र बदलते, आणि संदेश सामान्यतः ते स्पष्ट सांगतो। duplicate-cn असल्यास दोन्ही सत्रे एकत्र राहतात आणि लक्षण बदलते: क्लायंट सुरू राहतात पण प्रत्येक क्लायंटसाठी एकच सेटिंग्ज संच आणि एकच रद्द करण्याचा निर्णय वाटून घेतात। बदल फक्त क्रमात दिसतो, म्हणून दोन्ही नोंदी एकत्र वाचा।

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

फक्त दूरचे होस्टनेम नाही तर दोन्ही प्रोफाइलमधील प्रमाणपत्र आणि की ब्लॉक्सची तुलना करा। कॉपी केलेल्या प्रोफाइल सामान्यतः फक्त फाइल नावाने वेगळ्या असतात।

सर्व्हरच्या बाजूला ओळख वेगळी करा

या सर्व्हरसाठी स्वाक्षरी करणाऱ्या CA मार्फत प्रत्येक उपकरणासाठी एक प्रमाणपत्र द्या। Easy-RSA सह याचा अर्थ प्रत्येक उपकरणासाठी स्वतंत्र क्लायंट नाव, आणि नंतर त्या प्रमाणपत्रावरून व त्याच्या कीवरून प्रोफाइल तयार होते। सामाईक नाव उपकरणाची ओळख होते, आणि सर्व्हरला तंतोतंत तेच कमी पडले होते। व्यक्तीऐवजी उपकरणानुसार नावे द्या, जेणेकरून बदली नवे नाव निर्माण करेल।

सामायिक नियंत्रण-चॅनेल की वेगळी गोष्ट आहे। tls-crypt किंवा tls-auth प्रत्येक क्लायंटचे नियंत्रण चॅनेल संरक्षित करते आणि सामायिक करण्यासाठी आहे। ती क्लायंट ओळख नाही, आणि ती बदलल्याने दुहेरी प्रमाणपत्र सुटणार नाही।

प्रमाणपत्र, की आणि प्रत्येक क्लायंट-निहाय कॉन्फिगरेशन फाइल एकाच सामाईक नावाखाली ठेवा, नाहीतर पुढील कनेक्शनला जुळणी तुटते। तेथे तफावत असल्यास प्रमाणित होऊनही काहीही न मिळणारा क्लायंट तयार होतो।

विभाजनानंतर पत्ते आणि सेटिंग्ज जुळवून ठेवा

स्थिर पत्ते टकरीचा दुसरा मार्ग आणतात। सर्व्हर ते ifconfig-pool-persist किंवा क्लायंट-निहाय फाइलमार्फत देत असल्यास ते रेकॉर्ड अजूनही जुन्या नावाकडे निर्देश करतात। प्रमाणपत्रे वेगळी झाल्यावरही दोन उपकरणांना एकच टनेल पत्ता मिळू शकतो, आणि ते अपयश मूळ लूपपेक्षा वेगळे दिसते।

प्रमाणपत्रासोबतच जुळणी अद्ययावत करा, नंतर दोन्ही उपकरणे पुन्हा जोडा आणि त्यांना दिलेले पत्ते तुलना करा। दुहेरी पत्ता स्वच्छ पुनर्जोडणीऐवजी अधूनमधून होणारी हानी म्हणून दिसतो।

प्रत्येक उपकरणासाठी वेगळे असावीत अशा सेटिंग्ज त्या उपकरणाच्या स्वतःच्या फाइलमार्फत पाठवा, सामायिक टेम्पलेटमार्फत नाही। सामायिक टेम्पलेट पुढील दुहेरीपणा ओळखणेही कठीण करते।

जुनी ओळख योग्यरीत्या मागे घ्या

हार्डवेअर मागे घेतले जाते किंवा हरवते तेव्हा जुन्या मशीनवरून प्रोफाइल हटवण्याऐवजी प्रमाणपत्र रद्द करा। रद्द करण्याने नवीन CRL तयार होते, आणि crl-verify जिथे निर्देश करते तिथे सर्व्हरला ती फाइल लागते। ती सूचना असताना गहाळ किंवा न वाचता येणारे CRL सर्व्हरला प्रत्येक क्लायंट नाकारायला भाग पाडते, म्हणून प्रत्येक अद्ययावतानंतर एक ज्ञात खाते तपासा।

प्रत्येक प्रमाणपत्राला व्यक्तीशी किंवा उपकरणाशी जोडणारी, जारी आणि रद्दीकरणाच्या तारखांसह यादी ठेवा। ती यादी फाइल नावे न वाचता कोणाला अजून प्रवेश आहे याचे उत्तर देते, आणि पुढील कॉपी केलेल्या प्रोफाइलला लूप पुन्हा सुरू करू देत नाही।