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 പാത്ത് ഉൾക്കൊള്ളുന്നു, ആപ്പ് ടണലിന്റെ വ്യാപ്തിയിലുണ്ട്. അഞ്ചും ശരിയാണെങ്കിൽ നിയമം അതിന്റെ ജോലി ചെയ്യുന്നു, തകരാർ പാത്തിയിൽ കൂടുതൽ മുന്നിലാണ്.