To iPhone-VPN-er samtidig: hvilken bærer trafikken din?

To VPN-apper viser begge Connected, og antakelsen er at trafikken nå går gjennom begge, den ene inne i den andre. Som regel gjør den ikke det. iOS har en bestemt sameksistensmodell, og den er ikke en kjede. Én konfigurasjonsklasse er begrenset til én aktivert instans, den andre kan kjøre ved siden av, og ruteprioritet avgjør konflikter. To påslåtte brytere er ikke to hopp. Modellen er dokumentert, noe som betyr at veien kan forutsies i stedet for gjettes ut fra ikonene.

Myte: to tilkoblede VPN-er er en kjede

En kjede med to hopp krever en definert ytre transport, en definert indre tunnel, kompatibel endepunktsruting og en plan for hva som skjer når en av dem svikter. To uavhengige konfigurasjoner skaper ikke dette bare ved å eksistere samtidig. Ruteprioritet er ikke det samme som innkapsling, og at én konfigurasjon vinner et ruteoppslag sier ingenting om hvorvidt den andre bærer pakkene som følger.

Hvis du trenger nesting, design det som nesting. Ikke utled det fra to tilkoblingsindikatorer. Den forskjellen sparer mye feilsøking.

Den dokumenterte modellen bak myten

Apples NETunnelProviderManager beskriver vanlige bedrifts-VPN-konfigurasjoner og slår fast at bare én av den typen kan være aktivert om gangen. Samme referanse tillater en Personal VPN å forbli aktivert og tilkoblet ved siden av, og gir bedriftsrutene forrang der de to overlapper.

Personal VPN er her API-begrepet for den innebygde IPsec- eller IKEv2-implementasjonen som administreres via NEVPNManager. NETunnelProviderManager er tunnelleverandørmodellen. En forbrukerapp kan bruke leverandørmodellen, så et produktnavn som inneholder personal klassifiserer den ikke.

Apple dokumenterer én tillatt kombinasjon, og tillatelsen forteller deg ikke at to leverandørers profiler er kompatible, så spør hver leverandør hvilket par som støttes. Deres konfigurasjonstyper, ruter og policyer avgjør fortsatt resultatet.

Myte: den personlige VPN-en får nettlesertrafikken

En arbeidsprofil som krever alle destinasjoner vil vinne ruteoppslaget også for offentlig surfing, så den personlige utgangen bærer ingenting av det. Under den dokumenterte forrangen vinner bedriftsrutene der de kolliderer, så offentlig surfing tar ikke automatisk den personlige utgangen bare fordi den appen også rapporterer tilkoblet. En smalere arbeidskonfigurasjon kan endre rutebildet, men organisasjonens klient kan fortsatt pålegge DNS-, blokkerings- eller enhetskrav. Få den støttede ordningen fra eieren i stedet for å redigere disse kravene lokalt.

Administrerte konfigurasjoner per app har sitt eget omfang. Ikke generaliser en regel på enhetsnivå til hver administrert utrulling.

Skriv ned de to strømmene før du tester: arbeidstjenestens private navn og område, og en fersk offentlig surfeforespørsel. Begge er legitime, og de trenger ulike kontroller.

Ruteprioritet med en arbeidsprofil med delt tunnel

En arbeidsprofil med delt tunnel krever de private prefiksene og det interne DNS-suffikset den lister opp, og disse rutene vinner ethvert oppslag som passer med dem. Offentlige destinasjoner som ikke passer med noen bedriftsrute faller til den fysiske lenken med mindre den personlige VPN-en krever dem først. Forrangsregelen avgjør bare de overlappende treffene, og derfor må de to profilene leses som rutetabeller og ikke som ikoner.

Skriv paret som to linjer og navngi den forventede vinneren for hver: et arbeidsvertsnavn som løses til 10.x eller 172.16.x bør gå ut gjennom bedriftstunnelen, og en offentlig adresse uten samsvarende prefiks bør ta den gjenværende standardruten. Hvis begge linjene navngir samme utgang, gjør delingen ikke det dokumentasjonen beskriver.

Skriv ned to strømmer og test hver

For hver strøm, noter hvilken godkjent konfigurasjon som skal bære den og hvilken resolver som skal motta hver type navn. Bekreft deretter med ferske forespørsler, ikke med en bufret arbeidsside eller et gammelt IP-resultat.

Stopp én konfigurasjon og gjenta begge strømmene. Feilatferden er en del av designet, og det er den delen brukerne legger merke til. Når de to leverandørene ikke kan støtte kombinasjonen, velg én godkjent konfigurasjon og dokumenter hvilken strøm den bærer, eller gå over til et administrert design med én tunnel. NETunnelProviderManager-dokumentasjonen er kilden til sameksistensregelen.