होस्टको 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 कर्पोरेट नेटवर्कमा छ» भए, छानिएको प्रोक्सीमार्फत चल्ने ब्राउजर त्यो ब्राउजरका लागि प्रमाण हो, त्यसभन्दा बढी होइन।

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