होस्ट के URL के साथ गेस्ट VM में PAC प्रॉक्सी क्यों विफल होता है

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

PAC URL एक स्क्रिप्ट है, प्रॉक्सी नहीं

फ़ाइल में एक फ़ंक्शन है जो एक URL और एक होस्ट लेता है और प्रॉक्सी का विवरण या DIRECT शब्द लौटाता है। URL में कुछ भी एप्लिकेशन को नहीं बताता कि ट्रैफ़िक कहाँ भेजना है; वह निर्णय रनटाइम पर, स्क्रिप्ट के भीतर, उस डेटा के साथ लिया जाता है जो स्क्रिप्ट प्लेटफ़ॉर्म से माँगती है। PAC URL स्वीकार करने वाला सेटिंग्स संवाद एक निर्णय प्रक्रिया की ओर संकेतक स्वीकार कर रहा होता है।

यही अंतर कारण है कि URL की नकल करना काम कर गया जैसा लग सकता है। फ़ील्ड भर जाता है, सेटिंग सहेजी जाती है, और विफलता तभी बाद में दिखती है, जब स्क्रिप्ट नहीं लाई जा सकती या जब वह ऐसी प्रॉक्सी लौटाती है जहाँ गेस्ट नहीं पहुँच सकता।

चारों चरण अलग-अलग तरह से विफल होते हैं

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

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

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

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

वही स्क्रिप्ट VM के भीतर अलग तरह से तय करती है

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

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

यह निष्कर्ष न निकालें कि गेस्ट ने होस्ट की प्रॉक्सी सेटिंग्स विरासत में ली हैं क्योंकि उसका ट्रैफ़िक होस्ट-पक्ष अनुवाद से गुज़रता है। नेटवर्क अनुवाद पैकेट आगे भेजता है; वह एप्लिकेशन कॉन्फ़िगरेशन की नकल नहीं करता, और सिस्टम प्रॉक्सी एप्लिकेशन कॉन्फ़िगरेशन है।

वे उपकरण जो PAC बिलकुल नहीं पढ़ते

कमांड-लाइन उपकरण अलग सीमा हैं, और यहीं बहुत समय बर्बाद होता है। curl PAC फ़ाइलें निष्पादित नहीं करता, जैसा कि उसका प्रॉक्सी दस्तावेज़ स्पष्ट कहता है। प्रॉक्सी चर को PAC डाउनलोड URL की ओर इंगित करना स्क्रिप्ट को प्रॉक्सी एंडपॉइंट नहीं बनाता; उपकरण JavaScript फ़ाइल से HTTP बोलने की कोशिश करेगा और ऐसे विफल होगा जो नेटवर्क समस्या जैसा दिखता है।

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

Linux पर डेस्कटॉप एप्लिकेशन के लिए, सिस्टम सेटिंग को स्वचालित मोड में रखना होगा और उसे URL भी देना होगा; जब मोड अभी मैनुअल हो तब सहेजा गया URL कुछ नहीं करता। दोनों जाँचें, और उन्हें गेस्ट के भीतर जाँचें:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT भी एक निर्णय है

PAC परिणाम DIRECT का मतलब है कि एप्लिकेशन HTTP प्रॉक्सी को बायपास करता है, यह नहीं कि वह नेटवर्क से बच निकला है। परिणामी कनेक्शन अब भी टनल से गुज़रते हुए ऑपरेटिंग सिस्टम के मार्ग का अनुसरण कर सकता है, या ऐसे कारणों से विफल हो सकता है जिनका प्रॉक्सी के उपयोग से कोई संबंध नहीं है। इसके विपरीत, प्रॉक्सी परिणाम एक एप्लिकेशन के अनुरोध का वर्णन करता है, गेस्ट की हर प्रक्रिया का नहीं।

इसलिए उसी दिशा में सत्यापित करें जिसमें आवश्यकता लिखी गई थी। यदि आवश्यकता है «यह एप्लिकेशन आंतरिक साइट तक पहुँचता है», तो सिद्ध करें कि वह एप्लिकेशन पहुँचता है, और लिखें कि कौन सी प्रॉक्सी या मार्ग उसे ले गया। यदि आवश्यकता है «VM कॉर्पोरेट नेटवर्क पर है», तो चुनी गई प्रॉक्सी के ज़रिए चलने वाला ब्राउज़र उस ब्राउज़र के लिए प्रमाण है और इससे ज़्यादा कुछ नहीं।

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