Always On VPN eller VPN On Demand på iPhone: hva du bør implementere

To iPhone kan begge påstå at de bruker VPN og likevel oppføre seg helt forskjellig. On Demand åpner en tunnel når en regel passer, og brukeren kan fortsatt slå den av i Innstillinger. Administrert Always On holder dekningen tvunget på plass på en overvåket enhet, også når tunnelen ikke kommer opp. Velg ved å spørre hva som må være sant når brukeren ikke gjør noe, og test så overgangene fremfor den stabile tilstanden. Trinnene under følger den rekkefølgen en utrulling faktisk feiler i.

Trinn 1: avgjør hva enheten kan tvinge gjennom

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

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

Noter tre fakta før du berø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 navnet på funksjonen

On Demand er en liste over regler som vurderes i rekkefølge. Hver regel navngir en handling og vilkårene som velger den, og vilkårene er den interessante delen: grensesnitttype, Wi-Fi-SSID, DNS-domenesuffiks eller en probe-URL. Et regelsett som aldri passerer er en funksjon som aldri kobler seg 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 matrisen og still to spørsmål per regel: kan dette vilkåret noen gang være sant på denne flåten, og hva skjer når ingen regel passerer? Bedriftsnettverk gir tilgangspunkter nye navn, slår sammen SSID-er og endrer DNS-suffikser, og hver slik endring løsner en regel fra virkeligheten i det stille.

DNS-suffikset er vilkåret som oftest er feil i praksis, fordi suffikset en telefon rapporterer på et gjestenett ikke er det den interne navnetjeneren betjener. Kontroller navnet enheten faktisk slår opp før du stoler på regelen.

Trinn 3: test overgangene, ikke den statiske forbindelsen

En tunnel som står oppe mens du ser på den, beviser svært lite. Utfør hver overgang med vilje, og loggfør hva enheten gjør, med den samme private ressursen hver gang slik at resultatene blir sammenlignbare:

• Koble til et nettverk der en regel skal passe, 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 tilgjengelig eller om tvangen blokkerer den før du får autentisert deg.
• Slå tunnelen av manuelt på en overvåket enhet og sjekk om den kommer tilbake av seg selv, og hvor raskt.

Kjør den samme listen på en ikke-overvåket enhet hvis du har en. Forskjellen mellom de to resultatene er den virkelige atferden til utrullingen, og det er den delen et skjermbilde av en tilkoblet tunnel aldri viser.

Trinn 4: kjenn de to feilformene

Tvunget 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 surfe. Gjenoppkobling og blokkering er separate observasjoner, så logg begge i stedet for å behandle manglende internett som ett symptom.

On Demand feiler ved å ikke utløses. Regelen passerer ikke, ingen tunnel dukker opp, og den private ressursen går rett og slett ut på tid. 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å tilbakerulling

Verifiseringen hører hjemme på den virkelige 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 fører enheten tilbake 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 policyene, og den er verdt å lese før du skriver en konfigurasjon som hevder 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å ett minutt i stedet for en gjenoppbygging.