दो डिवाइस, एक OpenVPN प्रमाणपत्र: पुनः कनेक्शन का लूप

हर आधे मिनट में ऊपर उठकर फिर रीस्टार्ट होने वाली टनल आम तौर पर सिफ़र या MTU की समस्या नहीं है। यह एक ही पहचान का दो बार इस्तेमाल है। सर्वर एक जाना-पहचाना कॉमन नेम देखता है, नए सत्र को सबसे नया मान लेता है, और पुराना डिवाइस जान जाता है कि उसे बदल दिया गया है। क्लाइंट की ओर से यह निष्क्रियता की समय-सीमा और रीस्टार्ट जैसा दिखता है, इसलिए जाँच अक्सर गलत जगह से शुरू होती है।

रीस्टार्ट अंतराल से शुरू करें

अंतराल बाकी सब से पहले एक सुराग है। ping-restart विंडो से मेल खाती स्थिर लय बदले जा रहे सत्र की ओर इशारा करती है, किसी विफल मार्ग की ओर नहीं, क्योंकि मार्ग की विफलताएँ शायद ही इतनी नियमित होती हैं। रीस्टार्ट के बीच का सटीक अंतर और क्लाइंट लॉग की कारण-पंक्ति लिख लें। समय-सीमा के बाद रीस्टार्ट असफल हैंडशेक से अलग कहानी कहता है।

दूसरे डिवाइस के सापेक्ष रीस्टार्ट कब शुरू हुए, यह देखें। नया लैपटॉप, फ़ोन या किसी अतिरिक्त मशीन पर कॉपी किया गया प्रोफ़ाइल सामान्य कारण हैं, और समय आम तौर पर उसी दिन से मेल खाता है जिस दिन किसी ने इसे सेट किया।

अंतराल और कारण लिख लें। दोनों सबूत हैं, और दोनों सस्ते में जुटाए जा सकते हैं।

पढ़ें कि सर्वर ने दूसरे लॉगिन के बारे में क्या कहा

जिस सर्वर पर आपका नियंत्रण है, वहाँ लॉग कॉमन नेम बताता है और दूसरा कनेक्शन आते दिखाता है। duplicate-cn के बिना वह आगमन उसी नाम का मौजूदा सत्र बदल देता है, और संदेश आम तौर पर यह साफ़ कहता है। duplicate-cn के साथ दोनों सत्र साथ रहते हैं और लक्षण बदल जाता है: क्लाइंट चालू रहते हैं पर प्रति क्लाइंट एक ही सेटिंग्स समूह और एक ही रद्द करने का निर्णय साझा करते हैं। दोनों प्रविष्टियाँ साथ पढ़ें, क्योंकि बदलाव सिर्फ़ क्रम में दिखता है।

होस्टेड सेवा में आपके पास सर्वर लॉग बिल्कुल न हो। तब सुराग समय है: एक स्थिर टनल जो हर बार गिरती है जब कोई दूसरी मशीन जुड़ती है, और क्लाइंट लॉग में समय-सीमा के अलावा कुछ नहीं।

सिर्फ़ दूरस्थ होस्टनाम नहीं, दोनों प्रोफ़ाइल के प्रमाणपत्र और कुंजी ब्लॉक तुलना करें। कॉपी किए गए प्रोफ़ाइल आम तौर पर सिर्फ़ फ़ाइल नाम में भिन्न होते हैं।

सर्वर की ओर पहचान अलग करें

इस सर्वर के लिए हस्ताक्षर करने वाले CA से हर डिवाइस के लिए एक प्रमाणपत्र जारी करें। Easy-RSA के साथ इसका अर्थ है हर डिवाइस के लिए अलग क्लाइंट नाम, और फिर प्रोफ़ाइल उसी प्रमाणपत्र और उसकी कुंजी से बनता है। कॉमन नेम डिवाइस की पहचान बन जाता है, और सर्वर को ठीक यही चाहिए था। इन्हें व्यक्ति के बजाय डिवाइस के नाम पर रखें, ताकि बदलाव से नया नाम बने।

साझा कंट्रोल-चैनल कुंजी अलग चीज़ है। tls-crypt या tls-auth हर क्लाइंट के कंट्रोल चैनल की रक्षा करता है और साझा करने के लिए है। यह क्लाइंट पहचान नहीं है, और इसे बदलने से डुप्लिकेट प्रमाणपत्र ठीक नहीं होगा।

प्रमाणपत्र, कुंजी और हर प्रति-क्लाइंट कॉन्फ़िगरेशन फ़ाइल को एक ही कॉमन नेम के अंतर्गत रखें, वरना अगले कनेक्शन पर मैपिंग टूट जाती है। वहाँ असंगति से ऐसा क्लाइंट बनता है जो प्रमाणित होकर फिर कुछ नहीं पाता।

बँटवारे के बाद पते और सेटिंग्स एक-दूसरे से मिलाते रखें

स्थिर पते टकराव का दूसरा रास्ता जोड़ते हैं। अगर सर्वर उन्हें ifconfig-pool-persist या प्रति-क्लाइंट फ़ाइल से देता है, तो वे रिकॉर्ड अब भी पुराने नाम की ओर इशारा करते हैं। प्रमाणपत्र अलग करने के बाद भी दो डिवाइस को एक ही टनल पता मिल सकता है, और वह विफलता मूल लूप से अलग दिखती है।

मैपिंग को प्रमाणपत्र के साथ ही अपडेट करें, फिर दोनों डिवाइस फिर से जोड़ें और उन्हें मिले पते तुलना करें। डुप्लिकेट पता साफ़ पुनः कनेक्शन के बजाय रुक-रुक कर नुकसान के रूप में दिखता है।

जो सेटिंग्स हर डिवाइस के लिए अलग होनी चाहिए उन्हें उसी डिवाइस की अपनी फ़ाइल से भेजें, किसी साझा टेम्पलेट से नहीं। साझा टेम्पलेट अगली डुप्लिकेट पकड़ना भी मुश्किल बनाता है।

पुरानी पहचान को ठीक से हटाएँ

हार्डवेयर हटने या खो जाने पर पुरानी मशीन से प्रोफ़ाइल मिटाने के बजाय प्रमाणपत्र रद्द करें। रद्दीकरण नया CRL बनाता है, और सर्वर को वह फ़ाइल वहाँ चाहिए जहाँ crl-verify इशारा करता है। उस निर्देश के मौजूद रहने पर गायब या अपठनीय CRL सर्वर को हर क्लाइंट अस्वीकार करने पर मजबूर करता है, इसलिए हर अपडेट के बाद एक ज्ञात खाता जाँचें।

ऐसी सूची रखें जो हर प्रमाणपत्र को किसी व्यक्ति या डिवाइस से जोड़े, जारी होने और रद्द होने की तारीखों के साथ। वह सूची फ़ाइल नाम पढ़े बिना बताती है कि किसके पास अब भी पहुँच है, और अगली कॉपी किए गए प्रोफ़ाइल को लूप फिर से शुरू करने से रोकती है।