Always On VPN kontra VPN On Demand på iPhone: hva du bør rulle ut

To iPhones kan begge si VPN og oppføre seg helt forskjellig. On Demand åpner en tunnel når en regel matcher, og brukeren kan fortsatt slå den av i Innstillinger. Administrert Always On holder dekningen håndhevet på en overvåket enhet, også i øyeblikkene der tunnelen ikke kommer opp. Velg ved å spørre hva som må være sant når brukeren ikke gjør noe, og test deretter overgangene i stedet for den stabile tilstanden. Trinnene nedenfor følger rekkefølgen en utrulling faktisk feiler i.

Trinn 1: fastslå hva enheten kan håndheve

Always On er en funksjon for overvåkede enheter. Er flåten ikke overvåket, er diskusjonen over før den begynner, og ingen payload-nøkkel gjør en ikke-overvåket telefon håndhevet. Bekreft overvåkingen fra administrasjonssiden og fra enheten, og bekreft deretter hvem som signerte profilen.

På telefonen: Innstillinger, deretter Generelt, deretter VPN og enhetsadministrasjon. Profiloppføringen angir eieren, og en personlig profil installert manuelt ser annerledes ut enn en som leveres av en administrasjonstjeneste. Ikke utled håndheving fra profilnavnet eller fra en leverandørs markedsføringsetikett; etiketten er ikke plattformens policy.

Skriv ned tre fakta før du rører konfigurasjonen: overvåket eller ikke, administrert eller personlig profil, og hvilken klient som bærer tunnelen. Hvert senere trinn avhenger av disse tre, og å flytte atferd fra en personlig telefon til en administrert profil er måten en utrulling godkjennes mot et feil grunnlag.

Trinn 2: les on-demand-reglene, ikke funksjonsnavnet

On Demand er en liste over regler som vurderes i rekkefølge. Hver regel angir en handling og betingelsene som velger den, og betingelsene er den interessante delen: grensesnitttype, Wi-Fi-SSID, DNS-domenesuffiks eller en probe-URL. Et regelsett som aldri matcher er en funksjon som aldri kobler til.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Les hele arrayet og still to spørsmål per regel: kan denne betingelsen noen gang være sann på denne flåten, og hva skjer når ingen regel matcher? Bedriftsnettverk gir tilgangspunkter nye navn, slår sammen SSID-er og endrer DNS-suffikser, og hver av disse endringene løsriver en regel fra virkeligheten i stillhet.

DNS-suffikset er betingelsen som oftest er feil i felt, fordi suffikset en telefon rapporterer på et gjestenett ikke er det den bedriftsinterne resolveren betjener. Verifiser navnet enheten faktisk løser opp før du stoler på regelen.

Trinn 3: test overgangene, ikke den statiske forbindelsen

En tunnel som er oppe mens du ser på den, beviser svært lite. Utfør hver overgang bevisst og loggfør hva enheten gjør, med samme private ressurs hver gang slik at resultatene kan sammenlignes:

• Koble til et nettverk der en regel skal matche, be deretter om den private ressursen og bekreft at den lastes.
• Bytt til mobilnett med appen i bakgrunnen, hent den så frem og gjenta forespørselen.
• Koble til et Wi-Fi med captive portal og se om portalen er nåbar eller om håndhevingen blokkerer den før du får autentisert deg.
• Slå av tunnelen manuelt på en overvåket enhet og sjekk om den kommer tilbake av seg selv, og hvor raskt.

Kjør samme liste på en ikke-overvåket enhet hvis du har en. Forskjellen mellom de to resultatene er utrullingens reelle atferd, og det er den delen et skjermbilde av en tilkoblet tunnel aldri viser.

Trinn 4: kjenn de to feilformene

Håndhevet dekning feiler ved å blokkere. Når tunnelen ikke etableres, mister enheten vanlig internettilgang sammen med private ressurser, og brukeren opplever en telefon som er på nett men ikke kan bla. Gjenoppkobling og blokkering er separate observasjoner, så loggfør begge i stedet for å behandle manglende internett som ett symptom.

On Demand feiler ved å ikke utløses. Regelen matcher ikke, ingen tunnel vises, og den private ressursen løper bare ut. Det er lett å feildiagnostisere som et serverproblem, fordi klienten oppfører seg nøyaktig som konfigurert.

En captive portal ligger mellom de to: den trenger tilkobling før tunnelen finnes, så en policy som blokkerer alt til tunnelen er oppe trenger en dokumentert vei gjennom portalen. Bestem det i designet, ikke i brukerstøtten.

Trinn 5: verifiser, og øv deretter på tilbakerullingen

Verifisering hører hjemme på den ekte veien med ufarlig trafikk: be om en privat ressurs som ikke skal være offentlig, bekreft hvilken adresse enheten viser utover, og gjenta etter omstart slik at du har sett oppstartssekvensen og ikke bare den varme tilstanden.

Øv deretter på fjerning på en testenhet før du trenger det i produksjon. Fjerning av profilen returnerer enheten til forrige tilstand, og å vite hvor lang tid det tar og hva brukeren ser er en del av kjøreboken. Apples sikkerhetsveiledning for VPN er referansen for hva plattformen dokumenterer om disse policiene, og den er verdt å lese før du skriver en konfigurasjon som påstår mer enn plattformen.

Hold de tre faktaene fra første trinn ved siden av regelsettet og testresultatene. Når neste person spør hvorfor en telefon kobler til på ett nettverk og ikke på et annet, svarer notatene på et minutt i stedet for en gjenoppbygging.