Што може да создаде NEVPNManager на iOS (а што не)

Кога градите VPN екран во апликација за iOS, првото изненадување е што списокот на протоколи во апликацијата Поставки не е списокот на API-то. Рамката Network Extension ѝ овозможува на вашата апликација да создаде една лична VPN конфигурација, во сопственост на таа апликација, и прифаќа само неколку протоколски објекти. Сѐ друго што луѓето го очекуваат, од L2TP до преземен профил, е надвор од таа површина или е приватно за Apple. Грешките што следат обично не се бубачки, тоа API-то одбива работа што никогаш не ја добило.

Мит: API-то е уредувач на Поставки

Се верува дека бидејќи iOS може да конфигурира профили IKEv1, IKEv2, L2TP и IPsec, апликацијата може програмски да создаде кој било од нив. Не може. Рамката ѝ изложува точно едно конфигурациско место на апликацијата што ја повикува, и тоа место прифаќа само мал сет јавни протоколски класи. Сѐ друго што луѓето го очекуваат, од L2TP до преземен профил, е надвор од таа површина или е приватно за Apple.

Грешките што следат обично не се бубачки. Тоа API-то одбива работа што никогаш не ја добило, а решението е екранот да се дизајнира околу она што API-то го поседува.

Три протоколски објекти и тие што не постојат

Вашите опции се IKEv1 преку NEVPNProtocolIPSec, IKEv2 преку NEVPNProtocolIKEv2, и NETunnelProviderProtocol ако доставувате сопствено продолжување за пакетски тунел. Референцата на NEVPNManager ги наведува прифатените протоколски објекти. L2TP и PPTP никогаш не се појавуваат на тој список затоа што Apple не објави класи за нив. Обидот за било кое од нив завршува при зачувувањето со грешка или, уште полошо, со конфигурација што системот тивко одбива да ја користи.

Кодот за десктоп следи други правила. На macOS, SCNetworkInterfaceCreateWithInterface натрупува тип на интерфејс како L2TP над IPv4 и го прикачува на мрежна услуга, а networksetup -connectpppoeservice го стартува резултатот. Потребни се администраторски права и помошна алатка, бидејќи заедничката тајна и лозинката одат во системскиот привезок на клучеви. Копирајте го тој дизајн на iOS и ништо не се компајлира.

Предадете референца од привезокот на клучеви, не лозинката

Ниту една IKE класа не прифаќа лозинка како текст. Двете својства passwordReference и sharedSecretReference сакаат постојана референца од привезокот на клучеви, која ја добивате од SecItemCopyMatching со барање на kSecReturnPersistentRef. Предавањето на податоците од ставката или внесувањето низа во полето создава неуспех при зачувување или врска со празни акредитиви. Референцата е издржлива само колку ставката од привезокот на клучеви зад неа, затоа ставката мора да постои пред конфигурацијата да се состави. Создадете ја во истата трансакција како зачувувањето и отстранувате цела класа грешки со редослед.

Автентикацијата со сертификат оди по друг пат: identityData плус identityDataPassword за PKCS#12 блок. Доставувањето на тој блок внатре во пакетот на апликацијата е навика пренесена од примерниот код, а не одлука за издавање, бидејќи лозинката патува со него и секоја копија од апликацијата носи истиот идентитет.

Правото и достапноста портат сѐ

Менаџерот може воопшто да не постои, а причината е провизионирањето. Идентификаторот на вашата апликација бара способност Network Extension заедно со право за личен VPN, а профилот што го потпишува градењето мора да ги носи двете.

Прескокнете го тоа и споделената инстанца враќа nil, или зачувувањето не успева со грешка што никогаш не го споменува правото. Достапноста е другата порта. Ако целите на нешто постаро од iOS 8, симболот недостасува при извршувањето, па неуспехот е пад или nil менаџер, а не менаџер без конфигурација. Проверете го извршното опкружување и правото пред да го дебагирате вашиот граф на објекти.

Вчитајте, изменете, зачувајте, потоа следете го редоследот на барање

Третирајте го животниот циклус како вчитување, измена и зачувување и никогаш не го прескокнувајте вчитувањето. Додека loadFromPreferences не заврши, менаџерот не држи ништо и протоколскиот објект не може да се чита или замени.

Второто зачувување ја заменува конфигурацијата наместо да додаде уште една, па половично зачувување може да го оштети профилот што работел. Правилата на барање формираат подредена низа, и тој редослед е политиката. Ставете го правилото за поврзување од каде било пред правилото за исклучување и по рачното исклучување следи веднаш повторно поврзување, што изгледа како дефект но го следи документираното оценување.

Преместете го правилото за исклучување напред кога дејството на корисникот мора да победи. Она што останува надвор од контролата на апликацијата е исто толку важно. Рутите доаѓаат од тунелот или од серверската политика, а не од поставка што ја задавате вие, при што давателот на пакетски тунел известува за нив кога ќе стартува. Апликацијата не може да ги наведе или уредува профилите инсталирани од други апликации или конфигурациски профили, затоа не ветувајте екран што го прикажува секој VPN на уредот.