iOS VPN API-ներ. NEVPNManager, թունելի մատակարար, թե՞ պրոֆիլ

Երեք տարբեր արտադրանք կրում են iOS VPN անվանումը, և նրանք չեն կիսում մեկ API։ Personal VPN-ը հենվում է համակարգի ներկառուցված IPsec և IKEv2 տրանսպորտների վրա։ Custom tunnel-ը ձեր սեփական արձանագրությունն է աշխատեցնում network extension-ի ներսում։ Configuration profile-ը կարգավորում է դրանցից որևէ մեկը և կարող է ավելացնել on-demand վարքագիծ։ Ընտրել ըստ այն տրանսպորտի, որի հետ պետք է խոսել, ավելի արագ է, քան ընտրել ըստ այն ձեռնարկի, որն առաջինը կոմպիլացվեց։

Ստորև բերված ստուգումները կատարեք հերթականությամբ, որովհետև յուրաքանչյուր քայլ ենթադրում է, որ նախորդը ստացել է վավեր կոնֆիգուրացիա։

Քայլ 1: ընտրեք ըստ տրանսպորտի

Եթե սերվերը IKEv2 է կամ Cisco-ի ոճի IPsec, NEVPNManager-ը բավական է, և համակարգի տրանսպորտները անվճար են գալիս։ Եթե սերվերը խոսում է OpenVPN, WireGuard կամ այլ բան, NEVPNManager-ը չի կարող օգնել՝ այն կեռիկ չունի երրորդ կողմի արձանագրության համար։ Այդ դեպքում անհրաժեշտ է NETunnelProviderManager՝ packet tunnel provider-ով, որը ներդնում է արձանագրությունը։ Պրոֆիլը միայն բաշխում է կոնֆիգուրացիա, և այն չի կարող ավելացնել տրանսպորտ, որը բացակայում է օպերացիոն համակարգում։

PPTP-ն նպատակ չէ ընթացիկ համակարգերում։ Shared-secret IPsec-ը դեռ սպասում է խմբի անվանը remoteIdentifier-ում, գաղտնիքը պահող keychain տարրին և ընդլայնված նույնականացմանը, երբ սերվերը օգտանուն է հարցնում։ Յուրաքանչյուր պակասող մաս ի հայտ է գալիս որպես նույն ընդհանուր կոնֆիգուրացիայի սխալ, ուստի ավելացրեք դրանք բոլորը, նախքան որևէ այլ բան վրիպազերծելը։

Քայլ 2: հարգեք պահելու, բեռնելու և սկսելու հերթականությունը

NEVPNManager-ը գրում է preferences-ում, կարդում է դրանք հետ, և միայն դրանից հետո սկսում։ Լրացրեք արձանագրության և manager-ի օբյեկտները, կանչեք saveToPreferences, կանչեք loadFromPreferences և կանչեք startVPNTunnel՝ load completion handler-ից։ Բեռնման վերադարձից առաջ սկսելը առաջացնում է configuration-invalid սխալ՝ NEVPNErrorDomain code 1, այն կոնֆիգուրացիայի վրա, որն այլապես ճիշտ է։

Ձևը բավական կարճ է, որպեսզի պահվի մեկ տեղում:

manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }

startVPNTunnel-ը վերադառնում է, երբ հարցումն ընդունված է, այլ ոչ այն ժամանակ, երբ թունելը բարձրացած է։ Հետևեք NEVPNStatusDidChange-ին և կարդացեք connection.status-ը իրական վիճակի համար։ Հավելվածը, որը հաջողություն է ենթադրում կանչի տեղում, հաղորդում է միացված VPN, մինչ extension-ը դեռ բանակցում է։ Connecting կարգավիճակը սովորական է մի պահով՝ այն կարգավիճակը, որը երբեք դուրս չի գալիս դրանից, այն ձախողումն է, որն արժե գրանցել։

Քայլ 3: տվեք provider-ի պրոցեսին այն, ինչ նրան անհրաժեշտ է

Custom transport-ը աշխատում է առանձին պրոցեսում՝ իր bundle identifier-ով և իր entitlement-ով։ Ինչպես container հավելվածին, այնպես էլ provider-ին ստորագրման պահին անհրաժեշտ է network-extension entitlement-ը, և App Store-ից դուրս Developer ID build-ը դեռ պետք է այն կրի provisioning profile-ում։ Բացակայող entitlement-ը նման է արձանագրության սխալի, որովհետև extension-ը պարզապես չի մեկնարկում։

Հանրային socket descriptor չկա փոխառելու համար։ NEPacketTunnelProvider-ը ձեզ տալիս է NEPacketTunnelFlow՝ read, write և cancel-ով, և մասնավոր բանալու ուղիներին հասնող կոդը կոտրվում է թողարկումների միջև։ Provider-ը շարունակում է աշխատել, մինչ հավելվածը background-ում է, ուստի container հավելվածին դրա համար background ռեժիմ պետք չէ։

Քայլ 4: on-demand-ը կանոնների հավաքածու է, ոչ թե անջատիչ

isOnDemandEnabled-ը միայն զինում է կանոնները. NEOnDemandRuleConnect-ը և նրա քույրերը որոշում են, թե երբ է թունելը բարձրանում։ probe URL-ով evaluate-connection կանոնը լավ է այնքանով, որքանով լավ է այդ URL-ը։ Եթե probe-ը պատասխանում է առանց թունելի, կանոնը եզրակացնում է, որ մասնավոր ցանցն արդեն հասանելի է և երբեք չի միանում, ուստի ուղղեք այն մի բանի, որ պատասխանում է միայն ներսից։

Always-on-ը առանձին խոստում է։ Այն պահանջում է հսկվող սարք և կառավարվող պրոֆիլ, և չհսկվող օգտատերը կարող է հեռացնել պրոֆիլը ցանկացած պահի։ Մի թողարկեք դիզայն, որը կախված է always-on-ից, եթե պարկը հսկվող չէ։

Քայլ 5: ապացուցեք ուղին, ոչ թե պիտակը

tun, tap, ppp կամ ipsec ինտերֆեյսների սկանավորումը ապացուցում է, որ VPN-ը կարգավորված է, ոչ թե որ ձեր հարցումն օգտագործել է այն։ NWPathMonitor-ը usesInterfaceType(.other)-ով ասում է, որ վիրտուալ ինտերֆեյսը հասանելի է, և viability handler-ը կարող է ստուգել մեկ հոսթ։ Ոչ մեկը չի ապացուցում ելքի ուղին, ուստի միավորեք դրանք հարցման հետ դեպի ռեսուրս, որին հասնում է միայն թունելը։ Ինտերֆեյսների անունները ախտորոշման օժանդակ միջոց են, երբեք դարպաս, որի վրա հավելվածի տրամաբանությունը պետք է ճյուղավորվի։

Դաշտային ստուգման համար համեմատեք հանրային հասցեն թունելով և առանց դրա, և բերեք միայն ներքին էջ։ Status կանչը կարող է հաղորդել միացված, մինչ provider-ը բանակցում է, ուստի թող ռեսուրսի արդյունքը որոշի, և status-ը դիտեք որպես օժանդակ ապացույց։