iOS VPN API: NEVPNManager, давател на тунел или профил?

Три различни производи одговараат на името iOS VPN и тие не делат еден API. Personal VPN се потпира на вградените IPsec и IKEv2 транспорти на системот. Custom tunnel го извршува вашиот сопствен протокол внатре во network extension. Configuration profile конфигурира кое било од двете и може да додаде on-demand однесување. Изборот според транспортот со кој мора да зборувате е побрз од изборот според тоа кое упатство прво се компајлирало.

Извршете ги проверките подолу по ред, бидејќи секој чекор претпоставува дека претходниот создал валидна конфигурација.

Чекор 1: изберете според транспортот

Ако серверот е IKEv2 или IPsec во Cisco стил, 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 при потпишување, а Developer ID build надвор од App Store и понатаму мора да го носи во provisioning profile. Entitlement што недостасува изгледа како грешка во протоколот бидејќи extension едноставно не стартува.

Нема јавен socket descriptor што може да се позајми. NEPacketTunnelProvider ви дава NEPacketTunnelFlow со read, write и cancel, а кодот што посегнува по приватни патеки на клучеви се крши помеѓу изданија. Provider продолжува да работи додека апликацијата е во позадина, па на container апликацијата не ѝ треба позадински режим за тоа.

Чекор 4: on-demand е збир правила, не прекинувач

isOnDemandEnabled само ги активира правилата; NEOnDemandRuleConnect и неговите браќа одлучуваат кога тунелот се крева. Правилото evaluate-connection со probe URL е добро колку и тој URL. Ако probe одговори без тунелот, правилото заклучува дека приватната мрежа е веќе достапна и никогаш не се поврзува, затоа насочете го кон нешто што одговара само од внатре.

Always-on е посебно ветување. Бара надгледуван уред и управуван профил, а ненадгледуван корисник може да го отстрани профилот кога сака. Не испорачувајте дизајн што зависи од always-on, освен ако флотата е надгледувана.

Чекор 5: докажете ја патеката, не етикетата

Скенирањето tun, tap, ppp или ipsec интерфејси докажува дека VPN е конфигуриран, не дека вашето барање го користело. NWPathMonitor со usesInterfaceType(.other) вели дека виртуелниот интерфејс е достапен, а viability handler може да тестира еден хост. Ниту едно не ја докажува излезната патека, затоа комбинирајте ги со барање до ресурс што само тунелот може да го достигне. Имињата на интерфејсите се дијагностичка помош, никогаш порта на која апликациската логика би требало да се разгранува.

За теренска проверка, споредете ја јавната адреса со и без тунелот и преземете страница само за внатрешна употреба. Status повикот може да пријави поврзаност додека provider преговара, затоа нека одлучи резултатот од ресурсот, а status третирајте го како придружен доказ.