OpenVPN या IKEv2: प्रोटोकॉल चुनने से पहले चार जाँचें

OpenVPN और IKEv2 के बीच का चुनाव आमतौर पर प्रोटोकॉल के सवाल की तरह लड़ा जाता है, और यह ढाँचा फैसले को बर्बाद करता है। फैसला इस बात से होता है कि आपका सर्वर और आपके डिवाइस एक ही पूरा प्रोफ़ाइल समर्थित करते हैं या नहीं, और क्या वह प्रोफ़ाइल नेटवर्क के बीच आपके आने-जाने के तरीके में टिकता है। दोनों स्टैक एक-दूसरे में तब्दील नहीं होते: OVPN फ़ाइल अलग सिंटैक्स वाला IKEv2 प्रोफ़ाइल नहीं है। क्रम से की गई चार जाँचें किसी भी फ़ीचर तालिका से जल्दी सवाल का जवाब देती हैं।

क्लाइंट न हो तो बहस खत्म

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

Windows पर एक कमांड पहले से मौजूद प्रोफ़ाइलों की सूची देती है और बताती है कि हर एक किस प्रकार का है। जो नाम वह छापती है वही नाम आगे की जाँचें इस्तेमाल करती हैं।

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

क्लाइंट इंस्टॉल करने का संकेत उन प्लेटफ़ॉर्मों पर OpenVPN कॉलम का असली जवाब है, और यह प्रोटोकॉल की सीमा नहीं बल्कि तैनाती का काम है। कोई भी व्यवस्था भरोसे की जाँच, पहचान सत्यापन या रखरखाव को नहीं हटाती। प्रतिबद्ध होने से पहले पूछें कि प्रोफ़ाइल कैसे बाँटे जाते हैं, क्रेडेंशियल कैसे नवीनीकृत होते हैं और खोया डिवाइस कैसे हटाया जाता है। सरल इंस्टॉल भी ऐसी रिकवरी प्रक्रिया छिपा सकता है जिसे वीकेंड पर कोई नहीं चलाना चाहता।

गतिशीलता संयुक्त सेटिंग है, प्रोटोकॉल का वादा नहीं

IKEv2 MOBIKE का उपयोग तब कर सकता है जब दोनों सिरे उसे समर्थित और सक्षम करते हैं, जिससे क्लाइंट अपना पता बदलते समय भी अपनी सुरंग बनाए रख सकता है। RFC 4555 इस एक्सटेंशन को परिभाषित करता है, और सशर्त शब्दावली मायने रखती है: जो सर्वर इस क्षमता को नज़रअंदाज़ करता है वह बजाय इसके फिर से बातचीत करता है। नतीजा फ़ाइल ट्रांसफ़र के लिए एक जैसा और लाइव कॉल के लिए बहुत अलग दिख सकता है।

जिस बदलाव की आपको सचमुच परवाह है उसे किसी चलती हुई चीज़ के साथ जाँचें जिसे आप देख सकें। Windows पर ping -t <internal-host> चलता रखें, या कहीं और सादा ping, फिर Wi-Fi से सेल्युलर पर जाएँ और रुकावटें देखें। MOBIKE की विफलता क्लाइंट लॉग में चुपचाप पता अपडेट होने के बजाय पूर्ण पुनः-प्रमाणीकरण के रूप में दिखती है। आप यह माप रहे हैं कि सुरंग बदलाव में टिकती है या नहीं, यह नहीं कि प्रोटोकॉल समर्थन का विज्ञापन करता है या नहीं।

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

क्रेडेंशियल सेवा के होते हैं, स्टैक के नहीं

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

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

openssl x509 -in client.crt -noout -subject -issuer -dates

कंपनी कनेक्शन के लिए कंपनी जो तरीका प्रकाशित करती है वही इस्तेमाल करें और तुलना को प्रयोग मानना बंद करें। अगर आप खुद दोनों की तुलना कर रहे हैं, तो पहले जाँचें कि दोनों विकल्प एक ही गेटवे पर खत्म होते हैं या नहीं, क्योंकि यही एक ब्योरा तय करता है कि आपके नतीजे का कितना हिस्सा प्रोटोकॉल के बारे में है। जो अस्वीकृति क्रेडेंशियल का नाम लेती है वह क्रेडेंशियल की समस्या है, और प्रोटोकॉल बदलने से वह कभी ठीक नहीं होगी।

जाँचें कि सुरंग वास्तव में क्या रूट करती है

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

Windows पर दो कमांड रास्ते और नाम खोज दोनों को कवर करती हैं। Linux में बराबर वाले ip route show default और resolvectl query <internal-host> हैं।

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

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

जाँचों के बाद रखरखाव तौलें

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

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