VPN-ի պրոֆիլը չի ներմուծվում macOS-ում՝ նախ կարդացեք օգտակար բեռը

Երբ պրոֆիլը մեկ Mac-ում տեղադրվում է անխոչընդոտ, իսկ մյուսում մերժվում, ցանցին դեռ չենք հասել, ուստի վկայագրերը, դարպասները և գաղտնաբառերը որևէ մեղք չունեն։ Տեղադրիչը կանգ է առել օգտակար բեռի վրա, որը չէր ուզում ընդունել, և սովորաբար գրանցում է, թե որն էր։ Սա թողնում է պրոֆիլի ֆայլը և այն ամենը, ինչ ստեղծել է այն, որպես աշխատելու միակ ողջամիտ վայրեր, և կլիենտում կարգավորումները ջնջելը դարձնում է ապացույցներ ոչնչացնելու միջոց, այլ ոչ թե վերանորոգում։

Կարդացեք պրոֆիլը՝ Mac-ը վերակայելու փոխարեն

Արտահանեք .mobileconfig-ը և տեսեք, թե այն իրականում ինչ է պարունակում, նախքան կլիենտին դիպչելը։

plutil -p profile.mobileconfig | head -60

VPN պրոֆիլն իրականում երկու օգտակար բեռ է՝ տարբեր աշխատանքներով, com.apple.vpn.managed-ը պահում է միացումը, իսկ com.apple.dnsSettings.managed-ը՝ լուծիչի կարգավորումը։ Տեղադրումը կանգ է առնում առաջին այն բեռի վրա, որը տեղադրիչը մերժում է, և մերժումը մտնում է համակարգի մատյան՝ այդ բեռի անունով, ուստի մատյանն է ասում, թե որ բաժինը բացել։ Պահեք վերջին հաջող ներմուծված պրոֆիլի պատճենը, որովհետև այդ ֆայլն այն հիմքն է, որի դեմ չափվում է ձեր տարբերությունը։

Ինչ ավելացրեց գեներատորը լուռ

Apple Configurator 2.15-ը՝ 7A23 կառուցվածքը, իր DNS բեռի մեջ թողարկեց հետևյալ բլոկը։

<key>DNS</key>
<dict>
  <key>SupplementalMatchDomainsNoSearch</key>
  <integer>0</integer>
</dict>

macOS 12.1-ում այդ կառուցվածքով գրված պրոֆիլները մերժվեցին ներմուծման պահին։ Configurator 2.11.1-ով ստեղծված միացումն անցավ առանց բողոքի, քանի որ այդ թողարկումը բանալին ընդհանրապես չէր գրում։ Հեռացրեք ամբողջ DNS բառարանը կամ միայն խնդրահարույց բանալին, նորից պահեք, ապա կրկին փորձեք նույն մեքենայի վրա, նախքան որևէ այլ բան փոխելը։ Սովորաբար այդ մեկ խմբագրումն է ամբողջ վերանորոգումը։

Գործիքն ունի ծուղակ, որն արժե իմանալ նախքան դրան վստահելը։ Բանալին ջնջելուց հետո նույն միացումը պահելը այն հետ չբերեց, և այն նորից հայտնվեց միայն այն ժամանակ, երբ միացումը ստեղծվեց զրոյից։ Վերաբերվեք յուրաքանչյուր նոր ստեղծված պրոֆիլի որպես կասկածելիի և ստուգեք այն, հատկապես երբ միացումների մի ամբողջ խմբաքանակ ստեղծվել է մեկ նստաշրջանում։

MDM ուղին ձախողվում է այլ տեղ

Նույն պրոֆիլը մղող կառավարման ծառայությունը կարող է ձախողվել այլ կետում՝ կլիենտը բողոքում է, որ VPN ծառայություն ընդհանրապես չի ստեղծվել։ Հաղորդված դեպքում վկայագրով նույնականացման համար կարգավորված բեռը այնուամենայնիվ պահանջում էր գաղտնաբառի դաշտ, այն տեղապահով լրացնելը թույլ տվեց կիրառել պրոֆիլը, և ոչինչ երբեք այդ արժեքը չօգտագործեց նույնականացման համար։

Եթե ընտրեք այդ ուղին, պահեք կեղծ տող և երբեք իրական հավատարմագրեր, և իսկական գաղտնիքը պահեք պրոֆիլի մարմնից դուրս։ Աշխատող գաղտնաբառ կրող պրոֆիլը դառնում է ֆայլ, որը պետք է պաշտպանել ինչպես բանալի, և դա զգալիորեն ավելի մեծ խնդիր է, քան այն ձախողված ներմուծումը, որով սկսել եք։ Որոշեք, թե ումն է այդ տեղապահը, նախքան պրոֆիլը կբաշխվի, որպեսզի հետո ոչ ոք այն չընկալի որպես փոխարկման արժանի արժեք։ Նշելը, թե ինչու այն գոյություն ունի, մեկ տող է զբաղեցնում և վեց ամիս անց խնայում է մի վեճ։

Համոզվեք, որ պրոֆիլն իսկապես վայրէջք է կատարել։

Հաջող ներմուծումը աշխատող ծառայություն չէ, ուստի ստուգեք այս հերթականությամբ։

profiles show -type configuration
scutil --nc list
scutil --nc start "Your VPN Service"
scutil --nc status "Your VPN Service"
scutil --dns | head -20

Առաջին հրահանգը թվարկում է տեղադրված բեռերը, երկրորդը ասում է՝ արդյոք ընդհանրապես գոյություն ունի VPN ծառայություն։ Վերջինը, որը գործարկվում է միանալուց հետո, ցույց է տալիս լուծիչը, որն իրականում կօգտագործի համակարգը։ Կարդացեք դրանք այդ հերթականությամբ և կանգ առեք այնտեղ, որտեղ շղթան կոտրվում է, որովհետև բացակայող ծառայությունը լուծիչի մասին ցանկացած հարց դարձնում է անիմաստ։ Պրոֆիլը կարող է նշված լինել որպես տեղադրված և այնուամենայնիվ ոչ մի օգտագործելի բան չունենալ, և հենց այդ վիճակը բացահայտելու համար է նախատեսված այս հաջորդականությունը։

Եթե թունելը բարձրանա, մինչ ծառայության գրառումը դեռ օգտագործելի անուն չունի, ցուցադրվող անվան դաշտը կորել է արտահանման ժամանակ, և բուժումը վերաստեղծված պրոֆիլն է, այլ ոչ թե կլիենտում անունը փոխելը։ Եթե լուծիչը շարունակում է մատնանշել տեղականին, ապա DNS բեռը հեռացվել է ավելի հիմնովին, քան նախատեսել էիք։

Տարածեք փուլերով՝ միաժամանակ մեկ Mac։

Տեղադրեք մեկ կառավարվող Mac-ում, որն աշխատում է նույն ՕՀ կառուցվածքով, ապա առանձին ստուգեք երեք բան՝ ծառայությունը հայտնվում է, լուծիչը փոխվում է, և մեկ իրական ներքին հարցում հաջողվում է։ Միայն երեքից հետո պետք է ընդլայնել ծածկույթը։

Սրանք երեք տարբեր արդյունքներ են, որոնք ձախողվում են երեք տարբեր ձևերով, և հենց դա է մեկ փորձնական մեքենան դարձնում այդ տասը րոպեի արժանի։ Ներմուծվող պրոֆիլը աշխատող պրոֆիլ չէ, և առաջին փուլի մեքենան որսում է ձախողման երկու տեսակներն էլ, նախքան նավատորմի մնացած մասը կտեսնի դրանցից որևէ մեկը։