Per-app-VPN på administrerte iPhone-appar: kva som blir ruta og kva som ikkje

Per-app-VPN på iPhone er ikkje ein brytar for heile telefonen. Det er ei tilknyting mellom éin administrert app og éin VPN-payload, oppretta når appen blir distribuert, og trafikken til alt anna held ruta han hadde. Derfor oppfører same telefon seg inkonsekvent: jobbappen opnar ei privat side medan Safari ikkje når same vert, eller tunnelen kjem ikkje opp i det heile og appen rapporterer ein tidsavbrot som ser ut som feil påloggingsinformasjon. Kontrollane går frå den breiaste årsaka og nedover, så stopp ved den første som feilar.

Sjekk payloaden og app-oppføringa først

Tilknytinga lever i to objekt, ikkje eitt. VPN-payloaden definerer tunnelen: type, server, autentisering, DNS og leverandøren sin bundle-ID når ein tilpassa klient blir brukt. App-oppføringa peikar på den payloaden, og dei fleste administrasjonskonsollar tilbyr dette som eit per-app-alternativ i appkonfigurasjonen, med eit namn nær Per-App VPN. Ein payload som ingen app peikar på ruter ingenting per app; han oppfører seg som ein vanleg tunnel som nokon må starte manuelt.

Les begge objekta før du rører telefonen. Stadfest at appkonfigurasjonen peikar på payloaden du testar og ikkje ein eldre kopi av han, fordi dupliserte payloadar med nesten same namn er vanlege etter migrering, og appen peikar gjerne på den som er trekt tilbake. Stadfest deretter at konfigurasjonen har nådd eininga: Innstillingar, Generelt, VPN og einingadministrasjon må vise han som ein installert profil. VPN-lista der er ikkje testen. Ein per-app-teneste har vanlegvis ingen manuell brytar, så ein riktig distribuert konfigurasjon visest kanskje aldri blant VPN-ane som kan startast. Fråværet blir sett i app-oppføringa og i om tunnelen kjem opp ved den første førespurnaden til appen.

Éin føresetnad forklarer mange saker: denne modellen krev at appen kjem via administrasjon. Ein kopi som er installert sidelengs eller kjøpt privat får ikkje tilknytinga, sjølv når bundle-ID-en stemmer. Apple sin distribusjonsrettleiar for VPN skildrar payloadmodellen bak dette (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).

Stadfest at den installerte appen er den administrerte kopien

Tilknytinga følgjer den installerte, administrerte appen. Viss nokon installerte han på nytt frå App Store med ein personleg Apple-ID, bytte han ut med ein ny-signert bedriftsbuild, eller eininga vart registrert på nytt og appen kom tilbake via ein annan kanal, kan tunnelen bli liggjande nede medan appen sjølv ser heilt normal ut.

Test ved samanlikning, ikkje éi observasjon. I administrasjonsinventaret skal appen visast som administrert for den eininga med VPN-mappinga i oppføringa. På telefonen skal tunnelen kome opp når appen blir starta og den første førespurnaden hans går ut, ikkje berre når nokon startar ein separat manuell konfigurasjon i Innstillingar. Viss starting av appen ikkje endrar noko og den manuelle konfigurasjonen gjer det, er appen ikkje bunden til ein per-app-tunnel i det heile.

Oppdateringar betyr noko: den som blir send via administrasjon held mappinga, medan ein nyinstallasjon brukaren startar kan miste henne. Når klaga er datert frå ein oppdatering, sjekk app-oppføringa før nettet.

Sjekk kva tunnelen har lov til å ta

Ein per-app-tunnel blir vald av kjeldeappen, så standardruta til telefonen høyrer framleis til Wi-Fi eller mobilnettet. OverridePrimary er nøkkelen som endrar dette. Når ein profil set han, oppfører tunnelen seg som ein full tunnel og kvar app arvar han, så alt som går via VPN blir eit profilspørsmål og ikkje ein appfeil.

Reglane ved førespurnad avgjer varigheita. OnDemandEnabled og regelsettet gjer at tunnelen kjem tilbake når appen sender trafikk, overlever bytet frå Wi-Fi til mobilnett, eller fell når appen går i bakgrunnen. Ein distribusjon som koplar til og deretter døyr stille har vanlegvis ein regel som berre passar ein sondering som aldri blir utløyst medan appen er inaktiv.

Les deretter rutene ærleg. Viss leverandøren eller forhandlaren sin profil gir ei inkluderingsliste, vil ein tunnel som berre ber 10.20.0.0/16 ikkje bere teneste i 10.30.0.0/16; det er lista som gjer jobben sin, ikkje ein per-app-feil. Den innebygde iOS-payloaden har inga inkluderingsliste. Utan henne følgjer delinga standardverdiane til leverandøren og IncludeAllNetworks, ikkje ei skjult liste.

Test appen, og test deretter det som forlèt han

Test med namn, ikkje berre adresse. Å slå opp ein intern vert inne i den administrerte appen beviser at DNS også gjekk gjennom tunnelen, fordi payloaden avgjer kva resolver som svarar og kva søkedomene som gjeld. Rutinga kan vere perfekt medan namneoppslaget feilar, og dei to symptoma peikar på ulike innstillingar.

Test deretter grensa frå begge sider. Ein personleg app eller Safari skal nå ei vanleg offentleg side og rapportere adressa til operatøren eller heimen, medan den administrerte appen når den private tenesta. Viss begge rapporterer same offentlege adresse, er tunnelen ikkje lenger per app, uansett kva app-oppføringa seier.

Straumane som forlèt appen lagar forvirrande saker. Ei lenkje som opnast i Safari, eit dokument som blir sendt via delingsarket, eller ei SSO-innlogging som går over til ein nettlesar, forlèt prosessen til appen og tunnelen med han. Ei innlogging som blir vist inne i appen blir vanlegvis tilskriven appen, så innebygd innlogging kan lukkast der same URL feilar i Safari; verifiser det i staden for å anta det. Når identitetsleverandøren berre er tilgjengeleg via tunnelen, hald innlogginga inne i appen eller legg domenet til leverandøren til Safari-domena til payloaden, slik at samsvarande Safari-trafikk blir fanga.

Kople symptomet til laget

Forma på feilen fortel kva kontroll som må gjentakast.

Bak dei midtre linjene står to detaljar: ein per-app-tunnel kan vere sunn og likevel miste eit subnett som inga leverandørliste inneheld, og ein administrert telefon kan halde meir enn éin VPN-konfigurasjon, så stadfest kva appen er bunden til i staden for å anta at det er den du les.

Rett i denne rekkjefølgja: rett app-oppføringa slik at ho peikar på den aktive payloaden, installer appen på nytt via administrasjon, stadfest at tunnelen kjem opp ved den første førespurnaden til appen, og gjenta deretter namne- og grensetestane. Viss den første førespurnaden ikkje kan starte nokon tunnel i det heile, stopp og sjekk leverandørsida, fordi ein tilpassa klient treng Network Extension til stades og ein identifikator som samsvarar med den installerte appen.

Returner tre fakta i staden for eit skjermbilde: kva payload app-oppføringa peikar på, om Innstillingar viser han som ein installert profil, og kva den mislukka førespurnaden var — eit namn, ei adresse eller ei overlevering til nettlesaren. Desse tre svara skil ein distribusjonsfeil frå ein ruteleggingsfeil, og neste person kan handle utan å gjenta diagnosen.