Always On VPN kontra VPN On Demand på iPhone: vad du ska driftsätta

On Demand öppnar en tunnel när dess regler matchar; hanterad Always On upprätthåller täckning på övervakade enheter. En runbook för att välja en och bevisa att den fungerar.

Två iPhones kan båda säga VPN och bete sig helt olika. On Demand öppnar en tunnel när en regel matchar, och användaren kan fortfarande stänga av den i Inställningar. Hanterad Always On håller täckningen tvingande på en övervakad enhet, inklusive de stunder då tunneln inte kan komma upp. Välj genom att fråga vad som måste vara sant när användaren inte gör något, och testa sedan övergångarna i stället för det stabila tillståndet. Stegen nedan följer den ordning i vilken en driftsättning faktiskt misslyckas.

Steg 1: fastställ vad enheten kan tvinga fram

Always On är en funktion för övervakade enheter. Om flottan inte är övervakad är diskussionen över innan den börjar, och ingen payload-nyckel gör en icke övervakad telefon tvingande. Bekräfta övervakningen från hanteringssidan och från enheten, och bekräfta sedan vem som signerade profilen.

Öppna Inställningar på telefonen, sedan Allmänt, sedan VPN och enhetshantering. Profilposten anger sin ägare, och en personlig profil som installerats manuellt ser annorlunda ut än en som levererats av en hanteringstjänst. Dra inte slutsatsen om tvingande från profilens namn eller från leverantörens marknadsföringsetikett; etiketten är inte plattformens policy.

Skriv ner tre fakta innan du rör konfigurationen: övervakad eller inte, hanterad profil eller personlig, och vilken klientimplementation som bär tunneln. Varje senare steg beror på de tre, och att flytta beteende från en personlig telefon till en hanterad profil är hur en driftsättning godkänns mot en felaktig baslinje.

Steg 2: läs on-demand-reglerna i stället för funktionsnamnet

On Demand är en lista med regler som utvärderas i ordning. Varje regel anger en åtgärd och villkoren som väljer den, och villkoren är den intressanta delen: gränssnittstyp, Wi-Fi SSID, DNS-domänsuffix eller en test-URL. En regeluppsättning som aldrig matchar är en funktion som aldrig ansluter.

<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 hela arrayen och ställ två frågor per regel: kan villkoret någonsin vara sant i den här flottan, och vad händer när ingen regel matchar? Företagsnät byter namn på åtkomstpunkter, slår ihop SSID:n och ändrar DNS-suffix, och var och en av dessa ändringar kopplar tyst loss en regel från verkligheten.

Villkoret för DNS-suffix är det som oftast är fel i fält, eftersom det suffix en telefon rapporterar på ett gästnät inte är det suffix som företagets resolver betjänar. Verifiera namnet som enheten faktiskt löser upp innan du litar på regeln.

Steg 3: testa övergångarna, inte den statiska anslutningen

En tunnel som är uppe medan du tittar på den bevisar väldigt lite. Utför varje övergång medvetet och notera vad enheten gör, och använd samma privata resurs varje gång så att resultaten går att jämföra:

  • Anslut till ett nät där en regel ska matcha, begär sedan den privata resursen och bekräfta att den laddas.
  • Byt till mobilnät med appen i bakgrunden, ta den sedan till förgrunden och upprepa begäran.
  • Anslut till ett Wi-Fi med captive portal och se om portalen går att nå eller om tvingandet blockerar allt innan du kan autentisera.
  • Stäng av tunneln manuellt på en övervakad enhet och kontrollera om den kommer tillbaka av sig själv, och hur snabbt.

Kör samma lista på en icke övervakad enhet om du har en. Skillnaden mellan de två resultaten är driftsättningens verkliga beteende, och det är den delen en skärmbild av en ansluten tunnel aldrig visar.

Steg 4: känn till de två felfallen

Tvingande täckning misslyckas genom att blockera. När tunneln inte kan upprättas förlorar enheten vanlig internetåtkomst tillsammans med de privata resurserna, och användaren upplever en telefon som är online men inte kan surfa. Återanslutning och blockering är separata observationer, så logga båda i stället för att behandla ingen internet som ett enda symtom.

On Demand misslyckas genom att inte utlösas. Regeln matchar inte, ingen tunnel dyker upp och den privata resursen tar bara timeout. Det här är lätt att feldiagnostisera som ett serverproblem, eftersom klienten beter sig precis som konfigurerat.

En captive portal ligger mellan de två: den behöver anslutning innan tunneln finns, så en policy som blockerar allt tills tunneln är uppe behöver en dokumenterad väg genom portalen. Bestäm det i designen, inte i helpdesken.

Steg 5: verifiera och öva sedan på återställningen

Verifiering hör hemma på den verkliga vägen med ofarlig trafik: begär en privat resurs som inte får vara publik, bekräfta vilken adress enheten presenterar utåt och upprepa efter en omstart så att du har sett startsekvensen och inte bara det varma tillståndet.

Öva sedan på borttagning på en testenhet innan du någonsin behöver det i produktion. Att ta bort profilen återställer enheten till sitt tidigare tillstånd, och att veta hur lång tid det tar och vad användaren ser är en del av runbooken. Apples säkerhetsguide för VPN är referensen för vad plattformen dokumenterar om dessa policyer, och den är värd att läsa innan du skriver en konfiguration som påstår mer än plattformen gör.

Håll de tre fakta från steg ett bredvid regeluppsättningen och testresultaten. När nästa person frågar varför en telefon ansluter i ett nät och inte i ett annat svarar de anteckningarna på en minut i stället för en ombyggnad.

Relaterade artiklar