macOS का सेवा क्रम आपके VPN रूट को नियंत्रित नहीं करता

किसी वेबसाइट पर कुछ विफल होता है, सहकर्मी को याद आता है कि सेवा क्रम मौजूद है, और Wi-Fi को Ethernet के ऊपर खींच दिया जाता है। कुछ नहीं बदलता, क्योंकि उस सूची ने कभी तय नहीं किया कि VPN का गंतव्य कहाँ जाता है। Apple VPN कनेक्शन को सामान्य से प्राथमिकता देता है और उन्हें इस पुनर्व्यवस्था से बाहर रखता है, इसलिए वह स्विच पूछे गए प्रश्न से अधिक संकीर्ण प्रश्न का उत्तर देता है। विफलता को चुने गए रूट और resolver की ज़रूरत है, नई रैंकिंग की नहीं।

सेवा क्रम क्या बदलता है, और क्या कभी नहीं छूता

«सेवा क्रम सेट करें» सिस्टम सेटिंग्स, नेटवर्क में, Action मेनू के अंतर्गत है, और जब दो या अधिक सक्रिय हों तो यह सामान्य कनेक्शन की रैंकिंग करता है। वह रैंकिंग प्राथमिक सेवा चुनती है, जो डिफ़ॉल्ट रूट और resolver के व्यवहार का हिस्सा देती है। यह समकक्षों के बीच का निर्णायक मत है, टनल के पीछे के निजी गंतव्यों के लिए स्विच नहीं। Wi-Fi और USB Ethernet एडाप्टर वाला लैपटॉप इसका उपयोग एक समझदार प्रश्न का उत्तर देने के लिए करता है, और वह प्रश्न टनल के बारे में नहीं है।

VPN प्रोफ़ाइल शामिल रूट, बहिष्कृत गंतव्य और कभी-कभी प्रति-ऐप नियम रखती है, और ये तय करते हैं कि टनल में क्या जाता है; क्रम मेनू उन्हें संपादित नहीं करता। इसीलिए स्प्लिट-टनल प्रोफ़ाइल सार्वजनिक ट्रैफ़िक को बाहर छोड़ सकती है जबकि VPN अब भी हर भौतिक इंटरफ़ेस से ऊपर है। Wi-Fi को सबसे ऊपर खींचने से कोई निजी रेंज पहुँच योग्य नहीं होती, और यह उस गंतव्य को नहीं रोक सकता जिसे प्रोफ़ाइल पहले से शामिल करती है। सूची इंटरफ़ेस हिलाती है; प्रोफ़ाइल प्रीफ़िक्स हिलाती है। Apple इस प्राथमिकता को अपने नेटवर्क सेवा क्रम पृष्ठ पर प्रलेखित करता है, जिसे कुछ भी पुनर्व्यवस्थित करने से पहले एक बार पढ़ना उचित है।

वह रूट पढ़ें जो मशीन ने वास्तव में चुना

किसी विशिष्ट पते का गंतव्य route get 10.20.4.10 से मशीन से पूछें, फिर IPv6 के लिए इसे route -n get -inet6 2001:db8::10 से दोहराएँ। दोनों परिवार अलग-अलग निर्णय हैं, इसलिए काम करने वाला IPv4 रूट v6 के बारे में कुछ नहीं कहता, और सीधे जुड़ा सबनेट या अधिक विशिष्ट प्रीफ़िक्स किसी भी हाल में सामान्य कनेक्शन लेबल को हरा देता है, यही कारण है कि वह लेबल लोगों को भ्रमित करता रहता है।

अगर आउटपुट टनल इंटरफ़ेस का नाम लेता है, तो प्रोफ़ाइल ने गंतव्य पकड़ लिया और क्रम अप्रासंगिक है। अगर यह भौतिक इंटरफ़ेस का नाम लेता है, तो प्रोफ़ाइल ने ऐसा नहीं किया, और कोई भी खींचना प्रीफ़िक्स तालिका नहीं बदलेगा। दोनों आउटपुट उस स्रोत पते का नाम भी लेते हैं जो मशीन उपयोग करेगी, और दो रन की तुलना करते समय यही वह फ़ील्ड है जिसे उद्धृत करना चाहिए। कुछ भी बदलने से पहले आउटपुट सहेजें, क्योंकि बाद में यही एकमात्र साक्ष्य होगा।

DNS नाम से हल करता है, इंटरफ़ेस से नहीं

स्कोपित और डोमेन-विशिष्ट resolver का अर्थ है कि उत्तर इंटरफ़ेस के बजाय नाम के अनुसार भिन्न हो सकता है। scutil --dns वह resolver कॉन्फ़िगरेशन छापता है जो सिस्टम वास्तव में उपयोग कर रहा है, स्कोपित प्रविष्टियों सहित। सेवा क्रम प्रभावित करता है कि कौन-सी सेवा डिफ़ॉल्ट resolver देती है, पर नाम-विशिष्ट स्कोप फिर भी जीत सकता है।

इसलिए किसी पते पर ping काम कर सकता है जबकि होस्टनाम विफल हो, या इसका उलटा। दोषी चुनने से पहले दोनों आउटपुट पढ़ें।

प्रोफ़ाइल बदलें, फिर दोनों आउटपुट दोबारा पढ़ें

जब किसी गंतव्य नीति को बदलना हो, तो मालिक VPN प्रोफ़ाइल है: शामिल रूट, बहिष्कृत रूट और वे स्प्लिट-टनल नियम जिन्हें विक्रेता समर्थित करता है। इसके बजाय इंटरफ़ेस बदलना सिर्फ़ बहस को हिलाता है। दूर से प्रबंधित Mac पर, पहले मौजूदा नेटवर्क स्थिति सहेजें, क्योंकि ऐसी मशीन पर टनल खोना जिस तक आप पहुँच नहीं सकते, यात्रा है, वापसी नहीं।

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