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 |
Captive පෝටල් තමන්ගේම පේළියකට සුදුසුය, මන්ද හෝටල් සහ ගුවන්තොටුපළ 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 මාර්ගය ආවරණය කරයි, සහ යෙදුම ටනලයේ විෂය පථය තුළ ඇත. පහම සත්‍ය නම් නීතිය තම කාර්යය කරයි, දෝෂය මාර්ගයේ තවත් ඉදිරියෙන් ඇත.