To iPhone-VPN-ar samtidig: kven ber trafikken din?

To VPN-appar viser begge Connected, og føresetnaden er at trafikken no går gjennom begge, den eine inne i den andre. Som regel gjer han ikkje det. iOS har ein bestemt samverknadsmodell, og han er ikkje ei kjede. Éin konfigurasjonsklasse er avgrensa til éin aktivert instans, den andre kan køyre ved sida av, og ruteprioritet avgjer konfliktar. To påslåtte brytarar er ikkje to hopp. Modellen er dokumentert, noko som tyder at vegen kan føreseiast i staden for å gjetast ut frå ikona.

Myte: to tilkopla VPN-ar er ei kjede

Ei kjede med to hopp krev ein definert ytre transport, ein definert indre tunnel, kompatibel endepunktsruting og ein plan for kva som skjer når ein av dei sviktar. To uavhengige konfigurasjonar skapar ikkje dette berre ved å eksistere samstundes. Ruteprioritet er ikkje det same som innkapsling, og at éin konfigurasjon vinn eit ruteoppslag seier ingenting om korvidt den andre ber pakkane som følgjer.

Treng du nesting, design det som nesting. Ikkje leid det ut frå to tilkoplingindikatorar. Den skilnaden sparer mykje feilsøking.

Den dokumenterte modellen bak myten

Apples NETunnelProviderManager skildrar vanlege bedrifts-VPN-konfigurasjonar og slår fast at berre éin av den typen kan vere aktivert om gongen. Same referanse lèt ein Personal VPN halde fram som aktivert og tilkopla ved sida av, og gjev bedriftsrutene førerett der dei to overlappar.

Personal VPN er her API-omgrepet for den innebygde IPsec- eller IKEv2-implementasjonen som blir administrert via NEVPNManager. NETunnelProviderManager er tunnelleverandørmodellen. Ein forbrukarapp kan bruke leverandørmodellen, så eit produktnamn som inneheld personal klassifiserer han ikkje.

Apple dokumenterer éin tillaten kombinasjon, og løyvet fortel deg ikkje at profilane til to leverandørar er kompatible, så spør kvar leverandør kva par som er støtta. Konfigurasjonstypane, rutene og retningslinjene deira avgjer framleis resultatet.

Myte: den personlege VPN-en får nettlesartrafikken

Ein arbeidsprofil som krev alle destinasjonar vil vinne ruteoppslaget også for offentleg surfing, så den personlege utgangen ber ingenting av det. Under den dokumenterte føreretten vinn bedriftsrutene der dei kolliderer, så offentleg surfing tek ikkje automatisk den personlege utgangen berre fordi den appen også rapporterer tilkopla. Ein smalare arbeidskonfigurasjon kan endre rutebiletet, men klienten til organisasjonen kan framleis påleggje DNS-, blokkerings- eller einingkrav. Få den støtta ordninga frå eigaren i staden for å redigere desse krava lokalt.

Administrerte konfigurasjonar per app har sitt eige omfang. Ikkje generaliser ein regel på einingnivå til kvar administrert utrulling.

Skriv ned dei to straumane før du testar: det private namnet og området til arbeidstenesta, og ein fersk offentleg surfeførespurnad. Begge er legitime, og dei treng ulike kontrollar.

Ruteprioritet med ein arbeidsprofil med delt tunnel

Ein arbeidsprofil med delt tunnel krev dei private prefiksa og det interne DNS-suffikset han listar opp, og desse rutene vinn kvart oppslag som passar med dei. Offentlege destinasjonar som ikkje passar med noka bedriftsrute fell til den fysiske lenkja med mindre den personlege VPN-en krev dei først. Førerettsregelen avgjer berre dei overlappande treffa, og difor må dei to profilane lesast som rutetabellar og ikkje som ikon.

Skriv paret som to linjer og nemn den forventa vinnaren for kvar: eit arbeidsvertnamn som blir løyst til 10.x eller 172.16.x bør gå ut gjennom bedriftstunnelen, og ei offentleg adresse utan samsvarande prefiks bør ta den gjenverande standardruta. Viss begge linjene nemner same utgang, gjer delinga ikkje det dokumentasjonen skildrar.

Skriv ned to straumar og test kvar

For kvar straum, noter kva godkjend konfigurasjon som skal bere han og kva oppløysar som skal ta imot kvar type namn. Stadfest deretter med ferske førespurnader, ikkje med ei buftra arbeidsside eller eit gammalt IP-resultat.

Stopp éin konfigurasjon og gjenta begge straumane. Feilåtferda er ein del av designet, og det er den delen brukarane legg merke til. Når dei to leverandørane ikkje kan støtte kombinasjonen, vel éin godkjend konfigurasjon og dokumenter kva straum han ber, eller gå over til eit administrert design med éin tunnel. NETunnelProviderManager-dokumentasjonen er kjelda til samverknadsregelen.