प्रति प्रोफ़ाइल प्रॉक्सी: DNS, प्रमाणीकरण और विफलता

यह गाइड Chromium के दर्ज नेटवर्क व्यवहार को आधार मानती है। दूसरे ब्राउज़र और उत्पाद अलग चुनाव कर सकते हैं तथा मैनेजर Chromium के आसपास स्थानीय नेटवर्क ब्रोकर जोड़ सकता है। ठीक उसी बिल्ड का व्यवहार जाँचें जिसे आप चलाते हैं।

चार स्वतंत्र सवालों से शुरुआत करें

प्रॉक्सी रिकॉर्ड में आम तौर पर स्कीम, एंडपॉइंट, पोर्ट और कभी प्रमाणीकरण संदर्भ होता है। उसके बाद भी चार नीति सवाल बाकी हैं:

1. कवरेज: कौन-से ब्राउज़र अनुरोध और प्रोटोकॉल इस प्रॉक्सी से जाएँगे?
2. नाम समाधान: गंतव्य होस्टनाम का पता डिवाइस लगाएगा या प्रॉक्सी?
3. प्रमाणीकरण: कौन-सी क्लाइंट और प्रॉक्सी विधियाँ साथ काम करती हैं और क्रेडेंशियल कहाँ रखे हैं?
4. विफलता: कनेक्शन त्रुटि अनुरोध रोकेगी, दूसरी प्रॉक्सी आज़माएगी या सीधा रास्ता लेगी?

इन्हें एक ‘प्रॉक्सी चालू’ स्विच समझने से अधिकांश आश्चर्य होते हैं। Chromium प्रॉक्सी चयन को URL स्तर का समाधान बताता है: गंतव्य का पता लगने से पहले URL प्रॉक्सी विकल्पों की क्रमबद्ध सूची बना सकता है। बाइपास और वैकल्पिक रास्ते उसी निर्णय का हिस्सा हैं।

प्रति प्रोफ़ाइल प्रॉक्सी क्या कवर करती है

Google की ProxySettings नीति Chrome प्रोफ़ाइल स्तर पर लागू होती है। इसमें direct, system, auto-detected, fixed-server या PAC-script मोड, स्पष्ट बाइपास और अनिवार्य PAC फ़ील्ड हो सकते हैं।

यह सीमा VPN या OS नेटवर्क नेमस्पेस से छोटी है। यह ब्राउज़र नेटवर्क संदर्भ के अनुरोध नियंत्रित करती है। अपने आप इन पर लागू नहीं होती:

• डेस्कटॉप मैनेजर की अपनी API कॉल;
• अलग प्रक्रिया का ऐप या ब्राउज़र अपडेटर;
• OS की DNS और कनेक्टिविटी जाँच;
• डाउनलोड की गई फ़ाइल से खुला दूसरा ऐप;
• एक्सटेंशन का अलग नेटिव सहायक;
• अंतर्निहित लूपबैक बाइपास से जुड़ी स्थानीय सेवा; या
• ऐसा प्रोटोकॉल जिसे चुना प्रॉक्सी रास्ता नहीं ले जा सकता।

कुछ घटकों का अपना प्रॉक्सी समर्थन हो सकता है। उसे अलग निर्दिष्ट और जाँचना होगा। ‘प्रोफ़ाइल ट्रैफ़िक इस प्रॉक्सी से जाता है’ दावे में शामिल प्रक्रियाएँ और प्रोटोकॉल बताने चाहिए, पूरे डिवाइस की रूटिंग का संकेत नहीं देना चाहिए।

एक HTTPS अनुरोध का रास्ता देखें

सामान्य HTTPS नेविगेशन में कई चरण होते हैं।

1. रास्ता चुनना

ब्राउज़र तय नियम, प्रॉक्सी ऑटो-कॉन्फ़िगरेशन स्क्रिप्ट या सिस्टम सेटिंग देखता है। बाइपास मेल होने पर सीधा कनेक्शन चुना जा सकता है। सूची पहले मुख्य प्रॉक्सी, फिर विकल्प चुन सकती है; सीधा रास्ता अनुमत हो तो DIRECT भी हो सकता है।

