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 सर्व्हर नaming करणे आवश्यक आहे; टनेल रिझॉल्व्हर नसलेल्या डोमेन नियमाकडे तुलना करायला काहीच नाही, त्यामुळे मूल्यांकन तुम्ही अपेक्षित जुळणी देऊ शकत नाही. आणि शोध सिस्टम रिझॉल्व्हरपर्यंत पोहोचला पाहिजे. स्वतःचे एन्क्रिप्टेड 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 मार्ग व्यापते, आणि अॅप टनेलच्या व्याप्तीत आहे. पाचही बरोबर असतील तर नियम आपले काम करत आहे आणि दोष मार्गात पुढे आहे.