Apple VPN On Demand के डोमेन नियम टनल कैसे शुरू करते हैं
डोमेन नियम सिर्फ़ तय करता है कि टनल कब खुलेगा। connect-if-needed DNS प्रोब कैसे काम करता है, रूट अब भी ट्रैफ़िक क्यों चुनते हैं और प्रोफ़ाइल कैसे जाँचें।
टनल तब खुलता है जब आप एक आंतरिक नाम का अनुरोध करते हैं और बंद रहता है जब अगली ऐप को उसकी उतनी ही ज़रूरत होती है। यह ऐप में बग नहीं है; यह डोमेन नियम का आकार है। Apple का on-demand कॉन्फ़िगरेशन कनेक्शन बनाने की शर्तें बताता है, और उन शर्तों का डोमेन रूप एक भी पैकेट हिलने से पहले सिस्टम रिज़ॉल्वर से एक सवाल पूछता है। दो सवाल लगातार आपस में मिल जाते हैं: टनल कब ऊपर आना चाहिए, और टनल बनने के बाद क्या ढोता है। पहला ट्रिगर है, दूसरा रूट और रिज़ॉल्वर नीति है, और एक प्रोफ़ाइल आमतौर पर दोनों एक ही payload में सेट करती है, इसलिए सही डोमेन नियम भी आपको गलत नेटवर्क पर छोड़ सकता है।
ट्रिगर और ट्रैफ़िक चयन अलग-अलग परतों में हैं
on-demand नियम VPN payload के on-demand शब्दकोश में रहता है: नियमों की क्रमबद्ध सूची, हर एक में एक क्रिया और मिलान शर्तों का समूह। सिस्टम उनका मूल्यांकन तब करता है जब कनेक्टिविटी बदलती है या जब कुछ नेटवर्क तक पहुँचने की कोशिश करता है, और क्रिया तय करती है कि टनल ऊपर उठाया जाए, मूल्यांकित किया जाए, डिस्कनेक्ट किया जाए या अनदेखा किया जाए। यह सब प्लेटफ़ॉर्म की नेटवर्किंग परत में होता है, इससे पहले कि आपकी ऐप को सॉकेट मिले।
इसके बाद जो होता है वह कुंजियों का अलग समूह है: टनल की IPv4 और IPv6 सेटिंग्स, उसके शामिल और बहिष्कृत रूट, उसके DNS सर्वर पते, और iOS तथा iPadOS पर प्रति-ऐप मैपिंग जो तय करती है कि कौन-सी ऐप टनल का उपयोग कर सकती हैं। एक प्रोफ़ाइल चौड़े ट्रिगर को संकीर्ण रूट के साथ जोड़ सकती है, या संकीर्ण ट्रिगर को डिफ़ॉल्ट रूट के साथ। सिर्फ़ आधा पढ़ें और दूसरा आधा खराबी जैसा दिखेगा।
मेरे पास एक लैब प्रोफ़ाइल है जो आंतरिक डोमेन के नीचे कुछ भी माँगे जाने पर जुड़ जाती है, लेकिन टनल में सिर्फ़ एक /16 रूट करती है। यह ठीक वही करती है जो उसका payload कहता है, और यह उस तरह की प्रोफ़ाइल भी है जो टिकट पैदा करती है: लोग मान लेते हैं कि जुड़ा हुआ टनल मतलब उनका ट्रैफ़िक उसके अंदर है।
डोमेन नियम रिज़ॉल्वर से असल में क्या पूछता है
नियम का डोमेन रूप, जिसे अक्सर connect-if-needed कहा जाता है, पैकेट payload की जाँच नहीं करता और URL नहीं देखता। जब कोई नाम हल होता है, सिस्टम उसे नियम के डोमेन से तुलना करता है और मिलान पर पूछता है कि क्या वह नाम टनल द्वारा दिए गए DNS सर्वरों से हल हो सकता है। अगर टनल का रिज़ॉल्वर जवाब देता है, नाम आंतरिक गिना जाता है और कनेक्शन शुरू होता है। अगर स्थानीय रिज़ॉल्वर जवाब देता है, नाम बाहरी माना जाता है और कोई टनल नहीं दिखता। Apple का डिप्लॉयमेंट अवलोकन इसे नेटवर्क पहचान और फिर कनेक्शन मूल्यांकन बताता है।
इससे दो परिणाम निकलते हैं। प्रोफ़ाइल को टनल के अंदर DNS सर्वर बताने होंगे; टनल रिज़ॉल्वर के बिना डोमेन नियम के पास तुलना करने को कुछ नहीं होता, इसलिए मूल्यांकन वह मिलान नहीं दे सकता जिसकी आप उम्मीद करते हैं। और लुकअप को सिस्टम रिज़ॉल्वर तक पहुँचना चाहिए। जो ऐप या ब्राउज़र अपना एन्क्रिप्टेड DNS चलाता है, जो एक्सटेंशन स्थानीय रूप से जवाब देता है, या शाब्दिक पते से कनेक्शन — ये कभी वह नाम रिज़ॉल्यूशन नहीं बनाते जिसका नियम इंतज़ार कर रहा था। मेरी सबसे लंबी दोपहरों में से एक तब खत्म हुई जब मुझे पता चला कि टनल के सामने वाला क्लाइंट DNS over HTTPS इस्तेमाल कर रहा था।
कैशिंग भी ट्रिगर को हटा देती है। कैश में पहले से मौजूद नाम का जवाब उस प्रोब के बिना दिया जा सकता है जो टनल शुरू करता, इसलिए कल काम करने वाला नियम रीबूट के बाद, या टनल के कुछ समय ऊपर रहने के बाद विफल हो जाता है। macOS पर sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder स्थिति रीसेट करता है; iOS पर एयरप्लेन मोड चालू-बंद करना या डिवाइस रीस्टार्ट करना आपको तुलनीय साफ़ शुरुआत देता है।
मिलान का दायरा: नाम, ऐप और नेटवर्क
डोमेन मिलान कई प्रकारों में से एक है। एक नियम इंटरफ़ेस प्रकार (Wi-Fi, सेलुलर, Ethernet) और विशिष्ट SSID से भी मिल सकता है, और प्रति-ऐप या Safari-डोमेन प्रविष्टियाँ टनल को एक कार्यप्रवाह से बाँधती हैं। यही बंधन उस अजीब अनुभव को समझाता है जिसमें सिर्फ़ एक ऐप बाकी सबसे अलग व्यवहार करती है: बाकी ऐप टनल के दायरे से बाहर हैं, इसलिए वे स्थानीय रास्ता इस्तेमाल करती रहती हैं, भले ही टनल आइकन जुड़ा हुआ कहे।
क्रम लोगों की अपेक्षा से ज़्यादा मायने रखता है। नियम क्रम से मूल्यांकित होते हैं और पहला मिलान क्रिया देता है, इसलिए संकीर्ण डोमेन नियम के ऊपर रखा चौड़ा किसी-भी-Wi-Fi-पर-जुड़ो नियम चुपचाप जीत जाएगा और डोमेन नियम को परखने लायक नहीं छोड़ेगा। डोमेन सूची फिर से लिखने से पहले पुष्टि करें कि कोई पहले का नियम पहले ही मिल चुका नहीं है।
इसीलिए always-on सिर्फ़ ज़्यादा सख़्त on-demand नियम नहीं है। always-on का प्रवर्तन एक अलग डिप्लॉयमेंट मोड है जिसकी अपनी पर्यवेक्षण और प्रबंधन आवश्यकताएँ हैं; यह नाम पर प्रतिक्रिया देने के बजाय टनल खुला रखता है। अगर आपको ऐसा टनल चाहिए जो कभी गिरे नहीं, तो डोमेन नियम गलत औज़ार है।
टूटे नियम जैसी विफलताएँ
डोमेन नियम काम नहीं करने की ज़्यादातर रिपोर्टें पाँच जगहों में से एक पर पहुँचती हैं, और उनमें से सिर्फ़ आखिरी नियम का पाठ है।
| What you see | Layer | First check |
|---|---|---|
| Tunnel comes up, internal site still fails | route or resolver after connect | netstat -rn, scutil --dns |
| Tunnel never comes up for that name | trigger path | fresh lookup, cache flush, private DNS |
| Tunnel comes up for every app | scope, or an earlier rule | rule order, per-app mapping |
| Tunnel drops and will not return on the same Wi-Fi | interface or SSID match, admission | captive portal, SSID string, auth prompt |
| Tunnel returns after you disconnect it | profile ownership | profiles show |
कैप्टिव पोर्टल अपनी अलग पंक्ति के हक़दार हैं, क्योंकि होटल और हवाई अड्डे का Wi-Fi ठीक उसी लुकअप को रोकता है जिस पर नियम निर्भर है। जब तक पोर्टल डिवाइस को अंदर नहीं आने देता, टनल का DNS सर्वर पहुँच से बाहर रहता है, प्रोब विफल होता है, और विफलता गलत लिखे डोमेन जैसी दिखती है। प्रमाणीकरण दूसरा ख़ामोश मामला है: नियम चल सकता है, टनल जुड़ना शुरू कर सकता है, और कनेक्शन समाप्त प्रमाणपत्र पर या दूसरी डिस्प्ले पर आने वाले प्रॉम्प्ट पर मर जाता है।
IPv6 एक ऐसा रूप बनाता है जिसका गलत निदान आसान है। दोनों पता परिवारों वाले नाम का जवाब पहले AAAA रिकॉर्ड से दिया जा सकता है, जबकि टनल की रूट सूची में सिर्फ़ IPv4 है। एक ब्राउज़र सफल होता है, दूसरा विफल, और डोमेन सूची पूरी तरह निर्दोष है।
असली अनुरोध से, इस क्रम में परीक्षण करें
अनुमान लगाने से पहले नीति पढ़ें। macOS पर sudo profiles show -type configuration VPN payload सहित इंस्टॉल की गई प्रोफ़ाइल छापता है, scutil --nc list सेवा की स्थिति दिखाता है, और scutil --nc show <service> वह on-demand शब्दकोश छापता है जो सिस्टम इस्तेमाल कर रहा है। प्रबंधित iPhone या iPad पर वही payload प्रबंधन कंसोल या MDM रिपोर्ट से आता है। नेटवर्किंग लॉग macOS पर log stream --predicate 'subsystem == "com.apple.networkextension"' के साथ, और फ़ोन जुड़ा होने पर डिवाइस कंसोल के ज़रिए उपलब्ध हैं।
फिर ऐसे होस्टनाम से परीक्षण करें जो सत्र में पहले नहीं पूछा गया। टनल के DNS ज़ोन में ऐसा नाम चुनें जिसे आप जानते हैं कि आंतरिक रूप से हल होता है, एक बार माँगें, और देखें कि टनल दिखता है या नहीं। वही लुकअप दो बार चलाएँ: दूसरी कोशिश कैश रास्ते का इस्तेमाल करती है, और दोनों के बीच का अंतर आपको बताता है कि ट्रिगर रिज़ॉल्यूशन है या रूटिंग।
टनल ऊपर आने के बाद दोनों परतों को अलग-अलग सत्यापित करें। netstat -rn -f inet और netstat -rn -f inet6 दिखाते हैं कि हर प्रीफ़िक्स कहाँ इशारा करता है, scutil --dns रिज़ॉल्वरों का क्रम और यह दिखाता है कि कौन-सा इंटरफ़ेस किस रिज़ॉल्वर का मालिक है, और nettop -m route दिखाता है कि कौन-सा इंटरफ़ेस बाइट्स ले गया। अगर टनल ऊपर है और रिज़ॉल्वर सही है पर संसाधन अब भी विफल होता है, तो नियम संपादित करना बंद करें; सर्वर-साइड प्राधिकरण और वापसी रूट जाँचें।
जब नियम किसी और का हो
अगर डिस्कनेक्ट करने के बाद टनल फिर दिखे, तो नियम आमतौर पर ऐप का नहीं बल्कि प्रोफ़ाइल का होता है: MDM से भेजा गया कॉन्फ़िगरेशन, बचा हुआ व्यक्तिगत प्रोफ़ाइल, या किसी दूसरे क्लाइंट द्वारा इंस्टॉल की गई प्रोफ़ाइल। sudo profiles show -type configuration और on-demand कुंजियों की खोज इसे सीमित करेगी, और हटाने का रास्ता प्रोफ़ाइल है, मेनू बार का टॉगल नहीं। सेवा प्रविष्टि या ऐप हटाने से नियम पीछे रह जाता है, और अगली इंस्टॉलेशन उसे फिर विरासत में पाती है।
एक परीक्षण स्वामित्व तय करता है: डिस्कनेक्ट करें, प्रतीक्षा करें, फिर आंतरिक नाम माँगें। अगर टनल लौटता है, ट्रिगर डिज़ाइन के अनुसार काम कर रहा है और खुला सवाल यह है कि इसे कौन प्रबंधित करता है और क्या वही दायरा आप चाहते हैं।
इसे बग के रूप में दर्ज करने से पहले वही पाँच जाँचें करें: payload में टनल रिज़ॉल्वर पते मौजूद हैं, नाम कैश नहीं हुआ था, कोई पहला नियम पहले ही नहीं मिला, रूट सूची AAAA रास्ता ढकती है, और ऐप टनल के दायरे में है। जब पाँचों सही हों, नियम अपना काम कर रहा है और गड़बड़ी रास्ते में आगे है।