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, अयशस्वी होणाऱ्या होस्टसाठीचा मूल्यांकन निकाल आणि त्रुटी दिसलेला टप्पा पाठवा। या चारांमुळे पुढील व्यक्तीला कोणता स्तर गुंतलेला होता याचा अंदाज न घेता निर्णय पुन्हा तयार करता येतो। चाचणीच्या क्षणीची बोगद्याची स्थिती जोडा, कारण पुन्हा जोडण्यापूर्वी घेतलेला निकाल जुना असतो। स्क्रिप्टची आवृत्तीही ठेवा, कारण धोरण फाइल पूर्वसूचनेशिवाय बदलते आणि कालचे उत्तर आता वैध नसेल।

स्क्रिप्ट आणता येत नाही तेव्हा क्लायंट कसा वागतो ते नोंदवा, कारण अंमलबजावणी वेगळ्या असतात आणि प्रॉक्सीचा निर्णय संपूर्ण उपकरणाचा किल स्विच नाही। काही थेट कनेक्शनकडे परत जातात आणि इतर बंद होऊन अयशस्वी होतात, आणि हा फरक बिघाड मोडलेल्या प्रॉक्सीसारखा दिसतो की चालू धोरणासारखा हे बदलतो। घटनेदरम्यान त्यावर अवलंबून राहण्यापूर्वी नेमक्या क्लायंट आणि आवृत्तीसाठी वर्तनाची पुष्टी करा।