Apple VPN On Demand domen qaydaları tuneli necə açır
Domen qaydası yalnız tunelin nə vaxt açılacağını müəyyən edir. connect-if-needed DNS yoxlaması necə işləyir, marşrutların niyə trafiki hələ də seçdiyi və profili necə sınamaq olar.
Tunel bir daxili adı tələb etdiyiniz zaman açılır və növbəti tətbiq ona eyni dərəcədə ehtiyac duyanda bağlı qalır. Bu, tətbiqdə xəta deyil; domen qaydasının formasıdır. Apple-ın on-demand konfiqurasiyası bağlantı yaratmaq üçün şərtləri təsvir edir və bu şərtlərin domen forması hələ bir paket yerindən tərpənməmiş sistem resolverinə sual verir. İki sual daim qarışdırılır: tunelin nə vaxt qalxmalı olduğu və mövcud olduqdan sonra nə daşıdığı. Birincisi tetikdir, ikincisi marşrut və resolver siyasətidir və bir profil adətən hər ikisini eyni yükləmədə qurur, buna görə düzgün domen qaydası sizi yenə də yanlış şəbəkədə qoya bilər.
Tetik və trafik seçimi müxtəlif qatlarında yerləşir
On-demand qaydası VPN yükləməsinin on-demand lüğətində yaşayır: hər biri bir əməliyyat və uyğunluq şərtləri dəsti olan sıralı qaydalar siyahısı. Sistem onları bağlantı dəyişdikdə və ya nəsə şəbəkəyə çatmağa çalışdıqda qiymətləndirir və əməliyyat tunelin qaldırılması, qiymətləndirilməsi, kəsilməsi və ya nəzərə alınmaması barədə qərar verir. Bütün bunlar platformanın şəbəkə qatında, tətbiqinizin soketi olmadan əvvəl baş verir.
Bundan sonra baş verənlər ayrı açar qrupudur: tunelin IPv4 və IPv6 parametrləri, daxil edilmiş və xaric edilmiş marşrutları, DNS server ünvanları və iOS ilə iPadOS-da hansı tətbiqlərin tuneldən ümumiyyətlə istifadə edə biləcəyini müəyyən edən tətbiq üzrə xəritələmə. Profil geniş tetiki dar marşrutla və ya dar tetiki standart marşrutla birləşdirə bilər. Yalnız bir yarısını oxuyun və digər yarısı nasazlıq kimi görünəcək.
Daxili domen altında nəsə tələb olunduqda qoşulan, lakin tunelə yalnız bir /16 yönləndirən laboratoriya profilim var. Yükləməsinin dediyini dəqiq edir və eyni zamanda ticket yaradan profil növüdür: insanlar qoşulmuş tunelin trafiklərinin içində olduğunu fərz edirlər.
Domen qaydası resolverdən əslində nə soruşur
Qaydanın tez-tez connect-if-needed adlanan domen forması paket yükləmələrini yoxlamır və URL-lərə baxmır. Ad həll edildikdə sistem onu qaydadakı domenlərlə müqayisə edir və uyğunluq olduqda həmin adın tunelin təqdim etdiyi DNS serverləri vasitəsilə həll oluna bilib-bilmədiyini soruşur. Tunelin resolveri cavab verirsə, ad daxili sayılır və bağlantı başladılır. Əvəzində lokal resolver cavab verirsə, ad xarici sayılır və tunel görünmür. Apple-ın yerləşdirmə icmalı bunları şəbəkə aşkarlanması və ardınca bağlantı qiymətləndirilməsi kimi təsvir edir.
İki nəticə çıxır. Profil tunelin içində DNS serverləri göstərməlidir; tunel resolveri olmayan domen qaydasının müqayisə edəcəyi bir şey yoxdur, ona görə qiymətləndirmə gözlədiyiniz uyğunluğu verə bilməz. Və axtarış sistem resolverinə çatmalıdır. Öz şifrələnmiş DNS-ini işlədən tətbiq və ya brauzer, yerli cavab verən uzantı və ya hərfi ünvana bağlantı qaydanın gözlədiyi ad həllini heç vaxt yaratmır. Keçirdiyim ən uzun günortadan biri tunelin qarşısındakı klientin DNS over HTTPS istifadə etdiyini kəşf edəndə bitdi.
Keş tetiki də aradan qaldırır. Artıq keşdə olan ada tuneli başladacaq yoxlama olmadan cavab verilə bilər, buna görə dünən işləyən qayda yenidən başlatmadan sonra və ya tunel bir müddət açıq qaldıqdan sonra uğursuz olur. macOS-da sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder vəziyyəti sıfırlayır; iOS-da təyyarə rejimini yandırıb-söndürmək və ya cihazı yenidən başlatmaq oxşar təmiz vəziyyət verir.
Uyğunluq əhatəsi: adlar, tətbiqlər və şəbəkələr
Domen uyğunluğu bir neçə növdən biridir. Qayda həmçinin interfeys növünə (Wi-Fi, mobil, Ethernet) və konkret SSID-yə uyğunlaşa bilər, tətbiq üzrə və ya Safari-domen girişləri tuneli bir iş axınına bağlayır. Bu bağlama yalnız bir tətbiqin digərlərindən fərqli davrandığı qəribə təcrübəni izah edir: digər tətbiqlər tunelin əhatəsindən kənardadır, ona görə tunel ikonu qoşulduğunu söyləyərkən belə lokal yoldan istifadə etməyə davam edirlər.
Sıra insanların gözlədiyindən daha önəmlidir. Qaydalar ardıcıl qiymətləndirilir və ilk uyğun gələn əməliyyatı verir, buna görə dar domen qaydasının üstündə yerləşən geniş hər-hansı-Wi-Fi-da-qoşul qaydası səssizcə qalib gələcək və domen qaydasını sınanmaz edəcək. Domen siyahısını yenidən yazmazdan əvvəl heç bir əvvəlki qaydanın artıq uyğunlaşmadığını təsdiqləyin.
Bu həm də always-on-un sadəcə daha sərt on-demand qaydası olmadığının səbəbidir. Always-on tətbiqi ayrı yerləşdirmə rejimidir və öz nəzarət və idarəetmə tələblərinə malikdir; ada reaksiya vermək əvəzinə tuneli açıq saxlayır. Əgər sizə heç vaxt düşməyən tunel lazımdırsa, domen qaydası yanlış alətdir.
Qırıq qaydanı təqlid edən nasazlıq növləri
Domen qaydasının işləmədiyi barədə hesabatların çoxu beş yerdən birinə düşür və yalnız sonuncusu qayda mətnidir.
| 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 portallar ayrı sətirə layiqdir, çünki otel və hava limanı Wi-Fi-ları qaydanın asılı olduğu axtarışın özünü tutur. Portal cihazı qəbul edənə qədər tunelin DNS serveri əlçatmaz olur, yoxlama uğursuz olur və nasazlıq səhv yazılmış domen kimi görünür. Autentifikasiya digər səssiz haldır: qayda işə düşə bilər, tunel qoşulmağa başlaya bilər və bağlantı vaxtı keçmiş sertifikat və ya başqa ekranda görünən sorğu üzündən ölür.
IPv6 səhv diaqnoz qoyulması asan olan bir variant yaradır. Hər iki ünvan ailəsi olan ada əvvəlcə AAAA qeydindən cavab verilə bilər, halbuki tunelin marşrut siyahısı yalnız IPv4 daşıyır. Bir brauzer uğur qazanır, digəri uğursuz olur və domen siyahısı tamamilə günahsızdır.
Real sorğu ilə, bu ardıcıllıqla sınayın
Siyasəti təxmin etməzdən əvvəl oxuyun. macOS-da sudo profiles show -type configuration VPN yükləməsi daxil olmaqla quraşdırılmış profilləri çap edir, scutil --nc list xidmət vəziyyətini göstərir və scutil --nc show <service> sistemin istifadə etdiyi on-demand lüğətini çap edir. İdarə olunan iPhone və ya iPad-də eyni yükləmə idarəetmə konsolundan və ya MDM hesabatından gəlir. Şəbəkə jurnalları macOS-da log stream --predicate 'subsystem == "com.apple.networkextension"' ilə, telefon qoşulduqda isə cihaz konsolu vasitəsilə mövcuddur.
Sonra sessiyada əvvəl sorğulanmamış host adı ilə sınayın. Tunelin DNS zonasında daxildə həll olunduğunu bildiyiniz bir ad seçin, bir dəfə tələb edin və tunelin görünüb-görünmədiyini izləyin. Eyni axtarışı iki dəfə aparın: ikinci cəhd keş yolunu işlədir və ikisi arasındakı fərq tetikin həll, yoxsa marşrutlaşdırma olduğunu söyləyir.
Tunel qalxdıqdan sonra iki qatı ayrıca yoxlayın. netstat -rn -f inet və netstat -rn -f inet6 hər prefiksin hara yönəldiyini göstərir, scutil --dns resolver sırasını və hər resolverin hansı interfeysə aid olduğunu göstərir, nettop -m route isə baytları hansı interfeysin daşıdığını göstərir. Tunel açıqdırsa və resolver düzgündürsə, lakin resurs hələ də uğursuz olursa, qaydanı redaktə etməyi dayandırın; server tərəfli avtorizasiyanı və qayıdış marşrutunu yoxlayın.
Qayda başqasına aid olduqda
Əgər tunel kəsdikdən sonra yenidən görünürsə, qayda adətən tətbiqə deyil, profilə aiddir: MDM ilə göndərilmiş konfiqurasiya, qalmış şəxsi profil və ya başqa klient tərəfindən quraşdırılmış profil. sudo profiles show -type configuration və on-demand açarları üzrə axtarış bunu daraldacaq və silinmə yolu profildir, menyu çubuğundakı açar deyil. Xidmət girişini və ya tətbiqi silmək qaydanı geridə qoyur və növbəti quraşdırma onu yenidən miras alır.
Bir sınaq sahibliyi həll edir: bağlantını kəsin, gözləyin, daxili adı yenidən tələb edin. Tunel qayıdırsa, tetik dizayn edildiyi kimi işləyir və açıq sual onu kimin idarə etdiyi və bu əhatənin istədiyiniz olub-olmadığıdır.
Bunu xəta kimi qeyd etməzdən əvvəl eyni beş yoxlamadan keçin: yükləmədə tunel resolver ünvanları var, ad keşlənməyib, əvvəlki heç bir qayda uyğunlaşmayıb, marşrut siyahısı AAAA yolunu əhatə edir və tətbiq tunelin əhatəsindədir. Beşi də doğru olduqda qayda öz işini görür və qüsur yolun daha irəlisindədir.