Per-toepassing-VPN op bestuurde iPhone-programme: wat roeteer en wat nie

Per-toepassing-VPN op iPhone is nie ’n foonwye skakelaar nie. Dit is ’n assosiasie tussen een bestuurde program en een VPN-nuttige lading, geskep wanneer die program ontplooi word, en verkeer van alles anders behou die roete wat dit voorheen gehad het. Dit is waarom dieselfde foon inkonsekwent optree: die werkprogram maak ’n private bladsy oop terwyl Safari nie dieselfde gasheer kan bereik nie, of die tonnel kom nooit op nie en die program rapporteer ’n tydsverloop wat soos slegte geloofsbriewe lyk. Die kontroles loop van die breedste oorsaak af ondertoe, so stop by die eerste een wat misluk.

Kontroleer eers die nuttige lading en die programrekord

Die assosiasie leef in twee objekte, nie een nie. Die VPN-nuttige lading definieer die tonnel: tipe, bediener, verifikasie, DNS en die verskaffer-bundelidentifiseerder wanneer ’n pasgemaakte kliënt gebruik word. Die programrekord wys na daardie nuttige lading, en die meeste bestuurkonsoles bied dit as ’n per-program-opsie op die programkonfigurasie aan, met ’n naam na aan Per-App VPN. ’n Nuttige lading waarheen geen program wys nie, roeteer niks per program nie; dit gedra hom soos ’n gewone tonnel wat iemand met die hand moet begin.

Lees albei objekte voordat jy aan die foon raak. Bevestig dat die programkonfigurasie na die nuttige lading verwys wat jy toets en nie na ’n ouer kopie daarvan nie, want gedupliseerde nuttige ladings met byna identiese name kom ná ’n migrasie gereeld voor en die program wys graag na die afgeloste een. Bevestig dan dat die konfigurasie die toestel bereik het: Instellings, Algemeen, VPN & Toestelbestuur moet dit as ’n geïnstalleerde profiel wys. Die VPN-lys daar is nie die toets nie. ’n Per-program-diens het gewoonlik geen handskakelaar nie, so ’n korrek ontplooide konfigurasie verskyn dalk nooit tussen die VPN's wat jy kan begin nie. Afwesigheid blyk uit die programrekord en uit of die tonnel op die program se eerste aanvraag begin.

Een voorwaarde verduidelik baie kaartjies: hierdie model vereis dat die program deur bestuur aankom. ’n Sypad-gelaaide of persoonlik gekoopte kopie kry nie die assosiasie nie, selfs wanneer sy bundelidentifiseerder ooreenstem. Apple se ontplooiingsgids vir VPN beskryf die nuttige-lading-model hieragter (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).

Bevestig dat die geïnstalleerde program die bestuurde kopie is

Assosiasie volg die geïnstalleerde, bestuurde program. As iemand dit onder ’n persoonlike Apple ID uit die App Store herïnstalleer het, dit met ’n herondertekende ondernemingsbou vervang het, of die toestel weer ingeskryf is en die program deur ’n ander kanaal teruggekom het, kan die tonnel af bly terwyl die program self heeltemal normaal lyk.

Toets deur vergelyking, nie deur ’n enkele waarneming nie. In die bestuursinventaris moet die program as bestuur vir daardie toestel wys met die VPN-kartering op sy rekord. Op die foon moet die tonnel opkom wanneer die program begin en sy eerste aanvraag uitgaan, nie net wanneer iemand ’n aparte handkonfigurasie in Instellings begin nie. As die begin van die program niks verander en daardie handkonfigurasie wel, is die program glad nie aan ’n per-program-tonnel gebind nie.

Opdaterings maak saak: een wat deur bestuur gestuur word, behou die kartering, terwyl ’n gebruiker-geïnisieerde herïnstallasie dit kan verloor. Wanneer die klag uit ’n opdatering dateer, kyk eers na die programrekord voordat jy na die netwerk kyk.

Kontroleer wat die tonnel mag opneem

