Två iPhone-VPN:er samtidigt: vilken bär din trafik?

Två VPN-appar visar båda Connected, och antagandet är att trafiken nu går genom båda, den ena inuti den andra. Vanligtvis är det inte så. iOS har en specifik samexistensmodell, och den är inte en kedja. En konfigurationsklass är begränsad till en enda aktiverad instans, den andra kan köra bredvid, och rutprioritet avgör konflikter. Två påslagna reglage är inte två hopp. Modellen är dokumenterad, vilket innebär att vägen kan förutsägas i stället för gissas utifrån ikonerna.

Myt: två anslutna VPN:er är en kedja

En kedja med två hopp kräver en definierad yttre transport, en definierad inre tunnel, kompatibel endpoint-routing och en plan för vad som händer när någon av dem misslyckas. Två oberoende konfigurationer skapar inte det bara genom att finnas samtidigt. Rutprioritet är inte samma sak som inkapsling, och att en konfiguration vinner en rutsökning säger inget om huruvida den andra bär de resulterande paketen.

Om du behöver nästling ska du designa den som nästling. Härled det inte från två anslutningsindikatorer. Den skillnaden sparar mycket felsökning.

Den dokumenterade modellen bakom den myten

Apples NETunnelProviderManager beskriver vanliga företags-VPN-konfigurationer och säger att bara en av den typen kan aktiveras åt gången. Samma referens tillåter en Personal VPN att förbli aktiverad och ansluten bredvid, och ger företagsrutterna företräde där de två överlappar.

Personal VPN är här API-term för den inbyggda IPsec- eller IKEv2-implementeringen som hanteras via NEVPNManager. NETunnelProviderManager är tunnelleverantörsmodellen. En konsumentapp kan använda leverantörsmodellen, så ett produktnamn som innehåller personal klassificerar den inte.

Apple dokumenterar en tillåten kombination, och tillståndet säger inte att två leverantörers profiler är kompatibla, så fråga varje leverantör vilket par som stöds. Deras konfigurationstyper, rutter och policyer avgör fortfarande resultatet.

Myt: den personliga VPN:en får surfningstrafiken

En arbetsprofil som gör anspråk på varje destination vinner rutsökningen även för offentligt surfande, så den personliga utgången bär inget av det. Enligt den dokumenterade företrädesrätten vinner företagsrutterna där de krockar, så offentligt surfande tar inte automatiskt den personliga utgången bara för att den appen också rapporterar anslutet. En snävare arbetskonfiguration kan ändra routingbilden, men organisationens klient kan fortfarande införa DNS-, blockerings- eller enhetskrav. Få den stödda ordningen från ägaren i stället för att redigera dessa krav lokalt.

Hanterade konfigurationer per app har sin egen omfattning. Generalisera inte en regel på enhetsnivå till varje hanterad utrullning.

Skriv ned de två flödena före testet: arbetstjänstens privata namn och område, och en färsk offentlig surfbegäran. Båda är legitima, och de behöver olika kontroller.

Rutprioritet med en arbetsprofil med delad tunnel

En arbetsprofil med delad tunnel gör anspråk på de privata prefixen och det interna DNS-suffixet som den listar, och dessa rutter vinner varje sökning som matchar dem. Offentliga destinationer som inte matchar någon företagsrutt faller igenom till den fysiska länken om inte den personliga VPN:en gör anspråk på dem först. Företrädesregeln avgör bara de överlappande träffarna, och därför måste de två profilerna läsas som rutttabeller och inte som ikoner.

Skriv paret som två rader och namnge den förväntade vinnaren för varje: ett arbetsvärdnamn som löses till 10.x eller 172.16.x bör gå ut genom företagstunneln, och en offentlig adress utan matchande prefix bör ta den återstående standardrutten. Om båda raderna namnger samma utgång gör uppdelningen inte det som dokumentationen beskriver.

Skriv ned två flöden och testa varje

För varje flöde, notera vilken godkänd konfiguration som ska bära det och vilken resolver som ska ta emot varje typ av namn. Verifiera sedan med färska begäranden, inte med en cachad arbetssida eller ett gammalt IP-resultat.

Stoppa en konfiguration och upprepa båda flödena. Felbeteendet är en del av designen, och det är den del användarna lägger märke till. När de två leverantörerna inte kan stödja kombinationen, välj en godkänd konfiguration och dokumentera vilket flöde den bär, eller byt till en hanterad design med en enda tunnel. NETunnelProviderManager-dokumentationen är källan till samexistensregeln.