Always On VPN versus VPN On Demand a l'iPhone: què cal desplegar

Dos iPhone poden dir tots dos VPN i comportar-se de manera completament diferent. On Demand obre un túnel quan encaixa una regla, i l'usuari encara el pot desactivar als Ajustos. L'Always On gestionat manté la cobertura imposada en un dispositiu supervisat, fins i tot quan el túnel no pot aixecar-se. Trieu preguntant què ha de ser cert quan l'usuari no fa res, i després proveu les transicions en lloc de l'estat estable. Els passos següents van en l'ordre en què un desplegament falla de debò.

Pas 1: establiu què pot imposar el dispositiu

Always On és una funció per a dispositius supervisats. Si el parc no està supervisat, la conversa s'acaba abans de començar, i cap clau de payload converteix un telèfon no supervisat en un d'imposat. Confirmeu la supervisió des del costat de gestió i des del dispositiu, i després confirmeu qui va signar el perfil.

Al telèfon: Ajustos, després General, després VPN i gestió del dispositiu. L'entrada del perfil indica el seu propietari, i un perfil personal instal·lat manualment es veu diferent d'un lliurat per un servei de gestió. No deduïu la imposició del nom del perfil ni d'una etiqueta comercial del proveïdor; l'etiqueta no és la política de la plataforma.

Anoteu tres fets abans de tocar la configuració: supervisat o no, perfil gestionat o personal, i quin client porta el túnel. Cada pas posterior depèn d'aquests tres, i traslladar el comportament d'un telèfon personal a un perfil gestionat és com s'aprova un desplegament contra una base equivocada.

Pas 2: llegiu les regles on-demand, no el nom de la funció

On Demand és una llista de regles avaluades en ordre. Cada regla indica una acció i les condicions que la seleccionen, i les condicions són la part interessant: tipus d'interfície, SSID del Wi-Fi, sufix de domini DNS o un URL de prova. Un conjunt de regles que no encaixa mai és una funció que no connecta mai.

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

Llegiu tota la matriu i feu dues preguntes per regla: pot aquesta condició ser certa algun cop en aquest parc, i què passa quan cap regla encaixa? Les xarxes empresarials reanomenen punts d'accés, fusionen SSID i canvien sufixos DNS, i cadascuna d'aquestes edicions separa una regla de la realitat en silenci.

La condició de sufix DNS és la que més sovint falla sobre el terreny, perquè el sufix que un telèfon informa en una xarxa d'invitats no és el que serveix el resolutor corporatiu. Verifiqueu el nom que el dispositiu resol realment abans de confiar en la regla.

Pas 3: proveu les transicions, no la connexió estàtica

Un túnel aixecat mentre el mireu demostra molt poc. Executeu cada transició deliberadament i anoteu què fa el dispositiu, fent servir el mateix recurs privat cada vegada perquè els resultats siguin comparables:

• Uniu-vos a una xarxa on una regla hauria d'encaixar, demaneu el recurs privat i confirmeu que es carrega.
• Passeu a la xarxa mòbil amb l'aplicació en segon pla, torneu-la al davant i repetiu la petició.
• Connecteu-vos a un Wi-Fi amb portal captiu i mireu si el portal és abastable o si la imposició el bloqueja abans de poder autenticar-vos.
• Desactiveu el túnel manualment en un dispositiu supervisat i comproveu si torna sol i amb quina rapidesa.

Executeu la mateixa llista en un dispositiu no supervisat si en teniu. La diferència entre els dos resultats és el comportament real del desplegament, i és la part que una captura d'un túnel connectat no mostra mai.

Pas 4: conegueu les dues formes de fallada

La cobertura imposada falla bloquejant. Quan el túnel no s'estableix, el dispositiu perd l'accés normal a internet juntament amb els recursos privats, i l'usuari experimenta un telèfon connectat que no pot navegar. Reconnexió i bloqueig són observacions separades, així que registreu les dues en lloc de tractar la manca d'internet com un sol símptoma.

On Demand falla no activant-se. La regla no encaixa, no apareix cap túnel i el recurs privat simplement expira. És fàcil diagnosticar-ho malament com un problema del servidor, perquè el client es comporta exactament com està configurat.

Un portal captiu se situa entre els dos: necessita connectivitat abans que existeixi el túnel, així que una política que ho bloqueja tot fins que el túnel puja necessita un camí documentat a través del portal. Decidiu-ho al disseny, no al taulell d'ajuda.

Pas 5: verifiqueu i després assageu la reversió

La verificació va al camí real amb trànsit inofensiu: demaneu un recurs privat que no ha de ser públic, confirmeu quina adreça presenta el dispositiu a l'exterior i repetiu després d'un reinici per haver vist la seqüència d'arrencada i no només l'estat calent.

Després assageu la retirada en un dispositiu de prova abans de necessitar-la en producció. Retirar el perfil retorna el dispositiu al seu estat anterior, i saber quant triga i què veu l'usuari forma part del runbook. La guia de seguretat VPN d'Apple és la referència del que la plataforma documenta sobre aquestes polítiques, i val la pena llegir-la abans d'escriure una configuració que afirmi més del que afirma la plataforma.

Manteniu els tres fets del primer pas al costat del conjunt de regles i dels resultats de les proves. Quan la propera persona pregunti per què un telèfon connecta en una xarxa i en una altra no, aquestes notes ho responen en un minut en lloc de refer-ho tot.