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 жолун камтыйт, жана колдонмо туннелдин камтылышында. Бешөө тең туура болсо, эреже өз ишин аткарып жатат, ал эми ката жолдун андан ары бөлүгүндө.