Հավելվածային VPN-ը կառավարվող iPhone հավելվածներում. ինչն է երթուղվում, ինչը՝ ոչ
Հավելվածային թունելը հետևում է կառավարվող հավելվածին, ոչ՝ հեռախոսին. Ստուգեք բեռնվածքի կապը, կառավարվող պատճենը, պահանջով գործարկման կանոնները և հավելվածից դուրս եկող հոսքերը։
iPhone-ում հավելվածային VPN-ը ամբողջ հեռախոսի անջատիչ չէ։ Այն կապ է մեկ կառավարվող հավելվածի և մեկ VPN բեռնվածքի միջև, որը ստեղծվում է հավելվածի տեղակայման պահին, իսկ մնացած ամեն ինչի թրաֆիկը պահպանում է նախկին ուղեցույթը։ Այդ պատճառով նույն հեռախոսը վարվում է անհետևողական: աշխատանքային հավելվածը բացում է մասնավոր էջ, մինչդեր Safari-ն չի հասնում նույն հոսթին, կամ թունելը ընդհանրապես չի բարձրանում, և հավելվածը հաղորդում է ժամկետի ավարտ, որը նման է վատ հավատարմագրերի։ Ստուգումները գնում են ամենադարձ պատճառից ներքև, ուստի կանգ առվեք առաջին ձախողվողի վրա։
Նախ ստուգեք բեռնվածքը և հավելվածի գրառումը
Կապը ապրում է երկու օբյեկտում, ոչ մեկում։ VPN բեռնվածքը սահմանում է թունելը՝ տեսակը, սերվերը, նույնականացումը, DNS-ը և մատակարարի փաթեթի նույնացուցիչը, երբ օգտագործվում է հատուկ հաճախորդ։ Հավելվածի գրառումը ցույց է տալիս այդ բեռնվածքին, և կառավարման կոնսոլների մեծ մասը դա առաջարկում է որպես հավելվածային տարբերակ հավելվածի կարգավորումներում՝ Per-App VPN-ին մոտ անունով։ Բեռնվածքը, որին ոչ մի հավելված չի ցույց տալիս, հավելվածային ոչինչ չի երթուղում. այն իրեն պահում է սովորական թունելի նման, որը ինչ-որ մեկը պետք է ձեռքով գործարկի։
Կարդացեք երկու օբյեկտները էլ նախքան հեռախոսին դիպչելու։ Համոզվեք, որ հավելվածի կարգավորումը հղում է ձեր փորձարկվող բեռնվածքին, ոչ դրա հին պատճենին, քանի տեղափոխումից հետո գրեթե նույնանուն կրկնորին բեռնվածքները սովորական են, և հավելվածը համոնում ցույց տալիս հեռացվածին։ Ապա համոզվեք, որ կարգավորումը հասել է սարքին. Կարգավորումներ, Ընդհանուր, VPN և սարքի կառավարում բաժինները պետք է այն ցուցադրեն որպես տեղադրված պրոֆիլ։ Այնտեղի VPN ցանկը փորձարկություն չէ։ Հավելվածային ծառայությունն սովորաբար ձերքի անջատիչ չունի, ուստի ճիշտ տեղադրված կարգավորումը կարող է երբեք չհայտնվի գործարկելի VPN-ների մեջ։ Բացակայությունը երևում է հավելվածի գրառումում և նրանում, թե արդյոք թունելը բարձրանում է հավելվածի առաջին հարցով։
Մեկ պայման բացատրում է շատ տոմսներ. այս մոդելը պահանջում է, որ հավելվածը գա կառավարման միջոցով։ Կողքից տեղադրված կամ անձամբ գնված պատճենը կապը չի ստանում, նույնիսկ երբ նրա փաթեթի նույնացուցը համընկնում է։ Apple-ի VPN տեղակայման ուղեցույցը նկարագրում է դրա հետևում ընկած բեռնվածքի մոդելը (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web)։
Համոզվեք, որ տեղադրված հավելվածը կառավարվող պատճենն է
Կապը հետևում է տեղադրված, կառավարվող հավելվածին։ Եթե ինչ-որ մեկը վերատեղադրել է այն App Store-ից անձնական Apple ID-ով, փոխարինել վերաստորագրված ձեռնարկային կառուցվածքով, կամ սարքը կրկին գրանցվել է, և հավելվածը վերադարձել է այլ հոսքով, թունելը կարող է մնալ ներքևում, մինչդեր հավելվածն ինքը բարձր նորմալ տեսք ունի։
Փորձարկեք համեմատությամբ, ոչ մեկ դիտարկմամբ։ Կառավարման ցանկում հավելվածը պետք է ցուցադրվի որպես կառավարվող այդ սարքի համար՝ VPN քարտեզագրումով իր գրառումում։ Հեռախոսում թունելը պետք է բարձրանա, երբ հավելվածը գործարկվում է և նրա առաջին հարցումը դուրս է գալիս, ոչ միայն այն ժամանակ, երբ ինչ-որ մեկը Կարգավորումներում առանձին ձեռքի կարգավորում է գործարկում։ Եթե հավելվածի գործարկումը ոչինչ չի փոխում, իսկ այդ ձեռքի կարգավորումը փոխում է, հավելվածն ընդհանրապես կապված չէ հավելվածային թունելին։
Թարմացումները կարևոր են. կառավարման միջոցով ուղարկվածը պահպանում է քարտեզագրումը, մինչդեր օգտագործողի սկսած վերատեղադրումը կարող է կորցնել այն։ Երբ բողոքը թվագրվում է թարմացումից, նախքան ցանցը ստուգեք հավելվածի գրառումը։
Ստուգեք, ինչ կարող է վերցնել թունելը
Հավելվածային թունելը ընտրվում է ըստ աղբյուր հավելվածի, ուստի հեռախոսի լռելյան ուղին դեռ պատկանում է Wi-Fi-ին կամ բջջային ցանցին։ OverridePrimary-ը այն բանալին է, որը փոխում է դա։ Երբ պրոֆիլը սահմանում է այն, թունելը վարվում է ամբողջ թունելի պես, և յուրաքանչյուր հավելված ժառանգում է այն, ուստի VPN-ով անցնող ամեն ինչ դառնում է պրոֆիլի հարց, ոչ հավելվածի խափանում։
Պահանջով գործարկման կանոնները որոշում են կայունությունը։ OnDemandEnabled-ը և նրա կանոնների հավաքածուն են, որ թունելը վերադառնում է, երբ հավելվածը թրաֆիկ է ուղարկում, դիմանում Wi-Fi-ից բջջային ցանց անցմանը, կամ իջնում, երբ հավելվածը անցնում է ֆոն։ Կապվող և հետո հանգչ մեռնող տեղակայումը սովորաբար ունի կանոն, որը համապատասխանում է միայն այն զոնդին, որը երբեք չի գործարկվում, քանի հավելվածը անգործ է։
Ապա անկեղծիվ կարդացեք ուղիների կողմը։ Եթե մատակարարի կամ վաճառողի պրոֆիլը տալիս է ներառման ցանկ, ապա թունելը, որը կրում է միայն 10.20.0.0/16, չի կրի ծառայություն 10.30.0.0/16-ում. ցանկն է կատարում իր գործը, ոչ հավելվածային խափանում։ Ներկառուցված iOS բեռնվածքը ներառման ցանկ չունի։ Առանց դրա բաժանումը հետևում է մատակարարի լռելյան կանխատիցումներին և IncludeAllNetworks-ին, ոչ թաքնված ցանկի։
Փորձարկեք հավելվածը, ապա այն, ինչ դուրս է գալիս դրանից
Փորձարկեք անունով, ոչ միայն հասցեով։ Կառավարվող հավելվածի ներսում ներքին հոսթի լուծումը ապացուցիկ է, որ DNS-ն նույնպես անցել է թունելով, քանի բեռնվածքն է որոշում, թե որ լուծիչը կպատասխանի և թե որ որոնման տիրույքները կիրարկվեն։ Երթուղավորումը կարող է կատարյալ, մինչդեր անվան որոնումը ձախbեղում է, և երկու աղտանշանները մատնանում են տարբեր կարգավորումների։
Ապա փորձարկեք սահմանը երկու կողմից։ Անձնական հավելվածը կամ Safari-ն պետք է հասնի սովորական հանրային էջի և հաղորդի օգտագործողի կամ տան հասցեն, մինչդեր կառավարվող հավելվածը հասնում է մասնավոր ծառայության։ Եթե երկուսն էլ հաղորդում են նույն հանրային հասցեն, թունելը այլևս հավելվածային չէ, ինչ էլ պնդի հավելվածի գրառումը։
Հավելվածից դուրս եկող հոսքերը ստեղծում են շարշող տոմսները։ Safari-ում բացվող հղումը, բաժանման թերթից փոխանցված փաստաթուղթը կամ դիտարկիչում անցնող SSO մուտքը թողնում են հավելվածի գործընթացը և նրա հետևից՝ թունելը։ Հավելվածի ներսում ցուցադրվող մուտքը սովորաբար վերագրվում է հավելվածին, ուստի ներարված մուտքը կարող է հաջողվի այնտեղ, որտեղ նույն URL-ը ձախողվում է Safari-ում. ստուգեք դա, ոչ ենթադրեք։ Երբ ինքնության մատակարարը հասանելի է միայն թունելով, կամ պահեք մուտքը հավելվածի ներսում, կամ ավելացրեք մատակարարի տիրույքը բեռնվածքի Safari տիրույքներին, որպեսզի համապատասխան Safari թրաֆիկը բունդ արվի։
Համապատասխանեք աղտանշանը շերտի հետ
Խափանման ձևը ասում է, թե որ ստուգումը կրկնել։
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
Միջին տողերի հետևում երկու մանրամաս կա. հավելվածային թունելը կարող է առողջ լինել և այնուամենայնջ բաց թողնել ենթացանց, որը ոչ մի մատակարարի ցանկ չի ներառում, և կառավարվող հեռախոսը կարող է պահել մեկից ավելի VPN կարգավորում, ուստի համոզվեք, թե որին է կապված հավելվածը, ոչ ենթադրեք, որ դա ձեր կարդացողն է։
Ուղղեք այս հերթով. ուղղեք հավելվածի գրառումը, որպեսզի այն հղում է կենդանի բեռնվածքին, վերատեղադրեք հավելվածը կառավարման միջոցով, համոզվեք, որ թունելը բարձրանում է հավելվածի առաջին հարցով, ապա կրկնեք անվան և սահմանի փորձերը։ Եթե առաջին հարցումը ընդհանրապես չի կարող թունել գործարկել, կանգ առեք և ստուգեք մատակարարի կողմը, քանի հատուկ համակարգիչին անհրաժեշտ է Network Extension-ի առկայությունը և տեղադրված հավելվածին համապատասխան նույնացուցը։
Վերադարձրեք երեք փաստ էկրանի նկարի փոխարեն. թե որ բեռնվածքին շուղ է հղում հավելվածի գրառումը, արդյոք Կարգավորումները ցուցադրում են այն որպես տեղադրված պրոֆիլ, և ինչ էր ձախողված հարցումը՝ անուն, հասցե, թե դիտարկիչին փոխանցում։ Այս երեք պատասխանները տարբերում են տեղակայման սխալը երթուղավորման սխալից, և հաջորդ մարդը կարող է գործել առանց ախտորոշումը կրկնելու։