Mac VPN और PAC प्रॉक्सी: दो निर्णय, एक सेटिंग नहीं

आपका Mac एक नीति स्क्रिप्ट डाउनलोड करता है और फिर उस स्क्रिप्ट से पूछता है कि किसी अनुरोध को कौन-सा मध्यस्थ इस्तेमाल करना चाहिए, जबकि टनल केवल यह तय करता है कि चुने गए हॉप तक कैसे पहुँचा जाए। दोनों उत्तर एक ही सॉकेट पर पहुँचते हैं, इसलिए दोनों के सफल होने के बाद विफल होने वाला अनुरोध दो होने पर भी एक खराबी जैसा दिखता है। डाउनलोड को चयन से और चयन को मार्ग से अलग करना इन टिकटों का अधिकांश काम है। नीचे का क्रम वही करता है जो macOS वास्तव में करता है, साथ में वे जाँचें जो हर चरण को दृश्य बनाती हैं।

PAC पता और प्रॉक्सी कहाँ अलग होते हैं

https://config.corp.example/proxy.pac जैसा पता डाउनलोड करने के लिए एक दस्तावेज़ का नाम देता है, और वह दस्तावेज़ उस सर्वर का नाम देता है जिससे ट्रैफ़िक भेजा जाए। URL को प्रॉक्सी होस्ट फ़ील्ड में चिपकाने से क्लाइंट से ऐसे फ़ाइल सर्वर के लिए प्रॉक्सी कनेक्शन खोलने को कहा जाता है जो ऐसा कभी नहीं सुनता। फ़ाइल के अंदर एक फंक्शन है जिसे क्लाइंट हर अनुरोध पर कॉल करता है, और उसका लौटाया मान उस एक गंतव्य के लिए अगला हॉप है। यह अप्रत्यक्षता बताती है कि एक ही नेटवर्क सेवा पर दो मशीनें, दोनों के पास सही URL होने पर भी, अलग व्यवहार क्यों कर सकती हैं। यह यह भी बताती है कि नीति में बदलाव किसी के प्रॉक्सी को छुए बिना क्यों लागू हो जाता है।

नीचे किसी भी चीज़ की व्याख्या करने से पहले स्क्रिप्ट पढ़ें, क्योंकि उसके अंदर के नियम संगठन के अपवाद और उनके लागू होने का क्रम लेकर चलते हैं। जल्दी आने वाली चौड़ी श्रेणी बाद के आंतरिक प्रत्यय को ढक सकती है, और जिस होस्ट को स्पष्ट रूप से प्रॉक्सी छोड़नी चाहिए वह उसका इस्तेमाल करता रहता है। जब कोई ज़ोर दे कि नीति ग़लत है, तो स्क्रिप्ट ही एकमात्र जगह है जहाँ वह दावा तय होता है।

स्क्रिप्ट को कुछ भी तय करने से पहले लाना पड़ता है

नीति डाउनलोड करने के लिए हल किया गया नाम और फ़ाइल को परोसने वाले तक का मार्ग चाहिए, और जुड़ी हुई टनल इनमें से कुछ भी सुनिश्चित नहीं करती। यदि होस्ट केवल निजी DNS से हल होता है, तो उस समय इस्तेमाल हो रहा रिज़ॉल्वर तय करता है कि डाउनलोड शुरू हो सकता है या नहीं। यदि होस्ट निजी श्रेणी में है, तो मार्ग इसी मशीन से होना चाहिए, किसी सहकर्मी के लैपटॉप से नहीं। किसी पिछले सत्र में कैश की गई प्रति कैश ख़त्म होने या मशीन के फिर से शुरू होने तक यह सब छिपा देती है।

नीचे दी गई तीन जाँचें क्रम से चलाएँ और पहली विफलता पर रुक जाएँ, क्योंकि चरणों का कारण एक नहीं है। साथ मिलकर वे दिखाती हैं कि नीति कॉन्फ़िगर है या नहीं, उस तक पहुँचा जा सकता है या नहीं, और वह क्या लौटाती है।

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

पहला कमांड सक्रिय सेवा के लिए प्रॉक्सी शब्दकोश छापता है, जिसमें सिस्टम के पास मौजूद कोई भी ऑटो-कॉन्फ़िगरेशन URL शामिल है। दूसरा एक नामित सेवा से जुड़ा URL बताता है, जो Wi-Fi और Ethernet के बीच घूमने वाले लैपटॉप पर मायने रखता है। तीसरा फ़ाइल को रेंडर किए बिना लाता है, ताकि 404, टाइमआउट और रिज़ॉल्वर विफलता अलग पहचानी जा सकें। यदि वह अंतिम कमांड स्क्रिप्ट लौटाता है जबकि एप्लिकेशन अब भी विफल हो रहे हैं, तो समस्या पहले ही लाने से आगे बढ़ चुकी है।

