Twee iPhone-VPN's gelyktydig: watter een dra jou verkeer?

Twee VPN-toepassings wys albei Connected, en die aanname is dat die verkeer nou deur albei loop, die een binne die ander. Dit gebeur gewoonlik nie. iOS het 'n spesifieke naasbestaanmodel, en dit is nie 'n ketting nie. Een konfigurasieklas is tot 'n enkele geaktiveerde instansie beperk, die ander kan daarlangs loop, en roeteprioriteit beslis konflikte. Twee brandende skakelaars is nie twee spronge nie. Die model is gedokumenteer, wat beteken die pad kan voorspel word eerder as uit die ikone geraai.

Mite: twee gekoppelde VPN's is 'n ketting

'n Twee-sprong-ketting benodig 'n bepaalde buitenste vervoer, 'n bepaalde binneste tonnel, versoenbare eindpuntroetering en 'n plan vir wat gebeur wanneer een van die twee faal. Twee onafhanklike konfigurasies skep dit nie bloot deur gelyktydig te bestaan nie. Roeteprioriteit is nie dieselfde as inkapseling nie, en dat een konfigurasie 'n roetesoektog wen, sê niks oor of die ander die gevolglike pakkette dra nie.

As jy nesting nodig het, ontwerp dit as nesting. Moenie dit uit twee verbindingsaanwysers aflei nie. Daardie onderskeid spaar baie ontfouting.

Die gedokumenteerde model agter daardie mite

Apple se NETunnelProviderManager beskryf gewone ondernemings-VPN-konfigurasies en sê dat net een van daardie soort op 'n slag geaktiveer kan wees. Dieselfde verwysing laat 'n Personal VPN toe om daarlangs geaktiveer en gekoppel te bly, en gee die ondernemingsroetes voorrang waar die twee oorvleuel.

Personal VPN is hier die API-term vir die ingeboude IPsec- of IKEv2-implementering wat deur NEVPNManager bestuur word. NETunnelProviderManager is die tonnelverskaffermodel. 'n Verbruikerstoepassing kan die verskaffermodel gebruik, so 'n produknaam wat personal bevat, klassifiseer dit nie.

Apple dokumenteer een toegelate kombinasie, en toestemming sê nie vir jou dat twee verskaffers se profiele versoenbaar is nie, so vra elke verskaffer watter paar ondersteun word. Hulle konfigurasietipes, roetes en beleide beslis steeds die uitslag.

Mite: die persoonlike VPN kry die blaai-verkeer

'n Werkprofiel wat elke bestemming opeis, sal ook die roetesoektog vir openbare blaai wen, so die persoonlike uitgang dra niks daarvan nie. Volgens die gedokumenteerde voorrang wen die ondernemingsroetes waar hulle bots, so openbare blaai neem nie outomaties die persoonlike uitgang net omdat daardie toepassing ook gekoppeld rapporteer nie. 'n Nouer werkkonfigurasie kan die roeteringsprent verander, maar die organisasie se kliënt kan steeds DNS-, blokkerings- of toestelvereistes oplê. Kry die ondersteunde reëling by sy eienaar eerder as om daardie vereistes plaaslik te wysig.

Bestuurde per-toepassing-konfigurasies het hulle eie omvang. Moenie 'n toestelvlakreël na elke bestuurde ontplooiing ekstrapoleer nie.

Skryf die twee vloei neer voordat jy toets: die werksdiens se private naam en reeks, en 'n vars openbare blaai-versoek. Albei is geldig, en hulle het verskillende kontroles nodig.

Roeteprioriteit met 'n split-tonnel-werkprofiel

'n Split-tonnel-werkprofiel eis die private prefikse en die interne DNS-agtervoegsel wat dit lys, en daardie roetes wen enige soektog wat by hulle pas. Openbare bestemmings wat aan geen ondernemingsroete pas nie, val deur na die fisiese skakel tensy die persoonlike VPN hulle eerste opeis. Die voorrangreël beslis net die oorvleuelende treffers, daarom moet die twee profiele as roetetablelle gelees word eerder as as ikone.

Skryf die paar as twee lyne neer en noem die verwagte wenner vir elkeen: 'n werkhosnaam wat na 10.x of 172.16.x oplos, moet deur die ondernemingstonnel uitgaan, en 'n openbare adres met geen passende prefiks moet die oorblywende verstekroete neem. As albei lyne dieselfde uitgang noem, doen die splitsing nie wat die dokumentasie beskryf nie.

Skryf twee vloei neer en toets elkeen

Vir elke vloei, teken aan watter goedgekeurde konfigurasie dit moet dra en watter oplosser elke soort naam moet ontvang. Verifieer dan met vars versoeke, nie met 'n gekasde werkblad of 'n ou IP-uitslag nie.

Stop een konfigurasie en herhaal albei vloei. Die falinggedrag is deel van die ontwerp, en dit is die deel wat gebruikers raaksien. Wanneer die twee verskaffers die kombinasie nie kan ondersteun nie, besluit op een goedgekeurde konfigurasie en dokumenteer watter vloei dit dra, of skuif na 'n bestuurde enkeltonnel-ontwerp. Die NETunnelProviderManager-dokumentasie is die bron vir die naasbestaanreël.