Netgear OpenVPN: TUN और TAP अलग-अलग पोर्ट पर सुनते हैं

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

तीन संभावित खराबियों में से किसका पीछा करना है, यह तय करना ही यहाँ पूरा काम है: पोर्ट, डिवाइस प्रकार, या डेटा-चैनल की सिफ़र बातचीत।

तीन चीज़ें जो मेल खानी चाहिए

डिवाइस प्रकार, प्रोफ़ाइल की इंटरफ़ेस पंक्ति और श्रोता पोर्ट एक ही चुनाव बनाते हैं, तीन नहीं। dev tun घोषित करने वाली और TAP श्रोता की ओर लक्षित प्रोफ़ाइल सत्र पूरा नहीं कर सकती, और उलटा भी ठीक उसी तरह विफल होता है। अपने मॉडल और फ़र्मवेयर के लिए पोर्ट किसी गाइड से नहीं, राउटर के अपने VPN पृष्ठ से पढ़ें, क्योंकि संख्याएँ बिल्ड के बीच बदलती हैं। मॉडल और फ़र्मवेयर संस्करण उस संख्या के आगे लिखें ताकि अगला व्यक्ति उसे सत्यापित कर सके।

फ़ील्ड रिपोर्टें एक फ़र्मवेयर पर TUN के लिए 12973 और TAP के लिए 12974 जैसी जोड़ी का, और दूसरे पर अलग संख्या का ज़िक्र करती हैं। इन्हें बिल्ड के अलग होने का सबूत पढ़ें, नकल करने के स्थिरांक के रूप में नहीं। फिर प्रोफ़ाइल को दूरी के अनुरूप होस्टनाम चाहिए: राउटर का गतिशील DNS नाम, बदलने वाले WAN पते के बजाय।

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

लॉग को उसी क्रम में पढ़ें जिसमें वह छपता है

OpenVPN क्लाइंट घटनाओं की रिपोर्ट उसी क्रम में करता है जिसमें वे होती हैं, इसलिए ख़ामोशी से पहले की अंतिम पंक्ति जाँचने की परत बताती है। जब रन TLS Error: TLS key negotiation failed पर खत्म होता है, या बस पहले उत्तर की प्रतीक्षा करके हार मान लेता है, तो प्रमाणपत्रों की तुलना कभी हुई ही नहीं। यह पहुँच, श्रोता, या ऐसे पोर्ट की ओर इशारा करता है जिसके पीछे कुछ नहीं है। इनमें से कोई भी CA फ़ाइल बदलने से ठीक नहीं होता।

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

आधुनिक क्लाइंट जिस सिफ़र सूची की अपेक्षा करता है, उसे जोड़ें

हाल के OpenVPN क्लाइंट पुराने डिफ़ॉल्ट अस्वीकार करते हैं जो उपभोक्ता फ़र्मवेयर अब भी देता है, और लक्षण सफल हैंडशेक के ठीक बाद बातचीत की विफलता है। समाधान एक प्रोफ़ाइल पंक्ति है जो बताती है कि क्लाइंट क्या स्वीकार करेगा: data-ciphers को इसी क्रम में AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 और AES-128-CBC पर सेट करें। राउटर जिस एल्गोरिद्म को लागू नहीं करता वह बस कभी चुना ही नहीं जाता, इसलिए लंबी सूची थोड़ी लंबी बातचीत के अलावा कुछ नहीं लेती।

सिफ़र सूचीबद्ध करना राउटर को वह नहीं सिखाता जो उसके पास नहीं है। अगर बातचीत फिर भी विफल हो, तो देखें कि राउटर पृष्ठ पर अपनी सिफ़र सेटिंग है या नहीं और उस सेटिंग में कम से कम एक ऐसी प्रविष्टि है या नहीं जिसे क्लाइंट स्वीकार करता है। साझा सदस्य के बिना दो सूचियाँ गलत पोर्ट जैसी ही विफलता देती हैं, इसलिए दोनों सिरे एक नज़र के लायक हैं।

हाथ से प्रतियाँ संपादित करने के बजाय एक बार आयात करें

सुधरी हुई फ़ाइल को NetworkManager में आयात करना थोड़े अलग प्रोफ़ाइलों से भरे फ़ोल्डर से बचाता है: nmcli connection import type openvpn file client.ovpn, फिर उसे नाम से शुरू करें। आयातित प्रोफ़ाइल को ही वह एकमात्र प्रति रखें जिसे आप संपादित करते हैं, और बार-बार डाउनलोड से जमा होने वाली प्रतियाँ हटा दें।

फिर LAN के बाहर से परखें। उसी नेटवर्क से जुड़ना बहुत कम साबित करता है, क्योंकि ट्रैफ़िक शायद सुरंग से होकर गुज़रे ही नहीं। पुष्टि करें कि अनुरोध सचमुच राउटर से बाहर जाता है, केवल यह नहीं कि क्लाइंट जुड़ी हुई स्थिति दिखाता है।

चेतावनियों के बारे में क्या करना है, यह तय करें

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

जब फ़र्मवेयर सचमुच मायने रखने वाली चेतावनी सुधारने का कोई समर्थित तरीका नहीं देता, तो यह अंतराल VPN को कहीं और होस्ट करने के पक्ष में है। प्रोफ़ाइल ठीक करने, चेतावनी स्वीकार करने और समापन बिंदु हटाने के बीच चुनना इस बात का निर्णय है कि आप उस प्रमाणपत्र पर कितना भरोसा करते हैं। इसे जानबूझकर लें, और लिख लें कि आपने कौन-सा विकल्प चुना, आइकन हरा होने तक संवादों पर क्लिक करते रहने के बजाय।