सर्वर-लॉक प्रोफ़ाइल TLS प्रॉक्सी के पीछे विफल होती है: कौन सी पीढ़ी?
Access Server 2.8 और 2.9 सर्वर-लॉक प्रोफ़ाइल अलग तरह से बनाते हैं। फ़्रंटएंड बदलने से पहले तय करें कि आपकी प्रॉक्सी कौन सा रास्ता तोड़ती है।
एक उपयोगकर्ता जुड़ सकता है और दूसरा नहीं, उसी पोर्टल से, उसी दिन। दोनों के पास सर्वर-लॉक प्रोफ़ाइल हैं, दोनों एक ही Access Server बिल्ड पर हैं, और एकमात्र अंतर यह है कि उनकी प्रोफ़ाइल कब बनी थी। यही वह पैटर्न है जिसे पहचानना चाहिए, क्योंकि "सर्वर-लॉक" कनेक्शन क्रम नहीं, नीति का नाम है। Access Server ने उस आर्टिफ़ैक्ट की दो पीढ़ियाँ जारी की हैं, और एक TLS रिवर्स प्रॉक्सी उनके केवल एक रास्ते के सामने है। तीन शर्तें तय करती हैं कि आप किस शाखा में हैं।
दो पीढ़ियाँ, दो कनेक्शन क्रम
पुराने डिज़ाइन में, जो 2.8 तक चलता है, आयातित फ़ाइल एक स्यूडो-प्रोफ़ाइल है। OpenVPN Connect इसका उपयोग HTTPS पर Access Server के वेब API के सामने प्रमाणित होने के लिए करता है, एक अस्थायी उपयोगकर्ता-लॉक प्रोफ़ाइल और सत्र टोकन प्राप्त करता है, और उसके बाद ही VPN स्थापित करता है। दो ट्रांसपोर्ट क्रम से चलते हैं, और पहला एक साधारण वेब अनुरोध है।
2.9 के साथ पेश किया गया फ़ॉर्मेट वह प्रति-कनेक्शन बूटस्ट्रैप नहीं करता। यह एक मूल प्रोफ़ाइल है जिसका उपयोग संगत OpenVPN क्लाइंट कर सकते हैं, केवल OpenVPN Connect ही नहीं। इसे डाउनलोड करने या URL से आयात करने में अभी भी HTTPS शामिल हो सकता है — यह प्रकाशन का चरण है, प्रति-कनेक्शन अस्थायी प्रोफ़ाइल प्राप्त करना नहीं।
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
अपग्रेड पहले से जारी प्रोफ़ाइलों को ज़रूरी नहीं कि फिर से लिखे, इसलिए मौजूदा सर्वर संस्करण अभी भी पुराना आर्टिफ़ैक्ट दे सकता है। सर्वर बिल्ड आपको बताता है कि क्या संभव है, यह नहीं कि इस उपयोगकर्ता ने क्या आयात किया।
तीन शर्तें जो आपकी शाखा चुनती हैं
पहली शर्त आर्टिफ़ैक्ट की पीढ़ी है। फ़ाइल माँगें, देखें कि वह कैसे बनी, और उस क्लाइंट संस्करण को नोट करें जिसने उसे आयात किया। यदि आप फ़ाइल से पीढ़ी निर्धारित नहीं कर सकते, तो परीक्षण खाते के लिए जारी नई प्रोफ़ाइल आपको बताएगी कि सर्वर आज क्या बनाता है, और यह विफल उपयोगकर्ता के पास मौजूद जानकारी से भिन्न है।
दूसरी यह है कि आपका फ़्रंटएंड वास्तव में क्या समाप्त करता है। सातवीं परत का HTTP रिवर्स प्रॉक्सी जो TLS उतारता है, चौथी परत के TCP फ़ॉरवर्डर जैसी वस्तु नहीं है, और UDP फ़ॉरवर्डर भी नहीं। पोर्ट 443 पर Access Server की सामान्य व्यवस्था OpenVPN TCP डेमॉन को ब्राउज़र ट्रैफ़िक पहचानने और उसे वेब सेवाओं को सौंपने देती है, इसलिए सामने असंबंधित HTTPS टर्मिनेटर लगाना उस डेमॉन की प्रोटोकॉल हैंडलिंग को बनाए नहीं रखता। समान संख्या 443 साझा करना दो डिज़ाइनों को समतुल्य नहीं बनाता।
तीसरी यह है कि विफलता कहाँ पड़ती है। VPN से पहले की विफलता और कंट्रोल-चैनल विफलता उस क्लाइंट में समान दिखती हैं जो केवल "कनेक्ट हो रहा है" कहता है, परंतु वे अलग-अलग जगहों पर साक्ष्य छोड़ती हैं। यदि पुराना फ़ॉर्मेट चल रहा है तो बूटस्ट्रैप उम्मीदवार है। यदि नया फ़ॉर्मेट चल रहा है तो खाली वेब एक्सेस लॉग अपेक्षित है और किसी भी दिशा में कुछ साबित नहीं करता।
जब आर्टिफ़ैक्ट पुराना हो: बूटस्ट्रैप पहले विफल होता है
क्लाइंट की अंतिम स्थिति के बजाय उसकी वास्तविक त्रुटि पढ़ें। रोचक फ़ील्ड हैं HTTPS त्रुटि, वह सर्वर पहचान जिसकी क्लाइंट ने अपेक्षा की, वह गंतव्य जहाँ अनुरोध गया, और क्या प्रमाणपत्र सत्यापन पूरा हुआ। फिर उन्हें सर्वर पक्ष के वेब सेवा और प्रॉक्सी लॉग से मिलाएँ।
ब्राउज़र का लॉगिन पृष्ठ तक पहुँचना इस बात का प्रमाण नहीं है कि इस क्लाइंट का API प्रमाणीकरण सफल हुआ। ये अलग अनुरोध हैं, अलग प्रमाणपत्र अपेक्षाओं और अक्सर अलग होस्टनामों के साथ। यदि पोर्टल सही ढंग से परोसा जाता है और क्लाइंट फिर भी विफल होता है, तो मतभेद बूटस्ट्रैप पथ में है, उपयोगकर्ता के पासवर्ड में नहीं।
TLS सत्यापन बंद करके या प्रमाणीकरण नीति ढीली करके तुलना को सफल न बनाएँ। यह एक निदान-योग्य कॉन्फ़िगरेशन बेमेल को ऐसे पथ में बदल देता है जो काम करता है पर सत्यापित नहीं है, और यही वह बदलाव है जो अस्थायी परीक्षण को स्थायी छिद्र में बदल देता है। Access Server का कनेक्शन-प्रोफ़ाइल दस्तावेज़ दोनों पीढ़ियों और अस्थायी-प्रोफ़ाइल प्रवाह का वर्णन करता है, और यही वह संदर्भ है जिसे प्रॉक्सी को दोषी मानने से पहले जाँचना चाहिए।
जब आर्टिफ़ैक्ट नया हो: इसके बजाय कंट्रोल चैनल पढ़ें
2.9-शैली की प्रोफ़ाइल के साथ क्लाइंट सीधे मूल VPN एंडपॉइंट पर जाता है। प्रोफ़ाइल में एंडपॉइंट, प्रयुक्त ट्रांसपोर्ट, और कंट्रोल-चैनल त्रुटि की जाँच करें। यदि क्लाइंट कभी HTTP अनुरोध नहीं करता, तो यह डिज़ाइन के अनुरूप है और लक्षण नहीं है।
यहीं प्रॉक्सी का प्रश्न भी आकार बदलता है। HTTPS अनलोड केवल-TCP स्ट्रीम को नहीं तोड़ सकता जिसे वह कभी देखता ही नहीं, परंतु वह उस डाउनलोड को अभी भी तोड़ सकता है जो प्रोफ़ाइल प्रकाशित करता है, और केवल-TCP फ़ॉरवर्डर UDP बिल्कुल नहीं ढोएगा। यह निष्कर्ष निकालने से पहले कि फ़्रंटएंड अप्रासंगिक है, जाँचें कि प्रोफ़ाइल कौन सा ट्रांसपोर्ट माँगती है।
एक ही स्ट्रीम के लिए TLS पासथ्रू एक संकीर्ण व्यवस्था है। यह UDP फ़ॉरवर्डिंग नहीं देता, और 443 पर डेमॉन के अपने सेवा-फ़ॉरवर्डिंग व्यवहार को पुनःउत्पन्न नहीं करता। यदि आपका फ़्रंटएंड इनमें से कोई एक करता है, तो बताएँ कौन सा, क्योंकि उपाय अलग है।
संकीर्ण रहने वाले उपाय
सबसे कम हस्तक्षेप वाली जाँच यह है कि परीक्षण खाते के लिए नई समर्थित प्रोफ़ाइल बनाएँ और उसी प्रमाणीकरण आवश्यकताओं के साथ इच्छित मूल एंडपॉइंट से जुड़ें। यदि वह काम करे और सुरक्षित रखी पुरानी प्रोफ़ाइल न करे, तो आपने एक ही कदम में आर्टिफ़ैक्ट को सर्वर और प्रॉक्सी से अलग कर दिया है।
उपयोगकर्ता-लॉक प्रोफ़ाइल का वितरण पुरानी बूटस्ट्रैप निर्भरता को पूरी तरह हटा देता है, क्योंकि विफल हो सकने वाला कोई अस्थायी-प्रोफ़ाइल आदान-प्रदान नहीं है। इसे इच्छित उपयोगकर्ता के लिए जारी किया जाना चाहिए, कभी किसी प्रशासक से कॉपी नहीं, और यह बदलता है कि क्लाइंट क्या करने के लिए अधिकृत है, इसलिए इसे कामचलाऊ उपाय नहीं, नीति निर्णय मानें।
फिर प्रकाशन लेआउट इस तरह ठीक करें कि हर आवश्यक पथ मौजूद हो: डाउनलोड और पोर्टल उपयोग के लिए वेब पथ, और उस ट्रांसपोर्ट पर मूल VPN पथ जिसकी प्रोफ़ाइल अपेक्षा करती हैं। प्रॉक्सी का काम एक ही परत में रखें। काम करती उपयोगकर्ता-लॉक सुरंग साबित करती है कि वह पथ काम करता है; यह साबित नहीं करती कि हर प्रॉक्सी व्यवस्था हर पीढ़ी का समर्थन करती है, और पुरानी बूटस्ट्रैप विफलता नए फ़ॉर्मेट की निंदा नहीं करती।
- प्रॉक्सी को छूने से पहले आर्टिफ़ैक्ट की पीढ़ी पहचानें।
- निर्धारित करें कि विफलता सुरंग से पहले होती है या उसके भीतर।
- पुष्टि करें कि फ़्रंटएंड क्या समाप्त करता है: HTTP, TCP स्ट्रीम, या UDP।
- नीति अपरिवर्तित रखते हुए नई जारी प्रोफ़ाइल को मूल एंडपॉइंट के सामने परखें।