सर्व्हर-लॉक प्रोफाइल 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 |
अपग्रेड आधीच जारी केलेली प्रोफाइल पुन्हा लिहितातच असे नाही, त्यामुळे सध्याची सर्व्हर आवृत्ती अजूनही जुनी कलाकृती वितरित करू शकते। सर्व्हर बिल्ड काय शक्य आहे ते सांगते, या वापरकर्त्याने काय आयात केले ते नाही।
तुमची शाखा निवडणाऱ्या तीन अटी
पहिली अट कलाकृतीची पिढी आहे। फाइल मागा, ती कशी तयार झाली ते पहा, आणि ती आयात करणाऱ्या क्लायंटची आवृत्ती नोंदवा। फाइलमधून पिढी ठरवता येत नसेल, तर चाचणी खात्यासाठी जारी केलेले नवीन प्रोफाइल सर्व्हर आज काय तयार करतो ते सांगेल, आणि ही माहिती अयशस्वी वापरकर्त्याकडील माहितीपेक्षा वेगळी आहे।
दुसरी अट म्हणजे तुमचे फ्रंटएंड प्रत्यक्षात काय संपवते। TLS उतरवणारी सातव्या स्तराची HTTP रिव्हर्स प्रॉक्सी चौथ्या स्तराच्या 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।
- धोरण अपरिवर्तित ठेवून नव्याने जारी केलेले प्रोफाइल मूळ एंडपॉइंटसमोर तपासा।