NEVPNManager-ը չի պահպանում? Հերթականությունը՝ բեռնել, միացնել, պահպանել, կապվել
4 և 5 կոդերը սովորաբար նշանակում են, որ պրոֆիլը խմբագրվել է բեռնելուց առաջ կամ պահպանվել է անջատված վիճակում։ Ուղղեք կանչերի հերթականությունը, ապա ստուգեք իրավունքը։
Երկու սխալի կոդ բացատրում են iOS-ում Network Extension VPN-ի առաջին փորձերի մեծ մասը՝ NEVPNErrorDomain Code=4 և Code=5։ Դրանցից ոչ մեկը սերվերի բողոք չէ։ Մեկը հայտնվում է, երբ հավելվածը կարգավորումներ է գրում մի օբյեկտի մեջ, որը երբևէ չի կարդացվել սկավառակից, իսկ մյուսը՝ երբ ինքը գրառումը ձախողվում է, ամենից հաճախ այն պատճառով, որ պրոֆիլը պահպանվում է դեռ անջատված վիճակում։ Երկուսն էլ ուղղվում են չորս կանչերի հերթականությունը փոխելով, ոչ թե IKEv2 պարամետրերին դիպչելով։
Նախ բեռնեք, այլապես պահպանելուն համեմատելու բան չկա
Կառավարիչը պահում է պահպանված պրոֆիլի պատճենը, և այն օբյեկտը, որը խմբագրում եք, այդ պատճենը չէ, քանի դեռ չեք կարդացել այն։ Նախ կանչեք loadFromPreferences, խմբագրեք դրա ավարտի մշակիչի ներսում, ապա պահպանեք։ Եթե բաց թողնեք ընթերցումը, շրջանակը անհամապատասխանություն կտեսնի իր ունեցածի և ձեր գրածի միջև։ Swift-ում ձևը նույնն է յուրաքանչյուր քայլի համար, և յուրաքանչյուր քայլ պատկանում է իր closure-ին՝
let mgr = NEVPNManager.shared()
mgr.loadFromPreferences { loadErr in
guard loadErr == nil else { return }
let proto = NEVPNProtocolIKEv2()
proto.serverAddress = "vpn.example.net"
proto.username = "alice"
proto.useExtendedAuthentication = true
mgr.protocolConfiguration = proto
mgr.isEnabled = true
mgr.saveToPreferences { saveErr in
// do not start here; reload, then connect
}
}
Թունելը պահպանման closure-ի ներսից սկսելը նույն սխալն է այլ տեղ։ Այն աշխատում է նախքան պրոֆիլը նորից կարդալը, ուստի սկզբի կանչը տեսնում է ձեր կառուցած վիճակը, ոչ թե պահպանված վիճակը։ Պահպանման closure-ն ավարտվում է երկրորդ loadFromPreferences-ով, և միայն այդ ավարտի մշակիչն է կանչում startVPNTunnel։
Միացման դրոշը պահպանման մասն է
Պահպանված պրոֆիլն անգործուն է, քանի դեռ այն չի միացվել։ Սահմանեք isEnabled = true նույն գրառման մեջ, այլապես պրոֆիլը սկավառակի վրա կհայտնվի անջատված, և startVPNTunnel կհրաժարվի, նույնիսկ եթե Կարգավորումները ցույց են տալիս ամբողջական թվացող կազմաձև։
Արտաքին խմբագրումները մյուս կեսն են։ Եթե օգտատերը ինչ-որ բան փոխում է Կարգավորումներում, կամ սարքը տեղափոխվում է ցանցերի միջև, նորից կարդացեք նախքան հիշողության մեջ դեռ պահած արժեքներին վստահելը։ Օբյեկտը այդ փոփոխությունները ձեր փոխարեն չի դիտարկում։ Հնացած պատճենն այն ձևն է, որով հավելվածը գրում է պրոֆիլ, որը լուռ հետ է վերադարձնում օգտատիրոջ խմբագրումը։ Երկու հարևան դաշտեր նույն պահին հանգիստ դժվարություն են ստեղծում՝ on-demand կանոնները պետք է լինեն կանոնների օբյեկտների զանգված, ոչ թե դատարկ տեղապահ, և disconnectOnSleep-ը պետք է արտացոլի ձեր ընտրած վարքը, ոչ թե պատճենված լռելյայնը։
Երրորդ կողմի հավելվածներին հասանելի են միայն երկու արձանագրություն
Network Extension-ը հավելվածներին տալիս է IPsec և IKEv2։ L2TP-ն ու PPTP-ն մնում են համակարգի ներսում, ուստի հավելվածը, որն ունի դրանց կարիքը, չի կարող ստանալ դրանք, և իրատեսական պատասխաններն են IKEv2-ունակ դարպաս կամ կառավարվող կազմաձևի պրոֆիլ։
Ուղեկցող տվյալները նույն օրինակին են հետևում։ Գաղտնաբառը դրեք Keychain-ում և տողի փոխարեն փոխանցեք մշտական հղում։ Պահպանման պահին զրոյական հղումը սովորաբար նշանակում է, որ որոնումը կատարվել է տարրը գրելուց առաջ, ոչ թե որ կառավարիչը կոտրված է։
Երկուսն էլ ձևավորման որոշումներ են, ոչ թե շրջանցումներ։ Հավելվածը, որը գաղտնաբառը պահում է իր նախապատվություններում, ընտրում է ուղի, որը շրջանակը չի խրախուսում, և դրա առաջացրած ձախողումը կարդացվում է որպես պահպանման սխալ։
Բացառեք իրավունքը նախքան կոդը վերաշարադրելը
Երբ loadFromPreferences-ը բացարձակապես հետ չի կանչում, հավանական պատճառը բացակայող Network Extension հնարավորությունն է կամ տրամադրման պրոֆիլը, որը չի կրում այն։ Այդ ձախողումը կախվում է սխալ տալու փոխարեն, և դրա համար էլ աշխատող կոդը ժամերով վերաշարադրվում է։ Ստուգեք իրավունքը այն ստորագրված կառուցման վրա, որը մտադիր եք թողարկել, քանի որ սիմուլյատորում և սարքում աշխատելը կարող են տարբերվել, և կարևոր թիրախը սարքն է։ Բացեք թիրախի ստորագրման կարգավորումները և հաստատեք, որ Network Extension հնարավորությունը առկա է հենց այդ կառուցման համար։
Առանց իրավունքի տրամադրման պրոֆիլը սարքաշարում նույն կերպ է ձախողվում, մինչդեռ նույն կառուցումը սիմուլյատորում կարող է սովորական բեռնվել։ Փորձարկեք ստորագրված արխիվը իրական սարքում նախքան կանչերի հերթականությունը վերաշարադրելը։
Դիտարկեք կարգավիճակի փոփոխությունները, ոչ թե ենթադրությունները
Դիտարկեք NEVPNStatusDidChangeNotification-ը և յուրաքանչյուր քայլից հետո գրանցեք manager.connection.status-ը։ Կարգավիճակը, որը երբեք չի հեռանում invalid-ից, նշանակում է, որ պրոֆիլը չի պահպանվել կամ իրավունքը բացակայում է։ Կապը, որը հասնում է connecting-ին և երբեք չի միանում, մատնանշում է առաջարկը կամ ուղեկցող տվյալները, ինչը այլ ապացույցներով այլ հետաքննություն է։
Հաստատեք, որ պրոֆիլը հայտնվում է Կարգավորումներ, Ընդհանուր, VPN բաժնում, և գրանցեք յուրաքանչյուր closure-ի սխալը։ Այս երկու փաստերը առանց գուշակության բաժանում են հերթականության սխալը թույլտվության սխալից։