Windows पर OpenVPN: टनल को स्वतः शुरू करें और रूट रखें

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

पहला चरण: प्रोफ़ाइल वहाँ रखें जहाँ सेवा उसे ढूँढती है

Windows सेवा प्रोफ़ाइल एक निश्चित डायरेक्टरी से पढ़ती है, और GUI भी उसी जगह से पढ़ता है, इसलिए आयात करते समय काम करने वाली प्रोफ़ाइल बूट पर अदृश्य रह सकती है। .ovpn फ़ाइलें इंस्टॉलेशन की config डायरेक्टरी में रखें, जो सामान्यतः Program Files के अंतर्गत होती है। किसी उपयोगकर्ता के Downloads फ़ोल्डर में छोड़ी गई प्रोफ़ाइल सेवा के दायरे में ही नहीं आती।

पुराने निर्देश config-auto फ़ोल्डर की ओर इशारा करते हैं, जिसे 2.5 युग के कुछ बिल्ड मानते थे और बाद के रिलीज़ नहीं। इसीलिए अपग्रेड एक काम करते ऑटोस्टार्ट को खामोशी में बदल सकता है, लॉग में क्रेडेंशियल के बारे में कुछ भी न होने पर भी। कोई भी फ़ाइल हटाने से पहले पुष्टि करें कि इंस्टॉल किया गया बिल्ड वास्तव में कौन-सी डायरेक्टरी पढ़ता है।

एक मशीन पर कई प्रोफ़ाइल हों तो dev-node के ज़रिए हर एक को नामित अडैप्टर दें। वरना वे एक ही इंटरफ़ेस के लिए होड़ करते हैं और दूसरा ऐसे विफल होता है जो क्रेडेंशियल समस्या जैसा दिखता है।

दूसरा चरण: ट्रे आइकन नहीं, सेवा शुरू करें

सेवाOpenVPN को Automatic पर सेट करने से वह बिना लॉगिन के बूट पर शुरू हो जाती है। यही तंत्र है, और ट्रे आइकन उसका हिस्सा नहीं है। जब कनेक्शन सेवा के पास होता है, तो GUI शायद कोई आइकन या स्थिति न दिखाए, जो अपेक्षित है, खराबी नहीं।

नतीजा यह है कि डिस्कनेक्ट करने का मतलब सेवा रोकना है, Disconnect पर क्लिक करना नहीं। जो मशीन को सहायता देता है उसे बताएँ, वरना पहली सहायता कॉल गायब आइकन के बारे में होगी।

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

तीसरा चरण: रूट को टनल से बाँधें

स्थायी प्रविष्टि यहाँ गलत औज़ार है। -P के साथ रूट जोड़ने से वह रीबूट भी झेल जाता है और, इससे भी बुरा, टनल बंद होना भी झेल जाता है। VPN बंद होने पर प्रीफ़िक्स अब भी ऐसे गेटवे की ओर इशारा करता है जो नहीं है, इसलिए होस्ट उस गंतव्य तक नहीं पहुँच सकता जब तक कोई प्रविष्टि न मिटा दे।

तीन विकल्प सही व्यवहार करते हैं। रूट सर्वर से पुश करें, जो कनेक्ट पर उसे जोड़ता है और डिस्कनेक्ट पर हटा देता है। उसे route-up स्क्रिप्ट में जोड़ें जो route_vpn_gateway पढ़ती है, ताकि अगली हॉप बातचीत किए गए टनल से आए। या Add-VpnConnectionRoute को Windows की मूल VPN प्रोफ़ाइल के साथ इस्तेमाल करें, जो प्रीफ़िक्स को उस कनेक्शन से बाँधता है।

जब सर्वर इस साइट की ज़रूरत से ज़्यादा देता है, route-nopull पुश किए गए रूट अस्वीकार कर देता है और तालिका पूरी तरह स्थानीय छोड़ देता है। यह ऐसी साझा प्रोफ़ाइल के लिए उपयुक्त है जिसके उपयोगकर्ताओं को कॉर्पोरेट डिफ़ॉल्ट रूट नहीं मिलना चाहिए।

चौथा चरण: कोल्ड बूट झेलें

नेटवर्क स्टैक होने से पहले सेवा शुरू करने पर एक असफल प्रयास होता है और फिर दोबारा प्रयास नहीं। उसे Automatic (Delayed Start) पर सेट करना, या नेटवर्क सेवा पर निर्भरता जोड़ना, उस होड़ को हटा देता है। फिर बूट परीक्षण दोहराएँ और जाँचें कि दूसरे प्रयास की अब ज़रूरत नहीं।

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

जिस क्रम को आप वास्तव में तैनात करते हैं उसी को परखें, न कि जिसे हाथ से चला सकते हैं। कोल्ड बूट ही एकमात्र परीक्षण है जो क्रम को परखता है।

पाँचवाँ चरण: GUI के बिना सत्यापित करें

रीबूट और लॉगिन के बाद, GUI खोले बिना तीन चीज़ें जाँचें। अडैप्टर के पास एक पता होना चाहिए,रूट तालिका को साइट प्रीफ़िक्स अगली हॉप के रूप में टनल गेटवे के साथ दिखाना चाहिए, और दूर के पते पर ping का उत्तर आना चाहिए। हर जाँच ऊपर के चरणों के किसी अलग तंत्र से मेल खाती है।

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