Chromium localhost और लिंक-लोकल गंतव्यों के लिए अंतर्निहित बाइपास भी लगाता है। इससे स्थानीय ओरिजिन बाहरी नियंत्रित प्रॉक्सी सेटिंग से बचते हैं, लेकिन व्यापक ‘सारा ट्रैफ़िक’ दावे को स्पष्ट करना पड़ता है।

2. प्रॉक्सी का पता लगाना और जुड़ना

प्रॉक्सी एंडपॉइंट होस्टनाम हो तो डिवाइस को उसका पता लगाकर जुड़ने का तरीका चाहिए। गंतव्य DNS दूर होने से यह शुरुआती खोज खत्म नहीं होती। यहाँ की विफलता उस स्थिति से अलग है जिसमें प्रॉक्सी उपलब्ध है लेकिन गंतव्य नहीं ढूँढ़ पा रही।

3. प्रॉक्सी से प्रमाणित होना

क्रेडेंशियल माँगने वाली HTTP प्रॉक्सी सामान्यतः चुनौती के साथ 407 Proxy Authentication Required लौटाती है। RFC 9110 यह प्रक्रिया और Proxy-Authenticate व Proxy-Authorization फ़ील्ड तय करता है।

Chromium मैनुअल प्रॉक्सी सेटिंग में शामिल उपयोगकर्ता नाम और पासवर्ड इस्तेमाल नहीं करता। उसके प्रॉक्सी दस्तावेज़ बताते हैं कि प्रमाणीकरण सामान्य ब्राउज़र क्रेडेंशियल प्रक्रिया से होता है। इसलिए मैनेजर को समर्थित चुनौती के लिए स्पष्ट इंटीग्रेशन चाहिए, यह वादा नहीं कि कोई भी user:password@host स्ट्रिंग चलेगी।

4. गंतव्य कनेक्शन बनाना

HTTP प्रॉक्सी के साथ Chromium गंतव्य नाम समाधान प्रॉक्सी को देता है। HTTPS गंतव्य के लिए ब्राउज़र प्रॉक्सी से CONNECT टनल बनवाता है और उसके भीतर गंतव्य से एंड-टू-एंड TLS करता है।

प्रॉक्सी को गंतव्य होस्टनाम और कनेक्शन मेटाडेटा फिर भी पता चलता है। क्लाइंट से प्रॉक्सी तक साधारण HTTP हो तो उस हिस्से पर CONNECT अनुरोध और होस्टनाम सुरक्षित नहीं होते। HTTPS प्रॉक्सी ब्राउज़र और प्रॉक्सी के बीच TLS जोड़ती है, जिससे बीच के पर्यवेक्षकों से मेटाडेटा बचता है। प्रॉक्सी स्वयं अनुरोधित गंतव्य देख सकती है।

प्रॉक्सी सामान्यतः टनल के भीतर HTTPS पेज सामग्री नहीं पढ़ सकती। TLS इंटरसेप्शन अलग भरोसे का मॉडल है: क्लाइंट ऐसी प्रमाणपत्र अथॉरिटी पर भरोसा करता है जो मध्यस्थ को TLS समाप्त करके फिर बनाने देती है। इसे सामान्य फ़ॉरवर्डिंग से चुपचाप नहीं मिलाना चाहिए।

DNS की ज़िम्मेदारी प्रॉक्सी प्रकार से बदलती है

Chromium का दर्ज व्यवहार अलग प्रकार में अलग है:

रास्ता	गंतव्य नाम समाधान	महत्वपूर्ण सीमा
सीधा या बाइपास	डिवाइस या ब्राउज़र रिज़ॉल्वर	गंतव्य ट्रैफ़िक प्रोफ़ाइल प्रॉक्सी के बिना जाता है
HTTP प्रॉक्सी	प्रॉक्सी पर	साधारण HTTP कनेक्शन में HTTP अनुरोध खुलते हैं; HTTPS में CONNECT होता है
HTTPS प्रॉक्सी	प्रॉक्सी पर	क्लाइंट को प्रॉक्सी TLS प्रमाणपत्र जाँचना चाहिए
SOCKS4 प्रॉक्सी	क्लाइंट पर	केवल IPv4 गंतव्य; Chromium में SOCKS4a विकल्प नहीं
SOCKS5 प्रॉक्सी	प्रॉक्सी पर	Chromium TCP URL अनुरोध के लिए इस्तेमाल करता है और SOCKS5 प्रमाणीकरण समर्थन नहीं बताता

