ब्रांच ब्राउज़र से प्रॉक्सी तक: दो कनेक्शन, दो रूट
ब्राउज़र प्रॉक्सी लिसनर से बात करता है, और प्रॉक्सी साइट से। दोनों कनेक्शन कॉन्फ़िगर करें और उन्हें दो अलग विफलताओं के रूप में जाँचें।
स्पष्ट प्रॉक्सी के पीछे का ब्रांच ब्राउज़र दो कनेक्शन खोलता है, और वे अलग-अलग कारणों से विफल होते हैं। पहला ब्राउज़र से प्रॉक्सी लिसनर तक है, जो ब्रांच VPN से होकर जाता है। दूसरा प्रॉक्सी से वेबसाइट तक है, जो प्रॉक्सी के अपने रिज़ॉल्वर, रूट और एग्रेस नीति का उपयोग करता है। जो सपोर्ट टिकट इन्हें एक ही प्रवाह मानते हैं, वे लोगों को घंटों तक गलत डिवाइस पर भेजते हैं। हर एक को जानबूझकर सेट करें और उसी क्रम में जाँचें।
चरण 1: दोनों प्रवाह लिखें
ब्राउज़र का तात्कालिक गंतव्य प्रॉक्सी लिसनर है, हर वह साइट नहीं जिसे उपयोगकर्ता अंततः देखता है। यह एक वाक्य इस डिज़ाइन की अधिकांश उलझन हल कर देता है।
branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> websiteअलग स्रोत, अलग रूट, अलग अनुमतियाँ। स्केच को परिवर्तन रिकॉर्ड में रखें, क्योंकि हर बाद की जाँच इसके दो आधों में से एक का संदर्भ देती है।
चरण 2: ब्राउज़र को लिसनर तक रास्ता दें
प्रॉक्सी होस्टनाम, लिसनर पोर्ट, प्रमाणीकरण आवश्यकताएँ और अनुमत ब्रांच स्रोत दर्ज करें। वह सूची पहले प्रवाह के लिए स्वीकृति मानदंड है, और इसमें निजी नाम रिज़ॉल्यूशन के साथ-साथ टनल रूट भी शामिल होना चाहिए।
इंटरनेट पर असीमित प्रॉक्सी प्रकाशित करने के बजाय इच्छित सेवा के लिए संकीर्ण नेटवर्क नियम लागू करें। प्रॉक्सी आंतरिक नेटवर्क पर रह सकता है जब उसके इच्छित क्लाइंट के पास उस तक समर्थित रास्ता हो।
चरण 3: केवल रूट तालिका नहीं, ब्राउज़र कॉन्फ़िगर करें
ब्राउज़र की प्रॉक्सी सेटिंग, PAC फ़ाइल या संगठन की प्रबंधित खोज तंत्र का उपयोग करें। रूट के साथ सामान्य वेबसाइट पैकेट प्रॉक्सी पते की ओर भेजने से ब्राउज़र प्रॉक्सी प्रोटोकॉल नहीं बोलने लगता; वह पारदर्शी अवरोधन है और दूसरे गेटवे डिज़ाइन का हिस्सा है।
लिखें कि कौन-से अनुप्रयोग सेटिंग का पालन करते हैं। मेल क्लाइंट, अपडेटर और गेम अक्सर नहीं करते, और वे सादा रास्ता ही उपयोग करते रहेंगे।
चरण 4: प्रॉक्सी का आगे का कनेक्शन सिद्ध करें
प्रॉक्सी को अपना रिज़ॉल्वर और वेबसाइट तक अनुमत रूट चाहिए, साथ ही उसकी इंटरनेट सीमा को जो भी फ़ायरवॉल या अनुवाद नीति चाहिए। लिसनर तक पहुँचने वाला ब्राउज़र इसमें से कुछ भी सिद्ध नहीं करता। दूसरा प्रवाह प्रॉक्सी से ही जाँचें, उसी गंतव्य और पोर्ट के साथ जो उपयोगकर्ता ने बताया।
HTTPS के लिए, CONNECT अनुरोधित गंतव्य तक टनल खोलता है। सामान्य फ़ॉरवर्डिंग प्रॉक्सी को डिक्रिप्ट किया हुआ पृष्ठ नहीं देती, और निरीक्षण का बहाना बनाकर प्रमाणपत्र सत्यापन बंद करना समाधान नहीं है।
चरण 5: चार विफलताओं में अंतर करें
प्रॉक्सी प्रमाणीकरण चुनौती लिसनर से 407 है। अस्वीकृत CONNECT प्रॉक्सी पर नीति निर्णय है, आमतौर पर अपनी स्थिति और लॉग पंक्ति के साथ। विफल आगे का कनेक्शन टाइमआउट या रीसेट जैसा दिखता है, जिसे प्रॉक्सी गंतव्य के विरुद्ध लॉग करता है। वेबसाइट का उत्तर इसका अर्थ है कि दोनों कनेक्शन काम कर गए और समस्या स्रोत पर है।
जो सीमा आपने देखी उसकी रिपोर्ट करें, यह सारांश नहीं कि VPN विफल हो गया।
चरण 6: दायरा तय करें और विकल्प की योजना बनाएँ
तय करें कि प्रॉक्सी या टनल उपलब्ध न होने पर क्या होगा, और स्पष्ट कहें कि यह डिज़ाइन कौन-सा ट्रैफ़िक कवर करता है। यह उन क्लाइंट से वेब एक्सेस ले जाता है जो प्रॉक्सी सेटिंग का पालन करते हैं; यह मेल, मनमाने डिवाइस प्रोटोकॉल या ऐसा सॉफ़्टवेयर नहीं ले जाता जो कॉन्फ़िगरेशन को अनदेखा करता है।
डिज़ाइन को अधिक क्लाइंट तक बढ़ाने से पहले स्वीकृत योजना के अंतर्गत आवश्यक ब्राउज़र संचालन और एक आवश्यक अस्वीकृति को मान्य करें।