Per-app-VPN på hanterade iPhone-appar: vad som dirigeras och vad som inte gör det
En per-app-tunnel följer den hanterade appen, inte telefonen. Kontrollera payload-kopplingen, den hanterade kopian, reglerna på begäran och flödena som lämnar appen.
Per-app-VPN på iPhone är inte en strömbrytare för hela telefonen. Det är en koppling mellan en hanterad app och en VPN-payload, skapad när appen distribueras, och trafiken för allt annat behåller den väg den hade. Därför beter sig samma telefon inkonsekvent: arbetsappen öppnar en privat sida medan Safari inte når samma värd, eller så kommer tunneln inte upp alls och appen rapporterar en timeout som ser ut som fel inloggningsuppgifter. Kontrollerna går från den bredaste orsaken och nedåt, så stanna vid den första som fallerar.
Kontrollera payloaden och app-posten först
Kopplingen lever i två objekt, inte ett. VPN-payloaden definierar tunneln: typ, server, autentisering, DNS och leverantörens bundle-ID när en anpassad klient används. App-posten pekar på den payloaden, och de flesta hanteringskonsoler erbjuder detta som ett per-app-alternativ i appkonfigurationen, med ett namn nära Per-App VPN. En payload som ingen app pekar på dirigerar ingenting per app; den beter sig som en vanlig tunnel som någon måste starta manuellt.
Läs båda objekten innan du rör telefonen. Bekräfta att appkonfigurationen pekar på payloaden du testar och inte på en äldre kopia, eftersom dubblerade payloads med nästan samma namn är vanliga efter migrering och appen pekar gärna på den som dragits tillbaka. Bekräfta sedan att konfigurationen nått enheten: Inställningar, Allmänt, VPN och enhetshantering måste visa den som en installerad profil. VPN-listan där är inte testet. En per-app-tjänst har vanligtvis ingen manuell strömbrytare, så en korrekt distribuerad konfiguration kanske aldrig syns bland de VPN som kan startas. Frånvaron syns i app-posten och i om tunneln kommer upp vid appens första begäran.
Ett villkor förklarar många ärenden: den här modellen kräver att appen kommer via hantering. En kopia som installerats vid sidan om eller köpts privat får inte kopplingen, även när dess bundle-ID stämmer. Apples distributionsguide för VPN beskriver payloadmodellen bakom detta (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Bekräfta att den installerade appen är den hanterade kopian
Kopplingen följer den installerade, hanterade appen. Om någon installerade om den från App Store med ett personligt Apple ID, bytte ut den mot en ny-signerad företagsbuild, eller enheten registrerades om och appen kom tillbaka via en annan kanal, kan tunneln ligga nere medan appen själv ser helt normal ut.
Testa genom jämförelse, inte en enda observation. I hanteringsinventariet ska appen visas som hanterad för den enheten med VPN-mappningen i posten. På telefonen ska tunneln komma upp när appen startas och dess första begäran går ut, inte bara när någon startar en separat manuell konfiguration i Inställningar. Om start av appen inte ändrar något och den manuella konfigurationen gör det, är appen inte alls bunden till en per-app-tunnel.
Uppdateringar spelar roll: den som skickas via hantering behåller mappningen, medan en ominstallation som användaren startar kan förlora den. När klagomålet dateras från en uppdatering, kontrollera app-posten före nätverket.
Kontrollera vad tunneln får ta
En per-app-tunnel väljs av källappen, så telefonens standardväg tillhör fortfarande Wi-Fi eller mobilnätet. OverridePrimary är nyckeln som ändrar detta. När en profil sätter den beter sig tunneln som en full tunnel och varje app ärver den, så allt som går via VPN blir en profilfråga och inte ett appfel.
Reglerna på begäran avgör varaktigheten. OnDemandEnabled och dess regeluppsättning gör att tunneln kommer tillbaka när appen skickar trafik, överlever bytet från Wi-Fi till mobilnät eller faller när appen går i bakgrunden. En distribution som ansluter och sedan dör tyst har vanligtvis en regel som bara matchar en sond som aldrig utlöses medan appen är inaktiv.
Läs sedan rutsidan ärligt. Om leverantörens eller återförsäljarens profil ger en inkluderingslista kommer en tunnel som bara bär 10.20.0.0/16 inte att bära tjänst i 10.30.0.0/16; det är listan som gör sitt jobb, inte ett per-app-fel. Den inbyggda iOS-payloaden har ingen inkluderingslista. Utan den följer uppdelningen leverantörens standardvärden och IncludeAllNetworks, inte en dold lista.
Testa appen och testa sedan det som lämnar den
Testa med namn, inte bara med adress. Att lösa en intern värd inne i den hanterade appen bevisar att även DNS gick genom tunneln, eftersom payloaden bestämmer vilken resolver som svarar och vilka sökdomäner som gäller. Routingen kan vara perfekt medan namnsökningen misslyckas, och de två symptomen pekar på olika inställningar.
Testa sedan gränsen från båda håll. En personlig app eller Safari bör nå en vanlig offentlig sida och rapportera operatörens eller hemmets adress, medan den hanterade appen når den privata tjänsten. Om båda rapporterar samma offentliga adress är tunneln inte längre per app, vad app-posten än säger.
Flöden som lämnar appen skapar förvirrande ärenden. En länk som öppnas i Safari, ett dokument som skickas via delningsarket eller en SSO-inloggning som går över till en webbläsare lämnar appens process och tunneln med den. En inloggning som visas inne i appen tillskrivs vanligtvis appen, så inbäddad inloggning kan lyckas där samma URL misslyckas i Safari; verifiera det i stället för att anta det. När identitetsleverantören bara nås via tunneln, håll inloggningen inne i appen eller lägg leverantörens domän till payloadens Safari-domäner så att matchande Safari-trafik fångas.
Koppla symptomet till lagret
Felets form berättar vilken kontroll som ska upprepas.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
Bakom de mellersta raderna står två detaljer: en per-app-tunnel kan vara frisk och ändå missa ett subnät som ingen leverantörslista innehåller, och en hanterad telefon kan hålla mer än en VPN-konfiguration, så bekräfta vilken appen är bunden till i stället för att anta att det är den du läser.
Rätta i denna ordning: rikta app-posten mot den aktiva payloaden, installera om appen via hantering, bekräfta att tunneln kommer upp vid appens första begäran och upprepa sedan namn- och gränstesterna. Om den första begäran inte alls kan starta någon tunnel, stanna och kontrollera leverantörssidan, eftersom en anpassad klient behöver Network Extension närvarande och en identifikator som matchar den installerade appen.
Returnera tre fakta i stället för en skärmbild: vilken payload app-posten pekar på, om Inställningar visar den som en installerad profil och vad den misslyckade begäran var — ett namn, en adress eller en överlämning till webbläsaren. Dessa tre svar skiljer ett distributionsfel från ett routingfel, och nästa person kan agera utan att upprepa diagnosen.