RFC 1928 SOCKS5 अनुरोध में डोमेन नाम और कई प्रमाणीकरण विधि पहचानकर्ता देता है। प्रोटोकॉल क्षमता क्लाइंट लागूकरण की गारंटी नहीं है। Chromium अभी गंतव्य नाम SOCKS5 प्रॉक्सी को देता है, लेकिन बताता है कि उसका अंतर्निहित SOCKS5 क्लाइंट प्रॉक्सी प्रमाणीकरण विधियाँ नहीं देता। इसलिए उपयोगकर्ता नाम और पासवर्ड वाला SOCKS5 प्रदाता समर्थित मध्यस्थ या दूसरी स्कीम माँग सकता है। रिकॉर्ड स्वीकार करने से पहले ब्राउज़र लागूकरण जाँचें।

DNS-over-HTTPS एक और परत है। Chrome की DnsOverHttpsMode नीति में automatic असुरक्षित DNS पर लौट सकता है, जबकि secure सुरक्षित DNS विफल होने पर समाधान रोकता है। यह नीति ब्राउज़र स्तर की बताई गई है, जबकि ProxySettings प्रोफ़ाइल स्तर की है। यह अंतर चेताता है कि एक सेटिंग पर ‘प्रोफ़ाइल’ लिखा होने से हर DNS नियंत्रण उसी दायरे का नहीं होता।

हर प्रोफ़ाइल अलग ब्राउज़र प्रक्रिया में चलाने वाला उत्पाद प्रभावी सीमा छोटी कर सकता है, लेकिन यह लागूकरण का निर्णय है। जाँचें। प्रमाण में अलग दिखना चाहिए:

• प्रॉक्सी एंडपॉइंट का नाम समाधान;
• अनुरोधित गंतव्य का नाम समाधान;
• सीधे या बाइपास अनुरोधों का DNS;
• सुरक्षित DNS की शुरुआती खोज और वैकल्पिक रास्ता; और
• प्रोफ़ाइल नेटवर्क संदर्भ से बाहर घटकों का DNS।

प्रमाणीकरण में अनुकूलता और रहस्य प्रबंधन दोनों हैं

Chromium HTTP प्रॉक्सी के लिए Basic, Digest, Negotiate और NTLM बताता है। HTTPS प्रॉक्सी सुरक्षित क्लाइंट-प्रॉक्सी कनेक्शन जोड़ती है और क्लाइंट प्रमाणपत्र भी दे सकती है। SOCKS5 मानक में प्रमाणीकरण विधियाँ होने पर भी Chromium के अंतर्निहित प्रॉक्सी क्लाइंट में SOCKS4 और SOCKS5 प्रमाणीकरण लागू नहीं है।

संगत विधि भी गलत ट्रांसपोर्ट में असुरक्षित हो सकती है। RFC 7617 बताता है कि Basic क्रेडेंशियल केवल Base64 में एन्कोड होते हैं और TLS जैसे सुरक्षित चैनल की ज़रूरत है। साधारण HTTP प्रॉक्सी पर Basic इस्तेमाल करने से उस कनेक्शन को देख सकने वाले को प्रॉक्सी पासवर्ड मिल सकता है।

मैनेजर को ये डेटा अलग रखने चाहिए:

• गैर-गुप्त एंडपॉइंट विवरण, जैसे स्कीम, होस्ट, पोर्ट और प्रदाता लेबल;
• जीवनचक्र या नेटवर्क सेवा का रहस्य संदर्भ;
• सुरक्षित स्टोरेज में वास्तविक क्रेडेंशियल;
• UI और ऑडिट के लिए संवेदनशील जानकारी रहित कनेक्शन स्थिति; और
• केवल नियंत्रित सहायता प्रक्रिया से उपलब्ध निदान विवरण।

