iOS VPN API: NEVPNManager, mai samar da tunnel ko profile?

Kayayyaki daban-daban guda uku ne ake kira da sunan iOS VPN, kuma ba sa raba API ɗaya. Personal VPN yana amfani da IPsec da IKEv2 da ke cikin tsarin. Custom tunnel yana tafiyar da ka'idar ku a cikin network extension. Configuration profile yana daidaita ɗaya daga cikinsu kuma yana iya ƙara on-demand behaviour. Zaɓi bisa ga transport ɗin da dole ku yi magana da shi ya fi sauri fiye da zaɓi bisa kowane tutorial da ya fara compile.

Yi gwaje-gwajen da ke ƙasa bisa tsari, domin kowane mataki yana ɗauka cewa na baya ya samar da ingantaccen configuration.

Mataki 1: zaɓi bisa ga transport

Idan uwar garken IKEv2 ne ko IPsec irin na Cisco, NEVPNManager ya isa kuma transport ɗin tsarin yana zuwa kyauta. Idan uwar garken yana magana da OpenVPN, WireGuard ko wani abu dabam, NEVPNManager ba zai iya taimakawa ba: ba shi da hanyar haɗi ga protocol na ɓangare na uku. Wannan yanayin yana buƙatar NETunnelProviderManager tare da packet tunnel provider wanda ke aiwatar da protocol ɗin. Profile yana rarraba configuration ne kawai, kuma ba zai iya ƙara transport da tsarin aiki ba shi da shi.

PPTP ba ya cikin manufa a tsarin yanzu. IPsec na sirrin da aka raba har yanzu yana buƙatar sunan rukuni a cikin remoteIdentifier, abu na keychain da ke riƙe da sirrin, da kuma ingantaccen tabbaci lokacin da uwar garken ta nemi sunan mai amfani. Kowace ɓangare da ya ɓace yana bayyana a matsayin kuskuren configuration iri ɗaya, don haka ƙara su duka kafin yin debugging wani abu.

Mataki 2: bi tsarin ajiya, lodawa da farawa

NEVPNManager yana rubutu zuwa preferences, ya karanta su, sa'an nan kawai ya fara. Cika abubuwan protocol da manager, kira saveToPreferences, kira loadFromPreferences, kuma kira startVPNTunnel daga load completion handler. Farawa kafin load ya dawo yana haifar da kuskuren configuration mara inganci, NEVPNErrorDomain code 1, a kan configuration da ta dace.

Tsarin ya yi gajarta sosai don a ajiye shi a wuri ɗaya:

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

startVPNTunnel yana dawowa lokacin da aka karɓi buƙatar, ba lokacin da tunnel ɗin ya tashi ba. Kula da NEVPNStatusDidChange kuma karanta connection.status don ainihin yanayin. App da ke ɗauka cewa an yi nasara a wurin kira yana ba da rahoton VPN da ke haɗe yayin da extension ɗin ke ci gaba da tattaunawa. Matsayin connecting yana da kyau na ɗan lokaci; matsayin da ba ya fita daga gare shi shine gazawar da ta cancanci yin log.

Mataki 3: ba wa tsarin provider abin da yake buƙata

Custom transport yana gudana a cikin tsari dabam da nasa bundle identifier da nasa entitlement. Duka container app da provider suna buƙatar entitlement ɗin network-extension a lokacin sanya hannu, kuma ginin Developer ID da ke wajen App Store har yanzu dole ne ya ɗauke shi a cikin provisioning profile. Entitlement da ya ɓace yana kama da kuskuren protocol domin extension ɗin ya kasa farawa kawai.

Babu wani socket descriptor na jama'a da za a aro. NEPacketTunnelProvider yana ba ku NEPacketTunnelFlow tare da read, write da cancel, kuma code da ke kaiwa ga private key paths yana karyewa tsakanin releases. Provider yana ci gaba da gudana yayin da app ɗin ke background, don haka container app ba ya buƙatar yanayin background don hakan.

Mataki 4: on-demand saitin ƙa'ida ne, ba switch ba

isOnDemandEnabled yana shirya ƙa'idojin kawai; NEOnDemandRuleConnect da 'yan uwansa ne ke yanke shawarar lokacin da tunnel ɗin zai tashi. Ƙa'idar evaluate-connection tare da probe URL tana da kyau kamar yadda wannan URL ɗin yake. Idan probe ɗin ya amsa ba tare da tunnel ɗin ba, ƙa'idar tana yanke hukuncin cewa private network ɗin ta riga ta isa kuma ba za ta taɓa haɗuwa ba, don haka a nuna ta ga wani abu da ke amsawa daga ciki kawai.

Always-on alkawari ne dabam. Yana buƙatar na'ura da aka kula da ita da profile ɗin da aka sarrafa, kuma mai amfani da ba a kula da shi ba zai iya cire profile a duk lokacin da ya so. Kada ku aika ƙirar da ta dogara da always-on sai idan an kula da rundunar.

Mataki 5: tabbatar da hanyar, ba lakabin ba

Bincika tun, tap, ppp ko ipsec interfaces yana tabbatar da cewa an saita VPN, ba cewa buƙatarku ta yi amfani da ita ba. NWPathMonitor tare da usesInterfaceType(.other) yana cewa akwai virtual interface, kuma viability handler zai iya gwada host ɗaya. Babu ɗayansu da ke tabbatar da hanyar fita, don haka haɗa su da buƙata zuwa wani albarkatu da tunnel ɗin kaɗai zai iya isa. Sunayen interface kayan aikin ganowa ne, ba ƙofar da dabarun application ya kamata ya dogara da ita ba.

Don gwajin fili, kwatanta adireshin jama'a tare da tunnel da kuma ba tare da shi ba, sannan kawo shafin ciki kawai. Kira na matsayi zai iya ba da rahoton haɗe yayin da provider ke tattaunawa, don haka bar sakamakon albarkatun ya yanke hukunci kuma ɗauki matsayin a matsayin shaida mai goyan baya.