Ինչպես են 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 հաշվետվությունից։ Ցանցային մատյանները հասանելի են log stream --predicate 'subsystem == "com.apple.networkextension"'-ով macOS-ում և սարքի վահանակի միջոցով, երբ հեռախոսը միացված է։
Այնուհետև փորձարկեք հոսթի անունով, որը նախկինում չի հարցվել այս նստաշրջանում։ Ընտրեք անուն թունելի DNS գոտում, որը գիտեք, որ լուծվում է ներքին, պահանջեք այն մեկ անգամ և հետևեք՝ արդյոք թունելը հայտնվում է։ Կատարեք նույն հարցումը երկու անգամ. երկրորդ փորձը վարժեցնում է պահոցի ուղին, և երկուսի տարբերությունը ձեզ ասում է՝ գործարկիչը լուծումն է, թե երթուղավորումը։
Երբ թունելը վերևում է, ստուգեք երկու շերտերն առանձին։ netstat -rn -f inet-ը և netstat -rn -f inet6-ը ցույց են տալիս, թե ուր է ուղղված յուրաքանչյուր նախածանց, scutil --dns-ը ցույց է տալիս լուծիչների հերթականությունը և թե որ ինտերֆեյսն է տիրում յուրաքանչյուր լուծիչին, իսկ nettop -m route-ը ցույց է տալիս, թե որ ինտերֆեյսն է կրել բայթերը։ Եթե թունելը վերևում է, լուծիչը՝ ճիշտ, բայց ռեսուրսը դեռ ձախողվում է, դադարեցրեք կանոնը խմբագրելը. ստուգեք սերվերի կողմի լիազորումը և վերադարձի երթուղին։
Երբ կանոնը պատկանում է ուրիշին
Եթե թունելը նորից հայտնվում է անջատելուց հետո, կանոնը սովորաբար պատկանում է պրոֆիլին, ոչ թե հավելվածին. MDM-ով ուղարկված կոնֆիգուրացիա, մնացած անձնական պրոֆիլ կամ այլ հաճախորդի տեղադրած պրոֆիլ։ sudo profiles show -type configuration-ը և on-demand բանալիների որոնումը կնեղացնեն այն, և հեռացման ուղին պրոֆիլն է, ոչ թե մենյուի գծի անջատիչը։ Ծառայության գրառումը կամ հավելվածը ջնջելը թողնում է կանոնը, և հաջորդ տեղադրումը նորից ժառանգում է այն։
Մեկ թեստը լուծում է սեփականության հարցը. անջատեք, սպասեք, նորից պահանջեք ներքին անունը։ Եթե թունելը վերադառնում է, գործարկիչը աշխատում է ինչպես նախատեսված է, և բաց հարցն այն է, թե ով է կառավարում այն և արդյոք այդ շրջանակն է, ինչ դուք ուզում եք։
Նախքան սա որպես սխալ գրանցելը, անցեք նույն հինգ ստուգումներով. թունելի լուծիչի հասցեները payload-ում առկա են, անունը պահոցում չի եղել, ոչ մի ավելի վաղ կանոն արդեն չի համապատասխանել, երթուղիների ցանկը ծածկում է AAAA ուղին, և հավելվածը թունելի շրջանակում է։ Երբ բոլոր հինգը ճիշտ են, կանոնն անում է իր գործը, և սխալը ուղու վրա ավելի հեռու է։