सामान्य स्क्रीन, लॉग, API, निर्यात और ऑटोमेशन आउटपुट को प्रॉक्सी पासवर्ड की आवश्यकता नहीं होती। ऑपरेटर को आम तौर पर इतना जानना होता है कि प्रमाणीकरण विफल हुआ, कौन-सी विधि की चुनौती थी, कौन-सा एंडपॉइंट था और कोई वैकल्पिक रास्ता चुना गया या नहीं।

विफलताएँ कैसे दिखती हैं

विफलता	संभावित लक्षण	जाँचने वाली सीमा
गलत प्रॉक्सी स्कीम	TLS या प्रोटोकॉल हैंडशेक विफल	HTTPS को HTTP या उलटा तो नहीं बताया?
प्रॉक्सी होस्टनाम नहीं मिलता	प्रॉक्सी तक पहुँचने से पहले विफलता	शुरुआती खोज किस रिज़ॉल्वर ने की?
प्रॉक्सी पोर्ट अनुपलब्ध	टाइमआउट या कनेक्शन अस्वीकृत	सूची में अगला विकल्प दूसरी प्रॉक्सी या DIRECT है?
चुनौती समर्थित नहीं	बार-बार 407 या लॉगिन संकेत	क्या ब्राउज़र उस विधि को लागू करता है?
गलत या समाप्त क्रेडेंशियल	देने के बाद भी 407	रहस्य संदर्भ मिला और आउटपुट से मान छिपा रहा?
HTTPS प्रॉक्सी प्रमाणपत्र विफल	सुरक्षित कनेक्शन अस्वीकृत	प्रमाणपत्र सत्यापन बरकरार है?
प्रॉक्सी गंतव्य नहीं ढूँढ़ सकती	होस्ट या टनल विफलता	क्या क्लाइंट सीधे गंतव्य से नहीं जुड़ा?
CONNECT अस्वीकृत	उस गंतव्य पर HTTPS विफल	इसे नीति माना गया, बाइपास की अनुमति नहीं?
PAC फ़ाइल अनुपलब्ध	प्रॉक्सी चयन रुकता या रास्ता बदलता है	PAC अनिवार्य है या चुपचाप DIRECT संभव है?
बाइपास बहुत व्यापक	कुछ साइट सीधे जुड़ती हैं	सटीक होस्ट, उपडोमेन, पोर्ट और अंतर्निहित नियम समझे हैं?
WebRTC दूसरा इंटरफ़ेस लेता है	मीडिया रास्ता पेज ट्रैफ़िक से अलग	गैर-प्रॉक्सी UDP बंद है?
बदलाव के बाद पुराना कनेक्शन बचता है	कुछ समय पुराना रास्ता सक्रिय	कनेक्शन समाप्त होते हैं या प्रोफ़ाइल फिर शुरू होती है?
निदान में अधिक विवरण	URL, होस्टनाम या रहस्य सहायता फ़ाइल में	कौन-सा जानकारी हटाने का मोड और प्रतिधारण नियम है?

Chromium का वैकल्पिक रास्ता चयन पिछली स्थिति याद रखता है। कनेक्शन स्तर पर विफल प्रॉक्सी कुछ समय के लिए खराब चिह्नित होकर पीछे जा सकती है। सूची में DIRECT हो तो बाद के अनुरोध प्रॉक्सी के बिना जा सकते हैं। CONNECT अस्वीकृति अलग सँभाली जाती है, क्योंकि वह प्रॉक्सी अनुपलब्ध होने के बजाय जानबूझकर गंतव्य नीति हो सकती है।

PAC विफलता पर खास ध्यान दें। Chromium बताता है कि PAC अनिवार्य न हो तो अनुपलब्ध फ़ाइल चुपचाप सीधे समाधान पर लौटा सकती है। ProxySettings में ProxyPacMandatory इसी सीधे रास्ते को रोकने के लिए है।

WebRTC और UDP का अलग निर्णय चाहिए

पेज के WebRTC रास्ते सामान्य HTTP/HTTPS URL अनुरोधों जैसे नहीं हो सकते। Chrome की डिफ़ॉल्ट WebRtcIPHandling नीति सभी उपलब्ध इंटरफ़ेस इस्तेमाल कर सकती है। उसका disable_non_proxied_udp मोड WebRTC को सार्वजनिक इंटरफ़ेस पर TCP तक सीमित करता है, जब तक कॉन्फ़िगर प्रॉक्सी UDP न दे।