DIRECT उत्तर वास्तव में क्या छोड़ता है

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

DIRECT को VPN के बाहर पढ़ना वह ग़लती है जो लोगों को ग़लत सेटिंग्स पैनल तक भेजती है। उल्टी तस्वीर भी उतनी ही आम है, क्योंकि निजी प्रॉक्सी तक बँटे मार्ग से पहुँचा जा सकता है जबकि बाकी मशीन टनल से बाहर रहती है। तब गंतव्य जो बताता है वह प्रॉक्सी के अपने निर्गम का होता है, जो किसी दूसरे देश में हो सकता है। एक आंतरिक होस्ट और एक सार्वजनिक होस्ट के लिए अपेक्षा लिखना इसे जल्दी खोल देता है, क्योंकि स्क्रिप्ट अक्सर दोनों को अलग जवाब देती है। एक बार जान लें कि किस हॉप ने पता बनाया, तो रिपोर्ट रहस्यमय रहना बंद कर देती है।

तीन विफलताएँ जो एक ही त्रुटि पृष्ठ के रूप में सामने आती हैं

नीति डाउनलोड होने में विफल हो सकती है, चुनी गई प्रॉक्सी अप्राप्य हो सकती है, और सेवा तक पहुँचा कोई अनुरोध वहाँ अब भी ठुकराया जा सकता है। तीनों टाइमआउट या सामान्य त्रुटि पृष्ठ के रूप में आते हैं, और कोई भी उस चरण का नाम नहीं बताता जो टूटा। त्रुटि के बगल में निर्णय कैद करना ही उन्हें अलग करता है। नीचे दी गई दो जाँचें उस हॉप को परखती हैं जिसे स्क्रिप्ट ने चुना, हर उस शाखा के लिए एक जो वह लौटा सकती है।

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

प्रॉक्सी से पूरा हुआ कनेक्शन प्रश्न को प्रमाणीकरण या प्रॉक्सी की अपनी नीति की ओर ले जाता है, जिसका मालिक अलग है। मार्ग में प्रॉक्सी के बिना आंतरिक होस्ट से पूरा हुआ कनेक्शन मार्ग को बाहर करता है और नीति की ओर इशारा करता है। दोनों कमांड macOS प्रॉक्सी शब्दकोश को नज़रअंदाज़ करते हैं जब तक कि शेल प्रॉक्सी चर निर्यात न करे, इसलिए पहले उन्हें साफ़ करें। दोनों में से कोई जाँच दूसरी को साबित नहीं करती, इसीलिए एक त्रुटि पृष्ठ इतनी देर तक भ्रमित करता है।

टिकट के साथ क्या सौंपना है

सक्रिय नेटवर्क सेवा, PAC URL, विफल हो रहे होस्ट के लिए मूल्यांकन परिणाम और वह चरण जहाँ त्रुटि दिखी, भेजें। ये चार अगले व्यक्ति को यह अनुमान लगाने के बजाय कि कौन-सी परत शामिल थी, निर्णय दोबारा बनाने देते हैं। परीक्षण के क्षण में टनल की स्थिति जोड़ें, क्योंकि फिर से जुड़ने से पहले पकड़ा गया परिणाम पुराना होता है। स्क्रिप्ट का संशोधन भी रखें, क्योंकि नीति फ़ाइल बिना सूचना के बदलती है और कल का उत्तर अब मान्य न हो।

दर्ज करें कि जब स्क्रिप्ट नहीं लाई जा सकती तो क्लाइंट कैसे व्यवहार करता है, क्योंकि कार्यान्वयन अलग होते हैं और प्रॉक्सी निर्णय पूरे डिवाइस का किल स्विच नहीं है। कुछ सीधे कनेक्शन पर लौट जाते हैं और अन्य बंद होकर विफल होते हैं, और यह अंतर बदल देता है कि कोई रुकावट टूटी प्रॉक्सी जैसी दिखे या चलती नीति जैसी। किसी घटना के दौरान उस पर भरोसा करने से पहले सटीक क्लाइंट और संस्करण के लिए व्यवहार की पुष्टि करें।