O VPN baixo demanda do iPhone conéctase ao Wi-Fi da oficina, non á rede móbil

Ás nove, o teléfono únese á rede sen fíos da oficina, e o túnel sobe só e queda alí todo o día. A rede móbil despois compórtase exactamente como todos pretendían. Alguén engadiu unha exclusión para a rede corporativa hai semanas, así que o perfil revísase limpo, e cada mañá segue producindo o mesmo resultado. O dispositivo segue a lista que se lle deu, e a lista di algo distinto do que cría o seu autor.

A lista lese desde arriba, e a primeira coincidencia gaña

As entradas avalíanse en orde. A primeira cuxas condicións se cumpren decide o resultado para ese momento, e todo o que está debaixo nunca se mira. A orde, polo tanto, leva tanta carga de significado como calquera condición escrita dentro dunha regra. Ler a matriz desde arriba explica un perfil que parece ignorar unha exclusión que claramente contén.

Unha entrada xeral de conexión sen fíos colocada por riba da exclusión da oficina garante un túnel no lugar. Non fai falta mover nada máis da carga para que o comportamento se inverta.

Unha entrada de desconexión fai dous traballos

Cando a acción é Desconectar, a entrada pecha unha sesión que xa se executa e bloquea unha nova mentres as súas condicións sigan sendo certas. As dúas metades importan para unha exclusión, e a segunda tende a esquecerse. A mesma entrada nun segundo perfil explica unha planta onde o VPN se nega a arrincar mentres o resto do edificio funciona. Ninguén tocou o túnel; fíxoo a lista.

A táboa mostra a forma, a exclusión primeiro, con nomes que deben vir do teu propio despregamento. Normalmente dúas entradas bastan, e unha terceira para a rede móbil mantén previsible o resto.

Mantén ambas as condicións na exclusión

Empareja o nome da rede co tipo de interface. Un nome por si só pode dispararse nunha ligazón compartida que leve a mesma etiqueta, mentres que un tipo de interface por si só exclúe todas as redes sen fíos que o usuario visita ese día. As dúas metades pertencen a unha entrada, non a dúas regras que casualmente están unha ao lado da outra.

A comparación do nome é exacta e distingue maiúsculas de minúsculas. Iso encaixa cunha rede coñecida e crea tensión en todos os demais casos, porque as redes de convidados reutilizan etiquetas familiares, as sedes renómbranse tras unha fusión e un escritorio con cable non leva nome ningún. Pide ao equipo de rede a etiqueta exacta en lugar de lela dun cartel na parede.

Cando unha sonda supera un nome

Unha entrada de sonda solicita un URL e le unha resposta correcta como condición certa. Escolle un host que só responda desde dentro, como un servizo de intranet que non se poida resolver publicamente, e a regra deixa de importarlle como se chama a rede a si mesma. Unha sonda que responde desde calquera lugar proba internet, non o edificio. A propiedade que decide se isto funciona é que a resposta chegue sen redirección; un portal de convidados que rebota cada petición converte a sonda en ruído.

As regras baseadas en dominio son unha forma aparte: NEEvaluateConnectionRule coincide cos dominios solicitados e pode conectar cando se resolve un nome. O seu comodín só se acepta como a etiqueta máis á esquerda, así que *.example.com é válido mentres que example.*.com non o é. Se un perfil non usa nin condicións de interface nin sondas de alcance, comproba se no seu lugar usa ese tipo de regra.

O que as regras baixo demanda non controlan

As regras elixen se un túnel arrinca e non teñen voz en mantelo funcionando. Unha sesión que aparece e despois desaparece minutos despois apunta a temporizadores de inactividade, límites de sesión da pasarela ou o tamaño da ruta. Cada un deixa unha pegada distinta, e por iso convén descartar a lista de regras antes de cambiar calquera deles. Os axustes de keep-alive non explican ese patrón, e cambialos traslada o traballo sen tocar a causa.

Os usuarios poden desactivar a función baixo demanda en Axustes, e unha asignación xestionada pode restaurala no seguinte rexistro. Cando o interruptor segue volvendo á súa posición anterior, a asignación é a parte activa. A distinción importa, porque a aplicación forzosa volve soa mentres que unha oferta queda desactivada.

Confirma que grupo de perfís posúe o dispositivo e se a intención é impor o túnel ou só ofrecelo. Esa resposta decide se a preferencia do usuario conta como un erro ou como unha función.