’n Per-program-tonnel word deur die bronprogram gekies, so die foon se verstekroete behoort steeds aan Wi-Fi of sellulêr. OverridePrimary is die sleutel wat dit verander. Wanneer ’n profiel dit stel, gedra die tonnel hom soos ’n volle tonnel en elke program erf dit, so alles wat deur die VPN gaan, word ’n profielvraag eerder as ’n programfout.

Op-aanvra-reëls bepaal volharding. OnDemandEnabled plus sy reëlstel is wat die tonnel laat terugkom wanneer die program verkeer stuur, ’n verandering van Wi-Fi na sellulêr oorleef, of val sodra die program na die agtergrond beweeg. ’n Ontplooiing wat koppel en dan stilweg sterf, het gewoonlik ’n reël wat net op ’n peiling pas wat nooit vuur terwyl die program ledig sit nie.

Lees dan die roetekant eerlik. As ’n verskaffer- of verkoperprofiel ’n insluitlys verskaf, sal ’n tonnel wat net 10.20.0.0/16 dra nie ’n diens in 10.30.0.0/16 dra nie; dit is die lys wat sy werk doen, nie ’n per-program-fout nie. Die ingeboude iOS-nuttige lading het geen insluitlys nie. Sonder een volg die verdeling die verskaffer-verstekke en IncludeAllNetworks, nie ’n verborge lys nie.

Toets die program en dan wat dit verlaat

Toets met ’n naam, nie net ’n adres nie. Die oplos van ’n interne gasheer binne die bestuurde program bewys dat DNS ook deur die tonnel gereis het, want die nuttige lading besluit watter oplosser antwoord en watter soekdomeine toegepas word. Roetering kan perfek wees terwyl naamopsoeking misluk, en die twee simptome wys op verskillende instellings.

Toets dan die grens van albei kante. ’n Persoonlike program of Safari moet ’n gewone openbare bladsy bereik en die draer- of tuisadres rapporteer, terwyl die bestuurde program die private diens bereik. As albei dieselfde openbare adres rapporteer, is die tonnel nie meer per program nie, wat die programrekord ook al beweer.

Vloei wat die program verlaat, lewer die verwarde kaartjies op. ’n Skakel wat in Safari oopmaak, ’n dokument wat deur die deelblad oorgedra word, of ’n SSO-aanmelding wat na ’n blaaier oorskakel, verlaat die program se proses en die tonnel saam daarmee. ’n Aanmelding wat binne die program vertoon word, word gewoonlik aan die program toegeskryf, so ’n ingebedde aanmelding kan slaag waar dieselfde URL in Safari misluk; verifieer dit eerder as om dit te aanvaar. Wanneer die identiteitsverskaffer net deur die tonnel bereikbaar is, hou die aanmelding óf binne die program óf voeg die verskaffer-domein by die nuttige lading se Safari-domeine sodat ooreenstemmende Safari-verkeer opgevang word.

Pas die simptoom by die laag

Die vorm van die faling sê vir jou welke kontrole om te herhaal.

Twee besonderhede sit agter die middelste rye: ’n per-program-tonnel kan gesond wees en tog ’n subnet mis wat geen verskafferlys insluit nie, en ’n bestuurde foon kan meer as een VPN-konfigurasie hou, so bevestig aan watter een die program gebind is eerder as om te aanvaar dit is die een wat jy lees.

Maak reg in hierdie volgorde: korrigeer die programrekord sodat dit na die lewendige nuttige lading verwys, herïnstalleer die program deur bestuur, bevestig dat die tonnel op die eerste aanvraag van die program begin, en herhaal dan die naam- en grenstoetse. As die eerste aanvraag glad nie ’n tonnel kan begin nie, stop en kyk na die verskafferkant, want ’n pasgemaakte kliënt het sy Network Extension nodig, met sy identifiseerder wat by die geïnstalleerde program pas.

Gee drie feite terug eerder as ’n skermkiekie: na watter nuttige lading die programrekord verwys, of Instellings dit as ’n geïnstalleerde profiel wys, en wat die mislukte aanvraag was—’n naam, ’n adres of ’n blaaier-oordrag. Daardie drie antwoorde skei ’n ontplooiingsfout van ’n roeteringsfout, en die volgende persoon kan optree sonder om die diagnose te herhaal.