Per-app VPN på administrerede iPhone-apps: hvad der routes, og hvad der ikke gør
En per-app-tunnel følger den administrerede app, ikke telefonen. Tjek payload-tilknytningen, den administrerede kopi, on-demand-reglerne og de flows, der forlader appen.
Per-app VPN på iPhone er ikke en kontakt for hele telefonen. Det er en tilknytning mellem én administreret app og én VPN-payload, oprettet når appen udrulles, og trafik fra alt andet beholder den rute, det havde før. Derfor opfører den samme telefon sig inkonsekvent: arbejdsappen åbner en privat side, mens Safari ikke kan nå den samme vært, eller tunnelen kommer slet ikke op, og appen rapporterer en timeout, der ligner dårlige legitimationsoplysninger. Kontrollerne kører fra den bredeste årsag og ned, så stop ved den første, der fejler.
Tjek først payloaden og app-posten
Tilknytningen lever i to objekter, ikke ét. VPN-payloaden definerer tunnelen: type, server, godkendelse, DNS og udbyderens bundle-id, når en brugerdefineret klient bruges. App-posten peger på den payload, og de fleste administrationskonsoller viser dette som en per-app-indstilling i app-konfigurationen med et navn tæt på Per-App VPN. En payload, som ingen app peger på, router intet per app; den opfører sig som en almindelig tunnel, som nogen skal starte manuelt.
Læs begge objekter, før du rører telefonen. Bekræft, at app-konfigurationen henviser til den payload, du tester, og ikke til en ældre kopi, fordi dublerede payloads med næsten identiske navne er almindelige efter en migrering, og appen peger gerne på den pensionerede. Bekræft derefter, at konfigurationen nåede enheden: Indstillinger, Generelt, VPN og enhedsstyring skal vise den som en installeret profil. VPN-listen der er ikke testen. En per-app-tjeneste har normalt ikke en manuel kontakt, så en korrekt udrullet konfiguration vises måske aldrig blandt de VPN'er, du kan starte. Fraværet ses i app-posten og i, om tunnelen starter ved appens første anmodning.
Én betingelse forklarer mange sager: denne model kræver, at appen kommer ind via styring. En sideloadet eller personligt købt kopi får ikke tilknytningen, selv når dens bundle-id matcher. Apples udrulningsvejledning for VPN beskriver payload-modellen bag dette (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Bekræft, at den installerede app er den administrerede kopi
Tilknytningen følger den installerede, administrerede app. Hvis nogen geninstallerede den fra App Store med et personligt Apple ID, erstattede den med et gensigneret virksomhedsbuild, eller enheden blev tilmeldt igen, og appen kom tilbage ad en anden kanal, kan tunnelen blive nede, mens appen selv ser helt normal ud.
Test ved sammenligning, ikke ved en enkelt observation. I styringsoversigten skal appen stå som administreret for den enhed med VPN-mappingen i posten. På telefonen skal tunnelen komme op, når appen startes, og dens første anmodning går ud, ikke kun når nogen starter en separat manuel konfiguration i Indstillinger. Hvis det ikke ændrer noget at starte appen, men den manuelle konfiguration gør, er appen slet ikke bundet til en per-app-tunnel.
Opdateringer betyder noget: en, der sendes via styring, bevarer mappingen, mens en geninstallation, som brugeren starter, kan miste den. Når klagen dateres fra en opdatering, så tjek app-posten før netværket.
Tjek, hvad tunnelen må tage
En per-app-tunnel vælges efter kildeappen, så telefonens standardrute tilhører stadig Wi-Fi eller mobilnet. OverridePrimary er den nøgle, der ændrer det. Når en profil sætter den, opfører tunnelen sig som en fuld tunnel, og hver app arver den, så alt gennem VPN bliver et profilspørgsmål i stedet for en app-fejl.
On-demand-regler afgør vedholdenhed. OnDemandEnabled plus dets regelsæt får tunnelen til at vende tilbage, når appen sender trafik, overleve et skift fra Wi-Fi til mobilnet eller falde, når appen går i baggrunden. En udrulning, der forbinder og derefter stille dør, har normalt en regel, der kun matcher en sonde, som aldrig udløses, mens appen er inaktiv.
Læs derefter rutesiden ærligt. Hvis en udbyder- eller leverandørprofil leverer en inkluderingsliste, bærer en tunnel med kun 10.20.0.0/16 ikke en tjeneste i 10.30.0.0/16; det er listen, der gør sit arbejde, ikke en per-app-fejl. Den indbyggede iOS-payload har ingen inkluderingsliste. Uden en følger opdelingen udbyderens standarder og IncludeAllNetworks, ikke en skjult liste.
Test appen, og test derefter, hvad der forlader den
Test med et navn, ikke kun en adresse. Det at slå en intern vært op inde i den administrerede app beviser, at DNS også gik gennem tunnelen, fordi payloaden bestemmer, hvilken resolver der svarer, og hvilke søgedomæner der anvendes. Routing kan være perfekt, mens navneopslag fejler, og de to symptomer peger på forskellige indstillinger.
Test derefter grænsen fra begge sider. En personlig app eller Safari skal nå en almindelig offentlig side og rapportere operatørens eller hjemmets adresse, mens den administrerede app når den private tjeneste. Hvis begge rapporterer den samme offentlige adresse, er tunnelen ikke længere per app, uanset hvad app-posten hævder.
Flows, der forlader appen, skaber de forvirrede sager. Et link, der åbner i Safari, et dokument, der sendes videre via delearket, eller et SSO-login, der skifter til en browser, forlader appens proces og tunnelen med den. Et login, der vises inde i appen, tilskrives normalt appen, så et indlejret login kan lykkes, hvor den samme URL fejler i Safari; verificer det i stedet for at antage det. Når identitetsudbyderen kun kan nås gennem tunnelen, skal du enten holde login inde i appen eller føje udbyderens domæne til payloadens Safari-domæner, så matchende Safari-trafik fanges.
Match symptomet til laget
Fejlens form fortæller dig, hvilken kontrol du skal gentage.
| 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 |
To detaljer ligger bag de midterste rækker: en per-app-tunnel kan være sund og alligevel overse et subnet, som ingen udbyderliste inkluderer, og en administreret telefon kan rumme mere end én VPN-konfiguration, så bekræft, hvilken appen er bundet til, i stedet for at antage, at det er den, du læser.
Ret i denne rækkefølge: ret app-posten, så den henviser til den levende payload, geninstaller appen via styring, bekræft, at tunnelen starter ved appens første anmodning, og gentag derefter navne- og grænsetestene. Hvis den første anmodning slet ikke kan starte en tunnel, stop og tjek udbydersiden, fordi en brugerdefineret klient har brug for sin Network Extension til stede med et id, der matcher den installerede app.
Giv tre fakta tilbage i stedet for et skærmbillede: hvilken payload app-posten henviser til, om Indstillinger viser den som en installeret profil, og hvad den mislykkede anmodning var, et navn, en adresse eller en browserovergang. De tre svar adskiller en udrulningsfejl fra en routingfejl, og den næste person kan handle uden at gentage diagnosen.