Always On VPN mot VPN On Demand på iPhone: kva ein skal rulle ut

On Demand opnar ein tunnel når reglane passar; styrt Always On held dekninga tvinga på overvaka einingar. Ei køyrebok for å velje og prova at det verkar.

To iPhone kan båe seie VPN og likevel oppføre seg heilt ulikt. On Demand opnar ein tunnel når ein regel passar, og brukaren kan framleis slå han av i Innstillingar. Styrt Always On held dekninga tvinga på ei overvaka eining, også i augneblinkane der tunnelen ikkje kjem opp. Vel ved å spørje kva som må vere sant når brukaren ikkje gjer noko, og test deretter overgangane i staden for den stabile tilstanden. Stega nedanfor følgjer rekkjefølgja der ei utrulling faktisk feilar.

Steg 1: fastslå kva eininga kan tvinge

Always On er ein funksjon for overvaka einingar. Er flåten ikkje overvaka, er samtalen over før han byrjar, og ingen payload-nøkkel gjer ein ikkje-overvaka telefon tvinga. Stadfest overvakinga frå styringssida og frå eininga, og stadfest deretter kven som signerte profilen.

På telefonen: Innstillingar, deretter Generelt, deretter VPN og einingstyring. Profiloppføringa nemner eigaren sin, og ein personleg profil som er installert for hand ser annleis ut enn ein som ei styringsteneste leverer. Ikkje trekk tvinga ut frå namnet på profilen eller frå ein marknadsføringsetikett hjå leverandøren; etiketten er ikkje retningslinja til plattforma.

Skriv ned tre fakta før du rører konfigurasjonen: overvaka eller ikkje, styrt eller personleg profil, og kva klient som ber tunnelen. Kvart seinare steg heng på desse tre, og å flytte åtferd frå ein personleg telefon til ein styrt profil er måten ei utrulling blir godkjend mot eit feil grunnlag.

Steg 2: les on-demand-reglane, ikkje funksjonsnamnet

On Demand er ei liste med reglar som blir vurderte i rekkjefølgje. Kvar regel nemner ei handling og vilkåra som vel han, og vilkåra er den interessante delen: grensesnitttype, Wi-Fi-SSID, DNS-domenesuffiks eller ein probe-URL. Eit regelsett som aldri passar er ein funksjon som aldri koplar 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 heile arrayet og still to spørsmål per regel: kan dette vilkåret nokon gong vere sant på denne flåten, og kva skjer når ingen regel passar? Bedriftsnettverk gir tilgangspunkt nye namn, slår saman SSID-ar og endrar DNS-suffiks, og kvar av desse endringane koplar ein regel laus frå røynda i stillheit.

DNS-suffikset er vilkåret som oftast er feil i felt, fordi suffikset ein telefon rapporterer på eit gjestenett ikkje er det den interne oppløysaren tener. Stadfest namnet eininga faktisk løyser opp før du stolar på regelen.

Steg 3: test overgangane, ikkje den statiske sambindinga

Ein tunnel som står oppe medan du ser på han, beviser svært lite. Utfør kvar overgang med vilje og loggfør kva eininga gjer, med same private ressursen kvar gong slik at resultata kan samanliknast:

  • Kopla til eit nettverk der ein regel skal passe, be deretter om den private ressursen og stadfest at han lastar.
  • Byt til mobilnett med appen i bakgrunnen, hent han så fram og gjenta førespurnaden.
  • Kopla til eit Wi-Fi med captive portal og sjå om portalen er nåbar eller om tvinga blokkerer han før du får autentisert deg.
  • Slå av tunnelen for hand på ei overvaka eining og sjekk om han kjem tilbake av seg sjølv, og kor raskt.

Køyr same lista på ei ikkje-overvaka eining om du har ei. Skilnaden mellom dei to resultata er den reelle åtferda til utrullinga, og det er den delen eit skjermbilde av ein tilkopla tunnel aldri viser.

Steg 4: kjenn dei to feilformene

Tvinga dekning feilar ved å blokkere. Når tunnelen ikkje blir etablert, mistar eininga vanleg internettilgang saman med private ressursar, og brukaren opplever ein telefon som er på nett men ikkje kan bla. Ny tilkopling og blokkering er skilde observasjonar, så loggfør båe i staden for å handsame manglande internett som eitt symptom.

On Demand feilar ved å ikkje bli utløyst. Regelen passar ikkje, ingen tunnel viser seg, og den private ressursen renn berre ut. Det er lett å feildiagnostisere som eit tenarproblem, fordi klienten oppfører seg nøyaktig som konfigurert.

Ein captive portal ligg mellom dei to: han treng samband før tunnelen finst, så ein politikk som blokkerer alt til tunnelen er oppe treng ei dokumentert lei gjennom portalen. Avgjer det i designet, ikkje i brukarstøtta.

Steg 5: stadfest, og øv deretter på tilbakerulling

Stadfestinga høyrer heime på den ekte vegen med ufarleg trafikk: be om ein privat ressurs som ikkje skal vere open, stadfest kva adresse eininga viser utover, og gjenta etter omstart slik at du har sett oppstartssekvensen og ikkje berre den varme tilstanden.

Øv deretter på fjerning på ei testeining før du treng det i produksjon. Fjerning av profilen fører eininga tilbake til førre tilstand, og å vite kor lang tid det tek og kva brukaren ser er ein del av køyreboka. Tryggleiksrettleiinga for VPN frå Apple er referansen for kva plattforma dokumenterer om desse retningslinjene, og ho er verd å lese før du skriv ein konfigurasjon som påstår meir enn plattforma.

Hald dei tre fakta frå første steg ved sida av regelsettet og testresultata. Når neste person spør kvifor ein telefon koplar til på eitt nettverk og ikkje på eit anna, svarar notata på eit minutt i staden for ein ombygging.

Relaterte artiklar