Apple VPN On Demand இன் டொமைன் விதிகள் ஒரு சுரங்கப்பாதையை எவ்வாறு தொடங்குகின்றன
ஒரு டொமைன் விதி சுரங்கப்பாதை எப்போது திறக்கப்படுகிறது என்பதை மட்டுமே தீர்மானிக்கிறது. connect-if-needed DNS ஆய்வு எவ்வாறு செயல்படுகிறது, வழிகள் ஏன் இன்னும் போக்குவரத்தைத் தேர்ந்தெடுக்கின்றன மற்றும் சுயவிவரத்தை எவ்வாறு சோதிப்பது.
நீங்கள் ஒரு உள் பெயரைக் கோரும் போது சுரங்கப்பாதை திறக்கிறது, அடுத்த செயலி அதே அளவு தேவைப்படும் போது மூடியே இருக்கிறது. இது செயலியின் பிழை அல்ல; இது ஒரு டொமைன் விதியின் வடிவம். Apple இன் on-demand உள்ளமைவு இணைப்பை உருவாக்குவதற்கான நிபந்தனைகளை விவரிக்கிறது, அந்த நிபந்தனைகளின் டொமைன் வடிவம் ஒரு பாக்கெட் கூட நகரும் முன் கணினி தீர்வியிடம் ஒரு கேள்வியைக் கேட்கிறது. இரண்டு கேள்விகள் தொடர்ந்து கலக்கப்படுகின்றன: சுரங்கப்பாதை எப்போது மேலே வர வேண்டும், மற்றும் சுரங்கப்பாதை இருக்கும் போது என்ன எடுத்துச் செல்கிறது. முதலாவது தூண்டி, இரண்டாவது வழி மற்றும் தீர்வி கொள்கை, ஒரு சுயவிவரம் பொதுவாக இரண்டையும் ஒரே payload இல் அமைக்கிறது, எனவே சரியான டொமைன் விதியும் உங்களை தவறான நெட்வொர்க்கில் விட்டுவிடலாம்.
தூண்டி மற்றும் போக்குவரத்து தேர்வு வெவ்வேறு அடுக்குகளில் உள்ளன
on-demand விதி VPN payload இன் on-demand அகராதியில் வாழ்கிறது: வரிசைப்படுத்தப்பட்ட விதிகளின் பட்டியல், ஒவ்வொன்றும் ஒரு செயல் மற்றும் பொருந்தும் நிபந்தனைகளின் தொகுப்புடன். இணைப்பு மாறும்போது அல்லது ஏதாவது நெட்வொர்க்கை அடைய முயற்சிக்கும்போது கணினி அவற்றை மதிப்பிடுகிறது, செயல் சுரங்கப்பாதையை உயர்த்த வேண்டுமா, மதிப்பிட வேண்டுமா, துண்டிக்க வேண்டுமா அல்லது புறக்கணிக்க வேண்டுமா என்பதைத் தீர்மானிக்கிறது. இவை அனைத்தும் செயலிக்கு socket கிடைப்பதற்கு முன் தளத்தின் நெட்வொர்க் அடுக்கில் நடக்கின்றன.
அடுத்து வருவது தனி விசைக் குழு: சுரங்கப்பாதையின் 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 பாதையை உள்ளடக்குகிறது, செயலி சுரங்கப்பாதையின் எல்லைக்குள் உள்ளது. ஐந்தும் சரியாக இருந்தால் விதி தன் வேலையைச் செய்கிறது, பிழை பாதையில் மேலும் முன்னே உள்ளது.