Windows पर OpenVPN एडाप्टर बार-बार गिर रहा है? डुप्लिकेट IP जाँचें

Windows पर, जो OpenVPN एडाप्टर पता लेता है, उसे छोड़ देता है और हर कुछ सेकंड में यह दोहराता है, वह आमतौर पर DHCP बग नहीं होता। एडाप्टर को ऐसा पता इस्तेमाल करने को कहा जाता है जिसका जवाब पहले से कोई और दे रहा है, इसलिए Windows उसे अनुपयोगी चिह्नित कर देता है और क्लाइंट फिर से शुरू करता है। क्लाइंट लॉग शांत रहता है क्योंकि टकराव उसके नीचे, ऑपरेटिंग सिस्टम के अपने नेटवर्क स्टैक के भीतर हल होता है।

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

क्लाइंट लॉग से नहीं, Windows ईवेंट लॉग से शुरू करें

Windows पता टकराव सिस्टम लॉग में ईवेंट आईडी 4198 और 4199 के साथ दर्ज करता है। पहला किसी पते के लिए पाया गया टकराव बताता है, दूसरा बताता है कि कोई इंटरफ़ेस उस पते का उपयोग नहीं कर सका जिसके साथ वह कॉन्फ़िगर था। इनमें से कोई OpenVPN का उल्लेख नहीं करता, और इसी कारण इन्हें नज़रअंदाज़ करना आसान है।

हाल के ईवेंट निकालें और उनके टाइमस्टैम्प की तुलना एडाप्टर के नवीनीकरण चक्र से करें: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap। हर पंद्रह सेकंड में एक टकराव ऐसे क्लाइंट से मेल खाता है जो उसी पते को ऐसे मालिक के सामने फिर आज़मा रहा है जो उसका जवाब देता रहता है। कनेक्शन के समय एक अकेला टकराव इसके बजाय एकबारगी टक्कर की ओर संकेत करता है। किसी भी स्थिति में, अगला सवाल यह है कि पता और किसके पास है।

तीन व्यवस्थाएँ दो होस्टों को एक पते पर रखती हैं

सर्वर से पूछें कि उसके अनुसार पता किसके पास है, फिर नेटवर्क से पूछें कि उसका जवाब कौन देता है। grep -H ifconfig-push /etc/openvpn/ccd/* हर पिन किए गए टनल पते और उस प्रमाणपत्र की सूची देता है जिसका वह है। ip -4 neigh show dev tap0 दिखाता है कि ब्रिज ने दूसरी परत पर क्या सीखा है। इन दोनों सूचियों की तुलना करने से अधिकांश डुप्लिकेट एक मिनट से कम में मिल जाते हैं।

तीन व्यवस्थाएँ लगभग सभी की व्याख्या करती हैं: client-config-dir में एक प्रविष्टि दो प्रमाणपत्रों के लिए एक पता पिन करती है, ब्रिज किया गया tap खंड किसी मशीन को ऐसा पता देता है जो किसी दूसरे होस्ट के पास पहले से स्थिर रूप में है, या पुरानी लीज़ फ़ाइल ऐसा पता लौटाती है जिसे अभी भी जुड़ा क्लाइंट अपना मानता है। तीसरा मामला सबसे चालाक है, क्योंकि ifconfig-pool-persist जाने-पहचाने क्लाइंट के लिए जानबूझकर पतों का पुनः उपयोग करता है।

पते के लिए दौड़ लगाने के बजाय उसे अद्वितीय बनाएँ

बूट क्रम केवल यह तय करता है कि आज कौन जीतेगा, इसलिए रीस्टार्ट क्रम पर आधारित किसी भी सुधार को अस्थायी मानें। हर क्लाइंट को उसकी अपनी ifconfig-push पंक्ति दें, या ऐसी श्रेणी से स्थिर पते आवंटित करें जिसे कोई ब्रिज या सर्वर इंटरफ़ेस न छूता हो। क्लाइंट सूची में डुप्लिकेट सामान्य नाम भी जाँचें, क्योंकि duplicate-cn दो सत्रों को एक पहचान और इसलिए एक पिन किया गया पता साझा करने देता है। यदि ब्रिज किए गए डिवाइस को वास्तव में स्थिर पता चाहिए, तो उसे उसके अपने सबनेट में ले जाएँ या सर्वर जहाँ दर्ज करता है वहाँ से पूल में आरक्षित करें।

persist फ़ाइल को केवल तब हटाएँ जब आप जानते हों कि इसमें कौन-सी लीज़ हैं, अन्यथा अगला पुनः कनेक्शन फिर वही पते बाँट देगा।

सही क्रम में रीस्टार्ट करें और हर पते के लिए एक मालिक की पुष्टि करें

पहले सर्वर पर परिवर्तन लागू करें, फिर क्लाइंट को फिर से जोड़ें, ताकि हर प्रतिभागी सुधारे गए पूल के विरुद्ध पंजीकृत हो। पहले क्लाइंट रीस्टार्ट करने से वे ऐसे पतों के साथ रह जाते हैं जिन्हें सर्वर अभी भी अधिकृत मानता है। रीस्टार्ट के बाद स्टेटस फ़ाइल पढ़ें और पुष्टि करें कि हर सामान्य नाम एक बार एक पते के साथ दिखता है। एक नाम के लिए दो प्रविष्टियों का अर्थ है कि पुराना सत्र कभी बंद नहीं हुआ, यह नहीं कि पूल टूटा है।

यदि कोई क्लाइंट अभी भी अपना पता नहीं रख पाता, तो जाँचें कि क्या उसी होस्ट पर कोई ब्रिज इंटरफ़ेस उसे लिए हुए है। विक्रेता डिवाइस से पता विरासत में मिला ब्रिज, VPN सर्वर द्वारा वह पता क्लाइंट को दे दिए जाने पर भी उसके लिए ARP का जवाब देगा।

टिकट बंद करने से पहले पूरा नवीनीकरण चक्र देखें

एक साफ़ रीडिंग कुछ भी साबित नहीं करती। एडाप्टर को कम से कम दस मिनट देखें और बीच में पुनः कनेक्शन ज़बरदस्ती कराएँ: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState। पता पुनः कनेक्शन के बाद भी बना रहना चाहिए और पसंदीदा स्थिति में रहना चाहिए।

फिर पहले चरण की ईवेंट क्वेरी दोबारा चलाएँ और पुष्टि करें कि वह कुछ नया नहीं लौटाती। पुनः कनेक्शन के दौरान शांत लॉग यह प्रमाण है कि टकराव चला गया, जबकि एक कनेक्शन के बाद शांत लॉग का अर्थ केवल यह है कि दौड़ अभी नहीं हुई। अंत में, उस संसाधन का परीक्षण करें जिसके लिए टनल है, क्योंकि पता खो चुका ब्रिज विक्रेता का मार्ग तोड़ सकता है जबकि VPN स्वयं स्वस्थ दिखता है।

पूल की श्रेणी, हर पिन किया गया पता और उसे रखने वाला होस्ट सर्वर के नोट्स में दर्ज करें। तब अगली टक्कर को पहचानने में मिनट लगेंगे, पूरी दोपहर फिर से खोजने में नहीं।