HTTP प्रोक्सीमार्फत OpenVPN: पहिले CONNECT को जवाफ पढ्नुहोस्
CONNECT प्रोक्सीले बाइटहरू रिले गर्छ, त्यसैले दुवै छेउलाई TCP चाहिन्छ। प्रमाणपत्रलाई दोष दिनु अघि 407, 403 र 503 पढ्नुहोस्, र सर्भर प्रमाणीकरण खुला राख्नुहोस्।
VPN क्लाइन्टलाई कर्पोरेट HTTP प्रोक्सीतिर फर्काउनुहोस्, र पहिलो उपयोगी तथ्य यो हो कि प्रोक्सीले VPN को प्रोटोकल बोल्दैन। यसले तपाईंले भनेको ठेगानामा साधारण TCP जडान खोल्छ र त्यसपछि छेउतिर सर्छ, जसले तपाईंको क्लाइन्ट र सर्भरलाई त्यो स्ट्रिमबाट आफ्नै आदानप्रदान गर्न दिन्छ। क्लाइन्टलाई चाहिने सबै कुरा, ट्रान्सपोर्ट प्रकारदेखि सर्भरको श्रोतासम्म, त्यो व्यवस्थासँग मिल्नुपर्छ। दुई असमझदारीले अधिकांश असफलताहरू व्याख्या गर्छन्: CONNECT प्रोक्सीतिर लक्षित UDP प्रोफाइल, र VPN त्रुटि ठानिएको प्रोक्सीको जवाफ।
प्रोक्सीले के बोक्छ र के बोक्दैन
प्रोक्सी केवल एउटा ट्रान्सपोर्ट चरण हो। यो तपाईंको ब्राउजर प्रोक्सी बन्दैन, सुरुङबाट तपाईंले भेट्ने साइटहरू क्यास गर्दैन, र कसैले जानाजान परीक्षण मिलाएको छैन भने भित्री ट्राफिक देख्दैन। यसले खोल्ने सुरुङ डिजाइनअनुसार नै यसका लागि अपारदर्शी छ।
यसको अर्थ प्रोक्सीले मिल्ने श्रोता नभएको सर्भर मर्मत गर्न सक्दैन भन्ने पनि हो। गन्तव्यमा पुग्ने अनुमति र त्यो गन्तव्यमा सुन्ने सेवा दुई अलग तथ्य हुन्, र पहिलो मात्र प्रोक्सी प्रशासकको हो।
वाहक दुवै छेउमा TCP हुनुपर्छ
परम्परागत CONNECT प्रोक्सीले बाइट स्ट्रिम मात्र रिले गर्छ , त्यसैले क्लाइन्टले स्ट्रिम ट्रान्सपोर्ट प्रयोग गर्नुपर्छ। त्यो अवस्थाको क्लाइन्ट खण्ड यस्तो देखिन्छ:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128सर्भर पक्षलाई remote लाइनमा भनिएको पोर्टमा वास्तविक TCP श्रोता चाहिन्छ। प्रोफाइलमा proto udp लाई proto tcp-client मा बदल्दा स्ट्रिम अपेक्षा गर्ने क्लाइन्ट बन्छ; यसले अर्को छेउमा स्ट्रिम बनाउँदैन। यदि त्यही सर्भरले त्यो पोर्टमा UDP बाट पनि जवाफ दिन्छ भने त्यो अर्को श्रोता हो, त्यही श्रोताको दोस्रो मोड होइन।
जहाँ छुट्टै TCP इन्स्टेन्स छ, त्यसको सुरुङ उपकरण, ठेगाना पूल र राउटिङ आफ्नै स्रोत हुन्। काम गर्ने कन्फिगरेसन प्रतिलिपि गरेर ट्रान्सपोर्ट शब्द बदल्दा ती स्रोत मूल इन्स्टेन्सतिरै देखाइरहन्छन्, जसले प्रमाणीकरण भएर पनि केही राउट नगर्ने जडान बनाउँछ।
VPN नतिजाअघि प्रोक्सीको जवाफ पढ्नुहोस्
क्लाइन्टको पहिलो आदानप्रदान गन्तव्य होस्ट र पोर्ट नाम दिने अनुरोध लाइन हो। त्यो लाइनको जवाफले बाइट स्ट्रिम छ कि छैन भन्छ, र कुनै प्रमाणपत्र वा प्रमाण जाँच्नुअघि आउँछ:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
CONNECT मा 200 वर्गको जवाफ भनेको स्ट्रिम छ। गेटवे प्रमाणपत्र विश्वसनीय छ कि छैन, साझा कुञ्जी मिल्छ कि मिल्दैन, वा प्रयोगकर्ता खाता मान्य छ कि छैन भन्ने यसले बताउँदैन। ती जाँचहरू पछि, स्ट्रिमभित्र हुन्छन्, र ती HTTP स्टेटस लाइनको सट्टा क्लाइन्टका आफ्नै सन्देशहरूले असफल हुन्छन्। क्लाइन्ट लगमा पहिलो OpenVPN घटना प्रोक्सी ह्यान्डशेकपछि हेर्नुहोस्, विन्डो बन्द हुनुअघिको अन्तिम लाइन होइन।
प्रोक्सी प्रमाण र VPN प्रमाण प्रायः फरक टोलीका फरक पहिचान हुन्। 407 VPN खाताको नराम्रो पासवर्ड होइन, र अस्वीकृत प्रमाणपत्र प्रोक्सी अनुमतिको समस्या होइन।
CONNECT ले के प्रकट गर्दैन
स्पष्ट CONNECT सुरुङ अवरोध होइन। प्रोक्सीले बाइट अगाडि पठाउँछ र VPN को TLS सत्र अन्त्य गर्दैन, त्यसैले सर्भर प्रमाणपत्रको क्लाइन्ट जाँच अर्थपूर्ण रहन्छ र खुला रहनुपर्छ। प्रोक्सी पार गर्न प्रमाणीकरण बन्द गर्नु तपाईंको समस्याभन्दा फरक समस्या समाधान गर्नु हो।
संस्थाले जानाजान TLS अन्त्य गरेर परीक्षण गर्ने छुट्टै व्यवस्था पनि छन्। तिनलाई आफ्नै विश्वास कन्फिगरेसन र आफ्नै नीति निर्णय चाहिन्छ, र ती साधारण http-proxy लाइनले माग्ने कुरा होइनन्।
TCP भित्रको TCP को लागत
सुरुङ TCP माथि बोक्दा बाहिरी स्ट्रिम क्रममा र पुनःप्रेषणसहित रहन्छ, र भित्री ट्राफिक पनि सामान्यतया TCP हुन्छ। दुई पुनःप्राप्ति संयन्त्र समन्वय गर्दैनन्, त्यसैले एउटा हराएको खण्डले त्यो बाहिरी स्ट्रिम साझा गर्ने सबैलाई पुनःप्रेषण नहुँदासम्म रोक्न सक्छ। यो अनुकूलताका लागि साँचो साटासाट हो, निःशुल्क स्तरोन्नति होइन।
सञ्जालले विकल्प नछोड्दा प्रोक्सी मार्ग प्रयोग गर्नुहोस्, र नीतिले अनुमति दिने ठाउँमा सिधा UDP मार्गलाई प्राथमिकता दिनुहोस्। जे भए पनि, परिवर्तनपछि त्यही प्रोक्सी, गन्तव्य र प्रोफाइल अर्को चरणमा पुग्छन् भनी पुष्टि गर्नुहोस्; त्यो ठेगानामा पृष्ठ लोड गर्ने ब्राउजरले अर्कै प्रोटोकल चलाउँछ र सुरुङबारे केही पनि प्रमाणित गर्दैन।