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 मार्ग पसंद करें। किसी भी हाल में, बदलाव के बाद पुष्टि करें कि वही प्रॉक्सी, गंतव्य और प्रोफ़ाइल अगले चरण तक पहुँचते हैं; उस पते पर पेज लोड करने वाला ब्राउज़र दूसरा प्रोटोकॉल चलाता है और सुरंग के बारे में कुछ साबित नहीं करता।