VPN på iPhone kobler til på nytt etter at du slår det av: hvem starter det igjen?

Trykk på koble fra på iPhone-VPN-en, åpne en nettleser, og tunnelen er oppe igjen før siden lastes, noe som får bryteren til å se ødelagt ut. Vanligvis virker det som tenkt, bare ikke slik brukeren mente. Frakobling avslutter én økt; noe annet har fortsatt tillatelse til å starte en ny. Tre forskjellige eiere kan gjøre det på iOS, og hver etterlater et ulikt fingeravtrykk i når gjenoppkoblingen skjer.

Frakobling er ikke deaktivering

En manuell frakobling ber tunnelen stoppe. Den ber ikke nødvendigvis systemet slutte å spørre etter den. Regler for koble til ved behov, leverandørappens egen policy for automatisk tilkobling og en administrert Always On-konfigurasjon overlever alle en frakobling, og hver av dem kan starte tilkoblingen igjen uten at brukeren rører noe.

Forskjellen betyr noe fordi løsningen ligger hos eieren. Å trykke hardere på bryteren hjelper aldri, og å slette profilen er en mye større handling enn problemet krever. Finn utløseren først, og avgjør deretter om det er din oppgave å endre den. Den rekkefølgen hindrer deg også i å fjerne en fungerende konfigurasjon for å jage en regel som bor et annet sted.

Sammenlign de tre eierne etter utløseren deres

Koble til ved behov reagerer på betingelser som operativsystemet vurderer: å bli med i et nettverk, eller en forespørsel som involverer et domene regelen passer til. En leverandørapp kan reise en tilkobling når appen starter eller når dens egen bakgrunnspolicy bestemmer det. En administrert Always On-utrulling er et krav på enhetsnivå som brukeren ikke er ment å overstyre i det hele tatt.

Se hvilken hendelse som kommer før gjenoppkoblingen, og eieren blir ganske tydelig. Det er forskjellen mellom en regel du kan redigere og en policy du bare kan spørre om.

Hva reglene for ved behov faktisk gjør

Atferd ved behov er en ordnet liste. Hver oppføring passer til en betingelse og gir en handling: koble til, koble fra, vurder et tilkoblingsforsøk eller ignorer. En tilkoblingsregel som står før en frakoblingsregel, vinner hver gang begge passer, og derfor kan en enhet kobles til igjen umiddelbart etter en manuell frakobling.

Regler kan også være domenestyrt og passe på et vertsnavn i en forespørsel i stedet for en grensesnittendring. Det er mønsteret bak «VPN-en kommer tilbake når jeg åpner intranettsiden», og det peker på leverandøren eller profilen som installerte regelen, ikke på iOS selv.

Administrert Always On er ikke et personlig valg

På en overvåket, administrert enhet kan organisasjonen kreve at en VPN holdes oppe og fjerne brukerens mulighet til å slå den av. Ingen mengde brytertrykking i Innstillinger endrer det, og det ærlige svaret er at atferden tilhører administratorpolicyen.

Spør hvilken policy som gjelder og hvilken unntaksprosess som finnes, hvis noen. Sletting av den installerte administrasjonsprofilen er ikke en støttet løsning; det kan fjerne annen konfigurasjon enheten er avhengig av, og det kan bryte samsvarsrapporteringen.

Test ved å fjerne utløseren, ikke profilen

La profilen være installert, koble fra, og gjenta deretter hendelsen som tidligere startet tunnelen på nytt: bli med i det samme Wi-Fi-nettet, åpne den samme appen, be om det samme interne navnet. Hvis tunnelen kommer tilbake i det øyeblikket, har du identifisert utløseren og kan lete etter innstillingen som eier den.

Endre én innstilling hos eieren, og gjenta deretter den samme testen. Hvis gjenoppkoblingen stopper, har du svaret; hvis den fortsetter, er utløseren et annet sted, og profilen var aldri problemet. En nedlastet innstillingsfil som fortsatt ligger i Filer, er heller ikke en installert konfigurasjon, så å fjerne filen beviser ingenting.

Det nyttige resultatet er en setning du kan skrive ned: denne tilkoblingen startes av denne regelen eller policyen, og eies av denne parten. Når det er sant, slutter bryteren å føles uforutsigbar, og neste person som rapporterer det, får et direkte svar i stedet for nok en ominstallasjon.