नीति प्रोफ़ाइल स्तर की है, इसलिए प्रॉक्सी के लिए प्रासंगिक है, लेकिन अलग नियंत्रण रहती है। इससे मीडिया प्रदर्शन घट सकता है या सीधे UDP वाला वर्कफ़्लो टूट सकता है। समझौता स्पष्ट चुनें और जाँचें। केवल पेज सफल लोड होने से पूर्ण प्रॉक्सी नियंत्रण का दावा न करें।

तय करें कि विफलता पर रुकना है या उपलब्ध रहना है

उपलब्धता प्राथमिकता वाली सामान्य ब्राउज़िंग प्रोफ़ाइल में सीधा वैकल्पिक रास्ता वैध हो सकता है। जिस काम का प्राधिकरण, गोपनीयता या क्षेत्रीय परीक्षण की वैधता खास निकास रास्ते पर निर्भर हो, उसमें यह असुरक्षित है।

अच्छी प्रोफ़ाइल नीति व्यवहार का नाम देती है:

• अनिवार्य प्रॉक्सी: चुना रास्ता न चल सके तो संबंधित अनुरोध रोकें।
• स्वीकृत प्रॉक्सी समूह: केवल समान नीति वाले नामित विकल्प आज़माएँ।
• सीधा रास्ता अनुमत: बदलाव दिखाएँ और रहस्य मान के बिना घटना दर्ज करें।
• स्पष्ट बाइपास: गंतव्य श्रेणी और सीधी पहुँच की आवश्यकता दर्ज करें।

UI लॉन्च से पहले और विफलता के बाद रास्ते की स्थिति दिखाए। चुपचाप प्रॉक्सी से सीधे जाने पर नेटवर्क त्रुटि काम की सही होने की समस्या बन जाती है: गलत रास्ते से काम सफल दिख सकता है।

सुरक्षित परीक्षण सूची

अपने या जाँचने की अनुमति वाले एंडपॉइंट और DNS ज़ोन लें। चलाने से पहले अपेक्षित परिणाम दर्ज करें।

1. घोषित स्कीम को वास्तविक एंडपॉइंट ट्रांसपोर्ट से जाँचें।
2. HTTP, HTTPS, WebSocket और आवश्यक WebRTC सफलता की पुष्टि करें।
3. नियंत्रित गंतव्य पर निकास पता देखें।
4. देखें कि गंतव्य और प्रॉक्सी होस्टनाम की खोज कौन-से रिज़ॉल्वर करते हैं।
5. परीक्षण क्रेडेंशियल समाप्त करें और पुष्टि करें कि UI, लॉग या ऑटोमेशन आउटपुट में वास्तविक मान नहीं आता।
6. टेस्ट प्रॉक्सी अनुपलब्ध करके तय रोक या वैकल्पिक रास्ते का परिणाम जाँचें।
7. एक नियंत्रित CONNECT गंतव्य रोकें और जाँचें कि नीति अस्वीकृति सीधी पहुँच नहीं बनती।
8. टेस्ट PAC अनुपलब्ध करके अनिवार्य व्यवहार जाँचें।
9. आवश्यक सटीक, उपडोमेन, स्थानीय, लिंक-लोकल, IPv4 और IPv6 बाइपास मामले आज़माएँ।
10. सक्रिय कनेक्शन के दौरान प्रॉक्सी बदलें और नया रास्ता कब लागू होता है, जाँचें।
11. केवल आवश्यक निदान विवरण लें, फिर प्रतिधारण और मिटाना सत्यापित करें।

Chromium का NetLog मार्गदर्शन नेटवर्क लॉग को गोपनीयता और सुरक्षा का विषय मानता है। सीमित मोड संवेदनशील फ़ील्ड छोड़ सकते हैं, जबकि विस्तृत मोड में कुकी या प्रमाणीकरण हेडर हो सकते हैं। सहायता फ़ाइल को उसके नाम के बजाय वास्तविक कैप्चर मोड के अनुसार सँभालें।