VPN par domaine sur iPhone : décidez où le refus se produit
NeverConnect empêche le VPN de démarrer ; il ne bloque pas un site web. Décidez si le refus relève de la frontière du service ou d'une politique gérée.
Deux exigences sont consignées en une seule phrase, puis mises en œuvre à des endroits totalement différents. « Ce site ne doit être joignable que par le VPN » est une affirmation sur l'admission, et son foyer naturel est le réseau devant le service. « Cet iPhone ne doit jamais contacter ce domaine directement » est une affirmation sur l'appareil, et seule une politique client gérée peut l'exprimer. Décidez laquelle vous avez réellement avant d'ouvrir un éditeur de profil.
Deux exigences qui sonnent identiques
Prenez l'hôte illustratif records.corp.example. Dans le cas de l'admission, vous ne le publiez que vers des adresses derrière le VPN, si bien qu'une tentative directe depuis un téléphone en réseau cellulaire échoue au niveau du réseau, tandis que la même requête via le tunnel réussit et exige toujours une vraie connexion au compte. Dans le cas de l'appareil, le téléphone peut atteindre l'internet public, donc l'hôte se résout et répond à tout le monde, et le seul endroit pour arrêter la tentative est l'appareil. Le service ne peut pas appliquer une règle à une requête qui ne lui parvient jamais.
Une mauvaise lecture de l'exigence se manifeste par un déploiement précis. L'enregistrement reste public, l'opérateur croit le VPN obligatoire, et un audit d'une tentative cellulaire montre que la requête n'est jamais entrée dans le tunnel. Rien dans les journaux ne semble cassé, parce que rien n'a été bloqué.
Lisez les actions d'évaluation au pied de la lettre
Le mécanisme à la demande comporte deux couches d'actions distinctes, et les confondre produit l'essentiel de la confusion ici. L'action de règle externe décide de ce qui arrive au tunnel quand la règle correspond, et l'action d'évaluation de connexion décide de ce qui arrive à une correspondance de nom d'hôte dans une règle d'évaluation. La référence Never Connect d'Apple ne décrit que la seconde couche.
| Layer | Action | What it controls |
|---|---|---|
| Outer rule | connect | Bring the tunnel up when the rule matches |
| Outer rule | disconnect | Tear the tunnel down when the rule matches |
| Outer rule | evaluateConnection | Run a hostname evaluation instead of acting directly |
| Outer rule | ignore | Leave the current tunnel state alone |
| Connection evaluation | connectIfNeeded | Start the tunnel when the hostname cannot be resolved |
| Connection evaluation | neverConnect | Do not start the tunnel for that match |
neverConnect est la valeur la plus souvent mal lue, car le nom suggère un blocage. Elle régit le démarrage du tunnel pour un nom d'hôte correspondant, non l'autorisation du téléphone à atteindre un nom, donc une entrée Never Connect n'est pas un blocage de domaine. L'étiqueter ainsi dans un document de conception est la façon dont un déploiement est approuvé avec une frontière d'application qu'il n'a pas.
Quand le service est à vous, appliquez à la frontière
Restreindre l'admission signifie publier le nom uniquement là où le chemin VPN peut l'atteindre, puis vérifier que le chemin prévu fonctionne et qu'un autre chemin non. Couvrez chaque enregistrement publié, les deux familles d'adresses si vous les publiez, et tout nom intermédiaire ou alternatif utilisé par l'application. Un ancien CNAME pointant encore vers un répartiteur de charge public maintient le chemin direct vivant, aussi propre soit l'enregistrement principal.
Cela protège le service plutôt que l'appareil. Cela n'empêche pas le téléphone d'envoyer une requête DNS, ni l'application d'essayer. Si ces tentatives sont acceptables, l'application à la frontière est le choix le moins coûteux et le plus durable, car il vaut pour chaque client et pas seulement pour ceux que vous avez configurés. Il survit aussi à un téléphone qui n'a jamais été inscrit.
Quand le téléphone ne doit même pas essayer, il faut une politique gérée
Arrêter la tentative exige une politique d'application prise en charge qui couvre l'application ou les destinations avant la connexion, pendant une défaillance du tunnel et après un changement de réseau. Demandez au fournisseur de VPN ou de gestion des appareils de nommer cette politique, de dire si elle exige une gestion organisationnelle et de décrire ce qu'elle affecte d'autre. Un tunnel par application plus une règle à la demande ne sont pas la même chose, et un raccourci d'écran d'accueil vers une connexion non plus.
Testez le cas de défaillance en désactivant le tunnel et en observant si la requête sort. Si elle sort, la frontière que vous avez documentée n'est pas celle que vous avez déployée.
Décidez avec trois questions
Premièrement, contrôlez-vous le service ou seulement le téléphone ? Deuxièmement, l'appareil peut-il légitimement utiliser l'internet public pour tout le reste ? Troisièmement, le téléphone est-il géré, et par qui ? Posséder le service plus un parc géré signifie que l'une ou l'autre couche est disponible, tandis que ne posséder que le téléphone fait de la politique client la seule option et elle doit être prise en charge.
Répondez à ces trois avant de toucher à un profil. La configuration cesse alors d'être une supposition sur ce que signifie une case nommée Never.