API VPN у iOS: NEVPNManager, пастаўшчык тунеля ці профіль?

На імя VPN у iOS адказваюць тры розныя прадукты, і яны не падзяляюць адзін API. Асабісты VPN едзе на ўбудаваных у сістэму транспартах IPsec і IKEv2. Уласны тунель запускае ваш пратакол усярэдзіне пашырэння сеткі. А профіль канфігурацыі наладжвае любы з іх і можа дадаць паводзіны па патрабаванні. Выбар па транспарце, на якім трэба гаварыць, хутчэйшы за выбар па тым падручніку, які скампіляваўся першым.

Выканайце праверанні ніжэй па парадку, бо кожны крок мяркуе, што папярэдні стварыў сапраўдную канфігурацыю.

Крок 1: выбар па транспарце

Калі сервер працуе на IKEv2 або на IPsec у стылі Cisco, NEVPNManager дастаткова, і сістэмныя транспарты ідуць бясплатна. Калі сервер размаўляе на OpenVPN, WireGuard або чымсьці іншым, NEVPNManager не дапаможа: у ім няма кручка для пратаколу трэцяга боку. Гэты выпадак патрабуе NETunnelProviderManager з пастаўшчыком пакетнага тунеля, які рэалізуе пратакол. Профіль толькі распаўсюджвае канфігурацыю і не можа дадаць транспарт, якога няма ў аперацыйнай сістэме.

PPTP не з'яўляецца мэтай на сучасных сістэмах. IPsec з агульным сакрэтам па-ранейшаму чакае імя групы ў remoteIdentifier, элемент звязкі ключоў з сакрэтам і пашыраную аўтэнтыфікацыю, калі сервер просіць імя карыстальніка. Кожная адсутная частка выглядае як адна і тая ж агульная памылка канфігурацыі, таму дадайце ўсё перад адладкай чаго-небудзь іншага.

Крок 2: захоўвайце парадак захавання, загрузкі і запуску

NEVPNManager запісвае ў налады, чытае іх назад і толькі потым запускаецца. Запоўніце аб'екты пратаколу і менеджара, выклічце saveToPreferences, выклічце loadFromPreferences і выклічце startVPNTunnel з апрацоўшчыка завяршэння загрузкі. Запуск да вяртання загрузкі дае памылку несапраўднай канфігурацыі, код 1 у NEVPNErrorDomain, на канфігурацыі, якая інакш правільная.

Форма дастаткова кароткая, каб трымаць яе ў адным месцы:

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

startVPNTunnel вяртаецца, калі запыт прыняты, а не калі тунель узняты. Назірайце NEVPNStatusDidChange і чытайце connection.status для сапраўднага стану. Праграма, якая мяркуе поспех у месцы выкліку, паведамляе пра падключаны VPN, пакуль пашырэнне яшчэ вядзе перамовы. Стан падключэння — гэта нармальна на імгненне; стан, які ніколі з яго не выходзіць, і ёсць паломка, вартая запісу.

Крок 3: дайце працэсу пастаўшчыка тое, што яму трэба

Уласны транспарт працуе ў асобным працэсе са сваім ідэнтыфікатарам пакета і сваімі правамі. І праграма-кантэйнер, і пастаўшчык патрабуюць права пашырэння сеткі падчас подпісу, а зборка Developer ID па-за App Store усё адно павінна несці яго ў профілі забеспячэння. Адсутнае права выглядае як памылка пратаколу, бо пашырэнне проста не запускаецца.

Няма публічнага дэскрыптара сокета, які можна пазычыць. NEPacketTunnelProvider дае вам NEPacketTunnelFlow з read, write і cancel, а код, які цягнецца да прыватных шляхоў ключоў, ламаецца паміж выпускамі. Пастаўшчык працягвае працаваць, пакуль праграма ў фоне, таму кантэйнеру не патрэбны фонавы рэжым для гэтага.

Крок 4: патрабаванне — гэта набор правілаў, а не перамыкач

isOnDemandEnabled толькі ўзводзіць правілы; NEOnDemandRuleConnect і яго браты вырашаюць, калі тунель узнімаецца. Правіла ацэнкі злучэння з пробным URL такое ж добрае, як гэты URL. Калі проба адказвае без тунеля, правіла робіць выснову, што прыватная сетка ўжо дасяжная, і ніколі не злучаецца, таму накіруйце яго на тое, што адказвае толькі знутры.

Пастаянная праца — асобная абяцанка. Яна патрабуе прылады пад наглядам і кіраванага профілю, а карыстальнік без нагляду можа выдаліць профіль калі заўгодна. Не пастаўляйце дызайн, які залежыць ад пастаяннай працы, калі парк не пад наглядам.

Крок 5: дакажыце шлях, а не этыкетку

Сканаванне інтэрфейсаў tun, tap, ppp або ipsec даказвае, што VPN наладжаны, а не што ваш запыт ім скарыстаўся. NWPathMonitor з usesInterfaceType(.other) кажа, што віртуальны інтэрфейс даступны, а апрацоўшчык жыццяздольнасці можа праверыць адзін хост. Ні тое, ні другое не даказвае шлях выхаду, таму спалучыце іх з запытам да рэсурсу, да якога можа дабрацца толькі тунель. Імёны інтэрфейсаў — дыягнастычная дапамога, а ніколі не брама, на якую павінна разгаліноўвацца логіка праграмы.

Для палявой праверкі параўнайце публічны адрас з тунелем і без яго і загрузіце старонку, даступную толькі знутры. Выклік стану можа паведаміць пра падключэнне, пакуль пастаўшчык вядзе перамовы, таму няхай вырашае вынік рэсурсу, а стан лічыце дадатковым доказам.