Per-app-VPN på administrerte iPhone-apper: hva som rutes og hva som ikke
En per-app-tunnel følger den administrerte appen, ikke telefonen. Sjekk payload-tilknytningen, den administrerte kopien, reglene ved forespørsel og strømmene som forlater appen.
Per-app-VPN på iPhone er ikke en bryter for hele telefonen. Det er en tilknytning mellom én administrert app og én VPN-payload, opprettet når appen distribueres, og trafikken til alt annet beholder ruten den hadde. Derfor oppfører samme telefon seg inkonsekvent: jobbappen åpner en privat side mens Safari ikke når samme vert, eller tunnelen kommer ikke opp i det hele tatt og appen rapporterer en tidsavbrudd som ser ut som feil påloggingsinformasjon. Kontrollene går fra den bredeste årsaken og nedover, så stopp ved den første som feiler.
Sjekk payloaden og app-oppføringen først
Tilknytningen lever i to objekter, ikke ett. VPN-payloaden definerer tunnelen: type, server, autentisering, DNS og leverandørens bundle-ID når en tilpasset klient brukes. App-oppføringen peker på den payloaden, og de fleste administrasjonskonsoller tilbyr dette som et per-app-alternativ i appkonfigurasjonen, med et navn nær Per-App VPN. En payload som ingen app peker på ruter ingenting per app; den oppfører seg som en vanlig tunnel som noen må starte manuelt.
Les begge objektene før du berører telefonen. Bekreft at appkonfigurasjonen peker på payloaden du tester og ikke en eldre kopi av den, fordi dupliserte payloader med nesten samme navn er vanlige etter migrering, og appen peker gjerne på den som er trukket tilbake. Bekreft deretter at konfigurasjonen har nådd enheten: Innstillinger, Generelt, VPN og enhetsadministrasjon må vise den som en installert profil. VPN-listen der er ikke testen. En per-app-tjeneste har vanligvis ingen manuell bryter, så en riktig distribuert konfigurasjon vises kanskje aldri blant VPN-ene som kan startes. Fraværet ses i app-oppføringen og i om tunnelen kommer opp ved appens første forespørsel.
Én betingelse forklarer mange saker: denne modellen krever at appen kommer via administrasjon. En kopi som er installert sidelengs eller kjøpt privat får ikke tilknytningen, selv når bundle-ID-en stemmer. Apples distribusjonsveiledning for VPN beskriver payloadmodellen bak dette (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Bekreft at den installerte appen er den administrerte kopien
Tilknytningen følger den installerte, administrerte appen. Hvis noen installerte den på nytt fra App Store med en personlig Apple-ID, byttet den ut med en ny-signert bedriftsbuild, eller enheten ble registrert på nytt og appen kom tilbake via en annen kanal, kan tunnelen bli liggende nede mens appen selv ser helt normal ut.
Test ved sammenligning, ikke én observasjon. I administrasjonsinventaret skal appen vises som administrert for den enheten med VPN-mappingen i oppføringen. På telefonen skal tunnelen komme opp når appen startes og dens første forespørsel går ut, ikke bare når noen starter en separat manuell konfigurasjon i Innstillinger. Hvis starting av appen ikke endrer noe og den manuelle konfigurasjonen gjør det, er appen ikke bundet til en per-app-tunnel i det hele tatt.
Oppdateringer betyr noe: den som sendes via administrasjon beholder mappingen, mens en nyinstallering brukeren starter kan miste den. Når klagen dateres fra en oppdatering, sjekk app-oppføringen før nettet.
Sjekk hva tunnelen har lov til å ta
En per-app-tunnel velges av kildeappen, så telefonens standardrute tilhører fortsatt Wi-Fi eller mobilnettet. OverridePrimary er nøkkelen som endrer dette. Når en profil setter den, oppfører tunnelen seg som en full tunnel og hver app arver den, så alt som går via VPN blir et profilspørsmål og ikke en appfeil.
Reglene ved forespørsel avgjør varigheten. OnDemandEnabled og regelsettet gjør at tunnelen kommer tilbake når appen sender trafikk, overlever byttet fra Wi-Fi til mobilnett, eller faller når appen går i bakgrunnen. En distribusjon som kobler til og deretter dør stille har vanligvis en regel som bare passer en sondering som aldri utløses mens appen er inaktiv.
Les deretter rutene ærlig. Hvis leverandørens eller forhandlerens profil gir en inkluderingsliste, vil en tunnel som bare bærer 10.20.0.0/16 ikke bære tjeneste i 10.30.0.0/16; det er listen som gjør jobben sin, ikke en per-app-feil. Den innebygde iOS-payloaden har ingen inkluderingsliste. Uten den følger delingen leverandørens standardverdier og IncludeAllNetworks, ikke en skjult liste.
Test appen, og test deretter det som forlater den
Test med navn, ikke bare adresse. Å slå opp en intern vert inne i den administrerte appen beviser at DNS også gikk gjennom tunnelen, fordi payloaden bestemmer hvilken resolver som svarer og hvilke søkedomener som gjelder. Rutingen kan være perfekt mens navneoppslaget feiler, og de to symptomene peker på ulike innstillinger.
Test deretter grensen fra begge sider. En personlig app eller Safari skal nå en vanlig offentlig side og rapportere operatørens eller hjemmets adresse, mens den administrerte appen når den private tjenesten. Hvis begge rapporterer samme offentlige adresse, er tunnelen ikke lenger per app, uansett hva app-oppføringen sier.
Strømmer som forlater appen lager forvirrende saker. En lenke som åpnes i Safari, et dokument som sendes via delingsarket, eller en SSO-innlogging som går over til en nettleser, forlater appens prosess og tunnelen med den. En innlogging som vises inne i appen tilskrives vanligvis appen, så innebygd innlogging kan lykkes der samme URL feiler i Safari; verifiser det i stedet for å anta det. Når identitetsleverandøren bare er tilgjengelig via tunnelen, hold innloggingen inne i appen eller legg leverandørens domene til payloadens Safari-domener, slik at samsvarende Safari-trafikk fanges.
Koble symptomet til laget
Feilens form forteller hvilken kontroll som må gjentas.
| 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 |
Bak de midtre linjene står to detaljer: en per-app-tunnel kan være sunn og likevel miste et subnett som ingen leverandørliste inneholder, og en administrert telefon kan holde mer enn én VPN-konfigurasjon, så bekreft hvilken appen er bundet til i stedet for å anta at det er den du leser.
Rett i denne rekkefølgen: rett app-oppføringen slik at den peker på den aktive payloaden, installer appen på nytt via administrasjon, bekreft at tunnelen kommer opp ved appens første forespørsel, og gjenta deretter navne- og grensetestene. Hvis den første forespørselen ikke kan starte noen tunnel i det hele tatt, stopp og sjekk leverandørsiden, fordi en tilpasset klient trenger Network Extension til stede og en identifikator som samsvarer med den installerte appen.
Returner tre fakta i stedet for et skjermbilde: hvilken payload app-oppføringen peker på, om Innstillinger viser den som en installert profil, og hva den mislykkede forespørselen var — et navn, en adresse eller en overlevering til nettleseren. Disse tre svarene skiller en distribusjonsfeil fra en ruteleirfeil, og neste person kan handle uten å gjenta diagnosen.