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 मार्गाला प्राधान्य द्या। कोणत्याही परिस्थितीत, बदलानंतर तोच प्रॉक्सी, गंतव्य आणि प्रोफाइल पुढील टप्प्यापर्यंत पोहोचतात याची खात्री करा; त्या पत्त्यावर पान लोड करणारा ब्राउझर वेगळा प्रोटोकॉल वापरतो आणि बोगद्याबद्दल काहीही सिद्ध करत नाही।