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