Always On VPN fronte a VPN On Demand no iPhone: que despregar

Dous iPhone poden dicir ambos VPN e comportarse de forma totalmente distinta. On Demand abre un túnel cando coincide unha regra, e o usuario aínda pode desactivalo nos Axustes. Always On xestionado mantén a cobertura imposta nun dispositivo supervisado, mesmo nos momentos en que o túnel non pode levantarse. Escolla preguntando que debe ser certo cando o usuario non fai nada, e despois probe as transicións en lugar do estado estable. Os pasos seguintes van na orde na que un despregamento falla de verdade.

Paso 1: estableza que pode impor o dispositivo

Always On é unha función para dispositivos supervisados. Se o parque non está supervisado, a conversa remata antes de comezar, e ningunha clave de payload converte un teléfono non supervisado nun imposto. Confirme a supervisión desde o lado de xestión e desde o dispositivo, e despois confirme quen asinou o perfil.

No teléfono: Axustes, despois Xeral, despois VPN e xestión de dispositivos. A entrada do perfil nomea o seu propietario, e un perfil persoal instalado á man parécese distinto dun entregado por un servizo de xestión. Non deduza a imposición do nome do perfil nin dunha etiqueta comercial do provedor; a etiqueta non é a política da plataforma.

Anote tres feitos antes de tocar a configuración: supervisado ou non, perfil xestionado ou persoal, e que cliente transporta o túnel. Cada paso posterior depende deses tres, e trasladar o comportamento dun teléfono persoal a un perfil xestionado é como se aproba un despregamento contra unha base equivocada.

Paso 2: lea as regras on-demand, non o nome da función

On Demand é unha lista de regras avaliadas por orde. Cada regra nomea unha acción e as condicións que a seleccionan, e as condicións son a parte interesante: tipo de interface, SSID de Wi-Fi, sufixo de dominio DNS ou un URL de sonda. Un conxunto de regras que nunca coincide é unha función que nunca conecta.

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

Lea toda a matriz e faga dúas preguntas por regra: pode esta condición ser certa algunha vez neste parque, e que pasa cando non coincide ningunha regra? As redes empresariais renomean puntos de acceso, fusionan SSID e cambian sufixos DNS, e cada unha desas edicións separa unha regra da realidade en silencio.

A condición de sufixo DNS é a que máis falla sobre o terreo, porque o sufixo que un teléfono informa nunha rede de invitados non é o que serve o resolvedor corporativo. Verifique o nome que o dispositivo resolve realmente antes de confiar na regra.

Paso 3: probe as transicións, non a conexión estática

Un túnel levantado mentres o mira demostra moi pouco. Execute cada transición a propósito e anote que fai o dispositivo, usando o mesmo recurso privado cada vez para que os resultados sexan comparables:

• Únase a unha rede onde unha regra debería coincidir, logo solicite o recurso privado e confirme que carga.
• Pase á rede móbil coa aplicación en segundo plano, tráigaa á fronte e repita a solicitude.
• Conéctese a un Wi-Fi con portal cativo e vexa se o portal é alcanzable ou se a imposición o bloquea antes de que poida autenticarse.
• Desactive o túnel manualmente nun dispositivo supervisado e comprobe se volve só e con que rapidez.

Execute a mesma lista nun dispositivo non supervisado se ten un. A diferenza entre ambos resultados é o comportamento real do despregamento, e esa é a parte que unha captura dun túnel conectado nunca mostra.

Paso 4: coñeza as dúas formas de fallo

A cobertura imposta falla bloqueando. Cando o túnel non se establece, o dispositivo perde o acceso normal a internet xunto cos recursos privados, e o usuario vive un teléfono conectado que non pode navegar. Reconexión e bloqueo son observacións separadas, así que rexistre ambas en lugar de tratar a falta de internet como un só síntoma.

On Demand falla non disparándose. A regra non coincide, non aparece ningún túnel e o recurso privado simplemente expira. É fácil diagnosticalo mal como un problema do servidor, porque o cliente compórtase exactamente como está configurado.

Un portal cativo sitúase entre os dous: necesita conectividade antes de que exista o túnel, así que unha política que bloquea todo ata que o túnel sobe necesita unha ruta documentada a través do portal. Decídao no deseño, non no mostrador de axuda.

Paso 5: verifique e despois ensaie a reversión

A verificación vai na ruta real con tráfico inofensivo: solicite un recurso privado que non debe ser público, confirme que enderezo presenta o dispositivo cara a fóra, e repita tras un reinicio para ter visto a secuencia de arranque e non só o estado quente.

Despois ensaie a retirada nun dispositivo de proba antes de necesitala en produción. Retirar o perfil devolve o dispositivo ao seu estado anterior, e saber canto tarda e que ve o usuario forma parte do runbook. A guía de seguridade VPN de Apple é a referencia do que a plataforma documenta sobre estas políticas, e paga a pena lela antes de escribir unha configuración que afirme máis que a plataforma.

Manteña os tres feitos do primeiro paso xunto ao conxunto de regras e aos resultados das probas. Cando a seguinte persoa pregunte por que un teléfono conecta nunha rede e noutra non, esas notas responden nun minuto en lugar de reconstruír.