Always On VPN kontra VPN On Demand på iPhone: hvad du skal implementere

On Demand åbner en tunnel, når dens regler matcher; administreret Always On håndhæver dækning på overvågede enheder. En kørebog til at vælge og bevise, at det virker.

To iPhones kan begge sige VPN og opføre sig helt forskelligt. On Demand åbner en tunnel, når en regel matcher, og brugeren kan stadig slå den fra i Indstillinger. Administreret Always On holder dækningen håndhævet på en overvåget enhed, også i de øjeblikke hvor tunnelen ikke kan komme op. Vælg ved at spørge, hvad der skal være sandt, når brugeren intet gør, og test derefter overgangene frem for den stabile tilstand. Trinene nedenfor følger den rækkefølge, en udrulning faktisk fejler i.

Trin 1: fastslå, hvad enheden kan håndhæve

Always On er en funktion til overvågede enheder. Er flåden ikke overvåget, er diskussionen slut før den begynder, og ingen payload-nøgle gør en ikke-overvåget telefon håndhævet. Bekræft overvågningen fra administrationssiden og fra enheden, og bekræft derefter, hvem der signerede profilen.

På telefonen: Indstillinger, derefter Generelt, derefter VPN og enhedsstyring. Profilposten angiver sin ejer, og en personlig profil installeret manuelt ser anderledes ud end en, der leveres af en styringstjeneste. Udled ikke håndhævelse af profilens navn eller af en udbyders marketingetikette; etiketten er ikke platformens politik.

Skriv tre fakta ned, før du rører konfigurationen: overvåget eller ej, administreret eller personlig profil, og hvilken klient der bærer tunnelen. Hvert senere trin afhænger af disse tre, og at flytte adfærd fra en personlig telefon til en administreret profil er måden, en udrulning godkendes mod et forkert grundlag.

Trin 2: læs on-demand-reglerne i stedet for funktionsnavnet

On Demand er en liste af regler, der vurderes i rækkefølge. Hver regel angiver en handling og de betingelser, der vælger den, og betingelserne er det interessante: grænsefladetype, Wi-Fi-SSID, DNS-domænesuffiks eller en probe-URL. Et regelsæt, der aldrig matcher, er en funktion, der aldrig forbinder.

<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>

Læs hele arrayet, og stil to spørgsmål pr. regel: kan denne betingelse nogensinde være sand på denne flåde, og hvad sker der, når ingen regel matcher? Virksomhedsnetværk omdøber adgangspunkter, slår SSID'er sammen og ændrer DNS-suffikser, og hver af de ændringer løsriver en regel fra virkeligheden i det stille.

DNS-suffiksbetingelsen er den, der oftest er forkert i marken, fordi det suffiks, en telefon rapporterer på et gæstenetværk, ikke er det, den virksomhedsinterne resolver betjener. Kontrollér det navn, enheden faktisk opløser, før du tror på reglen.

Trin 3: test overgangene, ikke den statiske forbindelse

En tunnel, der er oppe, mens du kigger på den, beviser meget lidt. Udfør hver overgang bevidst, og notér hvad enheden gør, med den samme private ressource hver gang, så resultaterne kan sammenlignes:

  • Log på et netværk, hvor en regel bør matche, og anmod derefter om den private ressource og bekræft, at den indlæses.
  • Skift til mobildata med appen i baggrunden, bring den så i forgrunden og gentag anmodningen.
  • Forbind til et Wi-Fi med captive portal, og se, om portalen kan nås, eller om håndhævelsen blokerer den, før du kan godkende.
  • Slå tunnelen fra manuelt på en overvåget enhed, og tjek, om den kommer tilbage af sig selv, og hvor hurtigt.

Kør den samme liste på en ikke-overvåget enhed, hvis du har en. Forskellen mellem de to resultater er udrulningens reelle adfærd, og det er den del, et skærmbillede af en tilsluttet tunnel aldrig viser.

Trin 4: kend de to fejlformer

Håndhævet dækning fejler ved at blokere. Når tunnelen ikke kan etableres, mister enheden almindelig internetadgang sammen med private ressourcer, og brugeren oplever en telefon, der er online, men ikke kan browse. Genopkobling og blokering er separate observationer, så log begge i stedet for at behandle manglende internet som ét symptom.

On Demand fejler ved ikke at udløse. Reglen matcher ikke, ingen tunnel vises, og den private ressource løber blot ud. Det er let at fejldiagnosticere som et serverproblem, fordi klienten opfører sig præcis som konfigureret.

En captive portal ligger mellem de to: den har brug for forbindelse, før tunnelen findes, så en politik, der blokerer alt, indtil tunnelen er oppe, kræver en dokumenteret vej gennem portalen. Beslut det i designet, ikke ved helpdesken.

Trin 5: verificér, og øv derefter tilbagerulningen

Verifikation hører på den rigtige vej med harmløs trafik: anmod om en privat ressource, der ikke må være offentlig, bekræft hvilken adresse enheden viser udadtil, og gentag efter en genstart, så du har set opstartssekvensen og ikke kun den varme tilstand.

Øv derefter fjernelsen på en testenhed, før du får brug for den i produktion. Fjernelse af profilen returnerer enheden til sin tidligere tilstand, og at vide, hvor lang tid det tager, og hvad brugeren ser, er en del af kørebogen. Apples sikkerhedsvejledning til VPN er referencen for, hvad platformen dokumenterer om disse politikker, og den er værd at læse, før du skriver en konfiguration, der påstår mere end platformen.

Hold de tre fakta fra første trin ved siden af regelsættet og testresultaterne. Når den næste person spørger, hvorfor en telefon forbinder på ét netværk og ikke på et andet, svarer de noter på et minut i stedet for en genopbygning.

Relaterede artikler