Per-app-VPN op beheerde iPhone-apps: wat wordt gerouteerd en wat niet
Een per-app-tunnel volgt de beheerde app, niet de telefoon. Controleer de payload-koppeling, de beheerde kopie, de regels op aanvraag en de stromen die de app verlaten.
Per-app-VPN op iPhone is geen schakelaar voor de hele telefoon. Het is een koppeling tussen één beheerde app en één VPN-payload, gemaakt wanneer de app wordt uitgerold, en het verkeer van al het andere houdt de route die het had. Daarom gedraagt dezelfde telefoon zich inconsistent: de werkapp opent een privépagina terwijl Safari dezelfde host niet bereikt, of de tunnel komt helemaal niet omhoog en de app meldt een time-out die op verkeerde inloggegevens lijkt. De controles lopen van de breedste oorzaak naar beneden, dus stop bij de eerste die faalt.
Controleer eerst de payload en het app-record
De koppeling leeft in twee objecten, niet in één. De VPN-payload definieert de tunnel: type, server, authenticatie, DNS en de bundle-ID van de provider wanneer een aangepaste client wordt gebruikt. Het app-record wijst naar die payload, en de meeste beheerconsoles bieden dit als per-app-optie in de app-configuratie, met een naam dicht bij Per-App VPN. Een payload waar geen enkele app naar wijst routeert niets per app; hij gedraagt zich als een gewone tunnel die iemand handmatig moet starten.
Lees beide objecten voordat je de telefoon aanraakt. Bevestig dat de app-configuratie naar de payload wijst die je test en niet naar een oudere kopie, want dubbele payloads met bijna dezelfde naam komen vaak voor na een migratie en de app wijst graag naar de ingetrokken versie. Bevestig daarna dat de configuratie het apparaat heeft bereikt: Instellingen, Algemeen, VPN en Apparaatbeheer moeten hem als geïnstalleerd profiel tonen. De VPN-lijst daar is niet de test. Een per-app-dienst heeft meestal geen handmatige schakelaar, dus een correct uitgerolde configuratie verschijnt mogelijk nooit tussen de VPN's die je kunt starten. De afwezigheid is te zien in het app-record en in of de tunnel omhoogkomt bij het eerste verzoek van de app.
Eén voorwaarde verklaart veel tickets: dit model vereist dat de app via beheer binnenkomt. Een los geïnstalleerde of persoonlijk gekochte kopie krijgt de koppeling niet, zelfs niet als de bundle-ID overeenkomt. Apple's implementatiehandleiding voor VPN beschrijft het payloadmodel erachter (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Bevestig dat de geïnstalleerde app de beheerde kopie is
De koppeling volgt de geïnstalleerde, beheerde app. Als iemand hem opnieuw uit de App Store heeft geïnstalleerd met een persoonlijk Apple ID, heeft vervangen door een opnieuw ondertekende bedrijfsbuild, of het apparaat opnieuw is ingeschreven en de app via een ander kanaal terugkwam, kan de tunnel omlaag blijven terwijl de app zelf volkomen normaal lijkt.
Test door vergelijking, niet met één observatie. In de beheerinventaris moet de app als beheerd voor dat apparaat staan, met de VPN-koppeling in het record. Op de telefoon moet de tunnel omhoogkomen wanneer de app start en het eerste verzoek uitgaat, niet alleen wanneer iemand in Instellingen een aparte handmatige configuratie start. Als het starten van de app niets verandert en die handmatige configuratie wel, is de app helemaal niet aan een per-app-tunnel gebonden.
Updates zijn belangrijk: een via beheer gepushte update behoudt de koppeling, terwijl een door de gebruiker gestarte herinstallatie die kan verliezen. Als de klacht bij een update begint, controleer dan het app-record voordat je naar het netwerk kijkt.
Controleer wat de tunnel mag meenemen
Een per-app-tunnel wordt gekozen op basis van de bronapp, dus de standaardroute van de telefoon hoort nog steeds bij Wi-Fi of mobiel. OverridePrimary is de sleutel die dat verandert. Als een profiel die instelt, gedraagt de tunnel zich als een volledige tunnel en erft elke app hem, dus alles wat via de VPN gaat wordt een profielvraag en geen appstoring.
Regels op aanvraag bepalen de persistentie. OnDemandEnabled en de bijbehorende regelset zorgen dat de tunnel terugkomt wanneer de app verkeer stuurt, overleeft hij de overgang van Wi-Fi naar mobiel, of valt hij weg wanneer de app naar de achtergrond gaat. Een uitrol die verbindt en daarna stil sterft heeft meestal een regel die alleen past bij een probe die nooit afgaat terwijl de app inactief is.
Lees daarna de routenkant eerlijk. Als een provider- of leveranciersprofiel een includelijst geeft, zal een tunnel die alleen 10.20.0.0/16 draagt geen dienst in 10.30.0.0/16 dragen; dat is de lijst die zijn werk doet, geen per-app-fout. De ingebouwde iOS-payload heeft geen includelijst. Zonder lijst volgt de splitsing de standaardwaarden van de provider en IncludeAllNetworks, niet een verborgen lijst.
Test de app en test daarna wat eruit komt
Test met een naam, niet alleen met een adres. Een interne host oplossen binnen de beheerde app bewijst dat ook DNS door de tunnel ging, omdat de payload bepaalt welke resolver antwoordt en welke zoekdomeinen gelden. Routering kan perfect zijn terwijl naamresolutie faalt, en de twee symptomen wijzen op verschillende instellingen.
Test daarna de grens van beide kanten. Een persoonlijke app of Safari moet een gewone openbare pagina bereiken en het adres van de provider of thuis melden, terwijl de beheerde app de privédienst bereikt. Als beide hetzelfde openbare adres melden, is de tunnel niet langer per app, wat het app-record ook beweert.
Stromen die de app verlaten zorgen voor verwarrende tickets. Een link die in Safari opent, een document dat via het deelblad wordt doorgegeven of een SSO-login die naar een browser overgaat, verlaten het proces van de app en daarmee de tunnel. Een login die in de app wordt getoond, wordt meestal aan de app toegeschreven, dus een ingebouwde login kan slagen waar dezelfde URL in Safari faalt; verifieer dat in plaats van het aan te nemen. Als de identiteitsprovider alleen via de tunnel bereikbaar is, houd de login dan in de app of voeg het domein van de provider toe aan de Safari-domeinen van de payload, zodat overeenkomend Safari-verkeer wordt opgevangen.
Koppel het symptoom aan de laag
De vorm van de storing vertelt welke controle je moet herhalen.
| 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 |
Achter de middelste regels staan twee details: een per-app-tunnel kan gezond zijn en toch een subnet missen dat in geen enkele providerlijst staat, en een beheerde telefoon kan meer dan één VPN-configuratie bevatten, dus bevestig waaraan de app is gebonden in plaats van aan te nemen dat het de configuratie is die je leest.
Los het in deze volgorde op: wijs het app-record naar de actieve payload, herinstalleer de app via beheer, bevestig dat de tunnel omhoogkomt bij het eerste verzoek van de app en herhaal daarna de naam- en grenstests. Als het eerste verzoek helemaal geen tunnel kan starten, stop dan en controleer de providerkant, want een aangepaste client heeft een bestaande Network Extension en een ID die overeenkomt met de geïnstalleerde app nodig.
Geef drie feiten terug in plaats van een screenshot: naar welke payload het app-record wijst, of Instellingen hem als geïnstalleerd profiel toont, en wat het mislukte verzoek was — een naam, een adres of een overdracht naar de browser. Die drie antwoorden scheiden een uitrolfout van een routeringsfout, en de volgende persoon kan handelen zonder de diagnose te herhalen.