होस्टच्या 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 कॉर्पोरेट नेटवर्कवर आहे» असेल, तर निवडलेल्या प्रॉक्सीद्वारे चालणारा ब्राउझर त्या ब्राउझरसाठी पुरावा आहे आणि त्यापेक्षा जास्त काही नाही.

चाचणी उत्तीर्ण व्हावी म्हणून होस्टचा टनेल बंद करण्याऐवजी किंवा फॉरवर्डिंग धोरण सैल करण्याऐवजी गेस्टच्या आत साखळी दुरुस्त करा. साखळीत चार दुवे आहेत आणि त्यातील एक वगळणारा बदल पुढच्या वेळी स्क्रिप्ट अद्ययावत होईपर्यंत किंवा गेस्टचा पत्ता बदलेपर्यंत टिकेल.