सर्भर-लक प्रोफाइल 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।
- नीति अपरिवर्तित राखेर नयाँ जारी गरिएको प्रोफाइल मूल इन्डपोइन्टसामु परीक्षण गर्नुहोस्।