To iPhone-VPN'er på én gang: hvilken bærer din trafik?

To VPN-apps viser begge Connected, og antagelsen er, at trafikken nu går gennem begge, den ene inde i den anden. Det gør den som regel ikke. iOS har en bestemt sameksistensmodel, og den er ikke en kæde. Én konfigurationsklasse er begrænset til én aktiveret instans, den anden kan køre ved siden af, og ruteprioritet afgør konflikter. To tændte kontakter er ikke to hop. Modellen er dokumenteret, hvilket betyder, at stien kan forudsiges i stedet for gættes ud fra ikonerne.

Myte: to forbundne VPN'er er en kæde

En kæde med to hop kræver en defineret ydre transport, en defineret indre tunnel, kompatibel endpoint-routing og en plan for, hvad der sker, når en af dem fejler. To uafhængige konfigurationer skaber ikke det ved blot at eksistere samtidig. Ruteprioritet er ikke det samme som indkapsling, og at én konfiguration vinder et ruteopslag siger intet om, hvorvidt den anden bærer de resulterende pakker.

Hvis du har brug for indlejring, så design den som indlejring. Udled den ikke af to forbindelsesindikatorer. Den forskel sparer meget fejlfinding.

Den dokumenterede model bag den myte

Apples NETunnelProviderManager beskriver almindelige virksomheds-VPN-konfigurationer og fastslår, at kun én af den slags kan aktiveres ad gangen. Den samme reference tillader en Personal VPN at forblive aktiveret og forbundet ved siden af, og giver virksomhedsruterne forrang, hvor de to overlapper.

Personal VPN er her API-betegnelsen for den indbyggede IPsec- eller IKEv2-implementering, der styres via NEVPNManager. NETunnelProviderManager er tunneludbyder-modellen. En forbrugerapp kan bruge udbydermodellen, så et produktnavn, der indeholder personal, klassificerer den ikke.

Apple dokumenterer én tilladt kombination, og tilladelsen fortæller dig ikke, at to leverandørers profiler er kompatible, så spørg hver leverandør, hvilket par der understøttes. Deres konfigurationstyper, ruter og politikker afgør stadig resultatet.

Myte: den personlige VPN får browsingtrafikken

En arbejdsprofil, der gør krav på enhver destination, vinder også ruteopslaget for offentlig browsing, så den personlige udgang bærer intet af det. Under den dokumenterede forrang vinder virksomhedsruterne, hvor de støder sammen, så offentlig browsing tager ikke automatisk den personlige udgang, blot fordi den app også rapporterer forbundet. En snævrere arbejdskonfiguration kan ændre routingbilledet, men organisationens klient kan stadig pålægge DNS-, blokerings- eller enhedskrav. Få den understøttede ordning fra dens ejer i stedet for at redigere de krav lokalt.

Styrede konfigurationer for hver app har deres eget omfang. Ekstrapolér ikke en regel på enhedsniveau til enhver styret udrulning.

Skriv de to strømme ned, før du tester: arbejdstjenestens private navn og område samt en frisk offentlig browsinganmodning. Begge er legitime, og de kræver forskellige kontroller.

Ruteprioritet med en arbejdsprofil med delt tunnel

En arbejdsprofil med delt tunnel gør krav på de private præfikser og det interne DNS-suffiks, den angiver, og disse ruter vinder ethvert opslag, der matcher dem. Offentlige destinationer, der ikke matcher nogen virksomhedsrute, falder igennem til det fysiske link, medmindre den personlige VPN gør krav på dem først. Forrangsreglen afgør kun de overlappende match, og derfor skal de to profiler læses som rutetabeller og ikke som ikoner.

Skriv parret som to linjer, og navngiv den forventede vinder for hver: et arbejdsværtsnavn, der opløses til 10.x eller 172.16.x, bør gå ud gennem virksomhedstunnelen, og en offentlig adresse uden matchende præfiks bør tage den resterende standardrute. Hvis begge linjer navngiver den samme udgang, gør opdelingen ikke det, dokumentationen beskriver.

Skriv to strømme ned, og test hver

For hver strøm skal du notere, hvilken godkendt konfiguration der skal bære den, og hvilken resolver der skal modtage hver slags navn. Bekræft derefter med friske anmodninger, ikke med en cachet arbejdsside eller et gammelt IP-resultat.

Stop én konfiguration, og gentag begge strømme. Fejladfærden er en del af designet, og det er den del, brugerne bemærker. Når de to udbydere ikke kan understøtte kombinationen, så vælg én godkendt konfiguration og dokumentér, hvilken strøm den bærer, eller skift til et styret design med én tunnel. NETunnelProviderManager-dokumentationen er kilden til sameksistensreglen.