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, असफल हुने होस्टको मूल्याङ्कन नतिजा र त्रुटि देखिएको चरण पठाउनुहोस्। यी चारले अर्को व्यक्तिलाई कुन तह संलग्न थियो भनी अनुमान गर्नुको सट्टा निर्णय पुनः उत्पादन गर्न दिन्छ। परीक्षणको क्षणमा टनेलको अवस्था थप्नुहोस्, किनकि पुनः जडानअघि लिइएको नतिजा पुरानो हुन्छ। स्क्रिप्टको संस्करण पनि राख्नुहोस्, किनकि नीति फाइल सूचना बिना बदलिन्छ र हिजोको उत्तर अब मान्य नहुन सक्छ।

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