Twa iPhone-VPN's tagelyk: hokker draacht dyn ferkear?
Twa ferbûne VPN's op in iPhone binne gjin ketting. Lês it dokumintearre mienskipmodel en test dan hokker konfiguraasje elk stream draacht.
Twa VPN-apps litte beide Connected sjen, en de oanname is dat ferkear no troch beide giet, de iene binnen de oare. Meastentiids is dat net sa. iOS hat in spesifyk mienskipmodel, en dat is gjin ketting. Ien konfiguraasjeklasse is beheind ta ien aktivearre eksimplaar, de oare kin dêrby rinne, en rûteprioriteit beslist konflikten. Twa oanbuorde skeakels binne gjin twa sprongen. It model is dokumintearre, wat betsjut dat it paad foarsjoen wurde kin ynstee fan rieden út ’e byldsjes.
Myt: twa ferbûne VPN's binne in ketting
In ketting fan twa sprongen hat in definiearre bûtenste ferfier, in definiearre binnenste tunnel, kompatibele einpunt-routing en in plan foar wat der bart as ien fan beide mist. Twa ûnôfhinklike konfiguraasjes meitsje dat net troch gewoan tagelyk te bestean. Rûteprioriteit is net itselde as ynkapseling, en dat ien konfiguraasje in rûtesykjen wint, seit neat oer oft de oare de resultearjende pakketten draacht.
As jo nêsting nedich hawwe, ûntwerp it dan as nêsting. Lied it net ôf fan twa ferbiningsoanjouwers. Dat ûnderskie sparret in protte debuggen.
It dokumintearre model efter dy myt
Apple syn NETunnelProviderManager beskriuwt gewoane bedriuws-VPN-konfiguraasjes en stelt dat fan dat soarte mar ien tagelyk aktivearre wurde kin. Deselde referinsje lit in Personal VPN aktivearre en ferbûn bliuwe dêrby, en jout de bedriuwsrûtes foarrang wêr’t de twa oerlaapje.
Personal VPN is hjir de API-term foar de ynboude IPsec- of IKEv2-ymplemintearring dy't fia NEVPNManager beheard wurdt. NETunnelProviderManager is it tunnel-oanbieder-model. In konsuminte-app kin it oanbiedermodel brûke, dus in produktnamme mei personal klassifisearret it net.
Apple dokumintearret ien tastiene kombinaasje, en tastimming seit net dat de profilen fan twa leveransiers kompatibel binne, dus freegje elke leveransier hokker pear stipe wurdt. Harren konfiguraasjetypen, rûtes en belied beslisse noch altyd it resultaat.
Myt: de persoanlike VPN krijt it browsetraffyk
In wurkprofyl dat elke bestimming opeasket, sil it rûtesykjen ek foar iepenbier browsen winne, dus de persoanlike útgean draacht dêr neat fan. Neffens de dokumintearre foarrang winne de bedriuwsrûtes wêr’t se konfliktje, dus iepenbier browsen nimt net automatysk de persoanlike útgean allinich om't dy app ek ferbûn meldt. In lytser wurkprofyl kin it routingbyld feroarje, mar de kliïnt fan de organisaasje kin noch altyd DNS-, blokkear- of apparaatseasken opleine. Krij de stipe regeling fan syn eigner ynstee fan dy easken lokaal te bewurkjen.
Behearde konfiguraasjes per app hawwe har eigen berik. Oerdraach in regel op apparaatnivo net nei elke behearde ynset.
Skriuw de twa streams op foar't jo teste: de priveenamme en it berik fan ’e wurksjinst, en in farsk iepenbier browsen-fersyk. Beide binne legit, en se hawwe ferskate kontrôles nedich.
Rûteprioriteit mei in wurkprofyl fan splitst tunnel
In wurkprofyl mei splitst tunnel opeasket de priveeprefiksen en it ynterne DNS-efterheaksel dat it listet, en dy rûtes winne elk sykjen dat dermei oerienkomt. Iepenbiere bestimmingen dy't by gjin bedriuwsrûte passe, falle troch nei de fysike keppeling, útsein as de persoanlike VPN se earst opeasket. De foarrangregel beslist allinne de oerlaapjende oerienkomsten, dêrom moatte de twa profilen as rûtetabellen lêzen wurde, net as byldsjes.
Skriuw it pear as twa rigels en neam de ferwachte winner foar elk: in wurkhostnamme dy't nei 10.x of 172.16.x oplost, moat troch de bedriuwstunnel nei bûten gean, en in iepenbier adres sûnder passende prefiks moat de oerbleaune standertrûte nimme. As beide rigels deselde útgean neame, docht de splitsing net wat de dokumintaasje beskriuwt.
Skriuw twa streams op en test elk
Foar elke stream, skriuw op hokker goedkarde konfiguraasje it drage moat en hokker resolver elk soarte namme krije moat. Ferifiearje dan mei farske fersiken, net mei in cachet wurkblêd of in âld IP-resultaat.
Stop ien konfiguraasje en werhelje beide streams. It flatergedrach is diel fan it ûntwerp, en it is it diel dat brûkers fernimme. As de twa oanbieders de kombinaasje net stypje kinne, kies dan ien goedkarde konfiguraasje en dokumintearje hokker stream it draacht, of gean oer op in beheard ûntwerp mei ien tunnel. NETunnelProviderManager-dokumintaasje is de boarne foar de mienskipregel.