Apple VPN On Demand домен ережелері туннельді қалай іске қосады

Туннель бір ішкі атауды сұраған кезде ашылады және келесі қолданбаға ол дәл сондай қажет болғанда жабық қалады. Бұл қолданбадағы қате емес; бұл домен ережесінің пішімі. 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-ды орындау — жеке орналастыру режимі, оның өз қадағалау және басқару талаптары бар; ол атауға әрекет етудің орнына туннельді ашық ұстайды. Егер сізге ешқашан құламайтын туннель керек болса, домен ережесі қате құрал.

Сынған ережеге ұқсайтын ақаулар

Домен ережесі жұмыс істемейді деген хабарламалардың көбі бес орынның біріне түседі, және олардың тек соңғысы ғана ереже мәтіні.

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 жолын қамтиды және қолданба туннель ауқымында. Бесеуі де дұрыс болса, ереже өз жұмысын істеп тұр, ал ақау жолдың әрі қарайғы бөлігінде.