Always On VPN : choisir et déployer user tunnel et device tunnel

Position recommandée

Je recommande un user tunnel comme chemin principal pour l’accès utilisateur. Il offre une portée large, peut fonctionner sur plusieurs types de jointure et prend en charge IKEv2 ainsi que SSTP selon le design.

J’ajoute un device tunnel uniquement lorsqu’un appareil domain-joined compatible doit joindre des services de gestion avant logon. Il utilise IKEv2, un certificat machine, le split tunneling et une liste minimale de serveurs de gestion.

Les deux profils peuvent être actifs simultanément, mais leurs routes, NRPT, certificats et règles doivent être conçus ensemble. Le device tunnel ne doit pas devenir une route générale vers tout le réseau interne.

Je recommande un user tunnel comme chemin principal pour l’accès utilisateur. Il offre une portée large, peut fonctionner sur plusieurs types de jointure et prend en charge IKEv2 ainsi que SSTP selon le design.

Besoin, cas d’usage et périmètre de la recommandation

Le device tunnel se connecte avant l’utilisateur et répond aux scénarios de management ou d’accès à un contrôleur de domaine. Dans le modèle Microsoft documenté, il exige un appareil joint au domaine, une édition compatible, IKEv2 et une authentification certificat machine.

Le device tunnel ne prend pas en charge SSTP fallback ni le force tunnel. Je le configure en split tunnel et je limite les routes aux DNS, DC, gestion, PKI et autres services pré-logon justifiés.

Le user tunnel démarre après ouverture de session et porte l’identité utilisateur. Il peut utiliser IKEv2, SSTP, EAP, certificats ou méthodes prises en charge par la passerelle et convient aussi à des appareils Entra joined selon le scénario.

Critères de décision et options possibles

Pour Concevoir les tunnels Always On VPN, je commence par trois résultats concrets: Classer les flux pré/post-logon, Concevoir le user tunnel et Ajouter le device tunnel si justifié. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Pre-logon → Sign-in → User tunnel → Core. Chaque composant a un propriétaire clair, un état vérifiable et une méthode de retour arrière; cette répartition évite qu’une seconde politique masque le résultat de la première.

Le pilote contrôle notamment Classer les flux pré/post-logon, Concevoir le user tunnel et Ajouter le device tunnel si justifié. La généralisation ne commence qu’après une période stable et après vérification des exceptions propres aux populations visées.

La recommandation devient mesurable lorsqu’elle relie le besoin à une cible vérifiable. Les résultats attendus sont Classer les flux pré/post-logon, Concevoir le user tunnel et Ajouter le device tunnel si justifié. Les responsabilités se répartissent ainsi: Pre-logon: Device tunnel vers services minimaux. Sign-in: Utilisateur ouvre sa session. User tunnel: Accès métiers et identité user. Core: Gateway, NPS, PKI, DNS et routes. Cette répartition permet d’attribuer chaque écart au bon propriétaire et d’éviter qu’un second profil, une ancienne autorité ou une exception silencieuse ne produise un résultat apparemment correct mais impossible à exploiter dans la durée.

Les écarts « Device tunnel absent », « Pas de SSTP fallback », « DNS incohérent » et « Deux tunnels instables » servent de tests de décision. Pour chacun, la preuve indiquée dans la matrice doit permettre de choisir entre correction, exception temporaire et retour arrière. Le pilote surveille également les points suivants: device tunnel n’est pas un VPN utilisateur, ne pas supposer SSTP fallback, tester hors réseau d’entreprise et préserver un accès support alternatif. La valeur cible, le mode de distribution, les contrôles et la sortie de secours sont ainsi évalués ensemble.

Architecture cible et répartition des responsabilités

Le device tunnel se connecte avant l’utilisateur et répond aux scénarios de management ou d’accès à un contrôleur de domaine. Dans le modèle Microsoft documenté, il exige un appareil joint au domaine, une édition compatible, IKEv2 et une authentification certificat machine.

Le device tunnel ne prend pas en charge SSTP fallback ni le force tunnel. Je le configure en split tunnel et je limite les routes aux DNS, DC, gestion, PKI et autres services pré-logon justifiés.

Le user tunnel démarre après ouverture de session et porte l’identité utilisateur. Il peut utiliser IKEv2, SSTP, EAP, certificats ou méthodes prises en charge par la passerelle et convient aussi à des appareils Entra joined selon le scénario.

Prérequis, gouvernance et préparation

La préparation de Concevoir les tunnels Always On VPN couvre cas d’usage pré-logon démontré, passerelles et NPS hautement disponibles, PKI et certificats renouvelables, DNS public et interne documentés, plages et routes sans chevauchement. Le propriétaire de chaque composant et la population pilote sont définis avant la création de la configuration.

L’état initial est mesuré avec Classer les flux pré/post-logon. Concevoir le user tunnel. Ajouter le device tunnel si justifié. Déployer par ProfileXML versionné. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• cas d’usage pré-logon démontré
• passerelles et NPS hautement disponibles
• PKI et certificats renouvelables
• DNS public et interne documentés
• plages et routes sans chevauchement
• édition Windows compatible
• support et réseau de secours

Fonctionnement détaillé de Concevoir les tunnels Always On VPN

Le device tunnel se connecte avant l’utilisateur et répond aux scénarios de management ou d’accès à un contrôleur de domaine. Dans le modèle Microsoft documenté, il exige un appareil joint au domaine, une édition compatible, IKEv2 et une authentification certificat machine.

Le device tunnel ne prend pas en charge SSTP fallback ni le force tunnel. Je le configure en split tunnel et je limite les routes aux DNS, DC, gestion, PKI et autres services pré-logon justifiés.

Le user tunnel démarre après ouverture de session et porte l’identité utilisateur. Il peut utiliser IKEv2, SSTP, EAP, certificats ou méthodes prises en charge par la passerelle et convient aussi à des appareils Entra joined selon le scénario.

• cas d’usage pré-logon démontré
• passerelles et NPS hautement disponibles
• PKI et certificats renouvelables
• DNS public et interne documentés

Traitement, exploitation et cas limites de Concevoir les tunnels Always On VPN

Quand les deux tunnels coexistent, NRPT s’applique au user tunnel dans les conditions documentées. Je vérifie les chevauchements de routes et les métriques afin que la montée du second tunnel ne rende pas le premier instable.

La passerelle, NPS/RADIUS, PKI, DNS public, équilibreur et pare-feu forment le service. Je dimensionne ports, adresses, certificats et capacité NPS pour les reconnexions massives, notamment après coupure opérateur.

Les certificats serveur et client doivent être renouvelés sans interruption. J’aligne sujet, EKU, strong mapping, racines, CRL/AIA et accès aux points de distribution depuis le client et les validateurs.

• Tester réseaux représentatifs
• Mesurer gateway et NPS
• Migrer puis retirer l’ancien VPN

Lire les états propres à Concevoir les tunnels Always On VPN

Le pilote couvre bureau, domicile, Wi-Fi captif, partage mobile, double pile, changement de réseau, veille, redémarrage et absence temporaire d’un NPS. Je mesure temps de reconnexion et accès par espace DNS.

Pour une migration depuis DirectAccess ou un VPN tiers, je maintiens une cohorte de coexistence, évite les routes concurrentes et définis le signal exact qui autorise le retrait de l’ancien client.

Mes critères GO comprennent taux de connexion, authentification, stabilité IKEv2/SSTP, latence, incidents DNS, saturation gateway/NPS et rollback. Un tunnel connecté mais inutilisable pour les applications reste un échec.

• Device tunnel absent — Profil all-user et RasClient
• Pas de SSTP fallback — Protocole négocié
• DNS incohérent — Résolution par tunnel
• Deux tunnels instables — Routes et métriques

Pilote et suivi opérationnel de Concevoir les tunnels Always On VPN

Le pilote couvre le périmètre Always On VPN, Device tunnel, User tunnel, IKEv2 et contrôle Classer les flux pré/post-logon. Concevoir le user tunnel. Ajouter le device tunnel si justifié. Les résultats sont segmentés selon les populations réellement concernées par Concevoir les tunnels Always On VPN.

Les cas d’échec « Device tunnel absent », « Pas de SSTP fallback », « DNS incohérent » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve device tunnel n’est pas un VPN utilisateur, ne pas supposer SSTP fallback, tester hors réseau d’entreprise, préserver un accès support alternatif. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Configuration recommandée et déploiement par étapes

La méthode retenue pour Concevoir les tunnels Always On VPN se déploie par les étapes « Mesurer l’état de départ », « Configurer la population pilote », « Observer les indicateurs », « Décider la généralisation ». Chaque passage produit un résultat vérifiable avant l’ouverture du suivant.

Paramètres, commandes et automatisation

Les commandes et valeurs de cette section servent à vérifier Classer les flux pré/post-logon. Concevoir le user tunnel. Ajouter le device tunnel si justifié. Déployer par ProfileXML versionné. Chaque exemple précise l’état attendu et les éléments à comparer dans le service.

Le contexte d’exécution, les permissions et les effets sur Pre-logon, Sign-in, User tunnel, Core doivent rester explicites lorsque la configuration est automatisée.

$ErrorActionPreference = 'Stop'
try {
  Get-VpnConnection -ErrorAction SilentlyContinue |
    Select-Object Name,ConnectionStatus,TunnelType,SplitTunneling,RememberCredential
  Get-VpnConnection -AllUserConnection -ErrorAction SilentlyContinue |
    Select-Object Name,ConnectionStatus,TunnelType,SplitTunneling,RememberCredential
  Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric |
    Select-Object -First 30 DestinationPrefix,InterfaceAlias,NextHop,RouteMetric
  Get-WinEvent -LogName 'Microsoft-Windows-RasClient/Operational' -MaxEvents 60 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
} catch { Write-Error "Validation VPN impossible : $($_.Exception.Message)"; exit 1 }

Validation, indicateurs et critères GO / NO-GO

La décision repose sur Classer les flux pré/post-logon, Concevoir le user tunnel, Ajouter le device tunnel si justifié et Déployer par ProfileXML versionné. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

• Classer les flux pré/post-logon.
• Concevoir le user tunnel.
• Ajouter le device tunnel si justifié.
• Déployer par ProfileXML versionné.
• Tester réseaux représentatifs
• Mesurer gateway et NPS
• Migrer puis retirer l’ancien VPN

Exploitation, journaux et contrôle continu

La chronologie de Concevoir les tunnels Always On VPN relie Pre-logon, Sign-in, User tunnel, Core. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Classer les flux pré/post-logon. Concevoir le user tunnel. Ajouter le device tunnel si justifié. Déployer par ProfileXML versionné. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Édition, join ou certificat », « Limite device tunnel », « NRPT ou routes » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Classer les flux pré/post-logon.
• Concevoir le user tunnel.
• Ajouter le device tunnel si justifié.
• Déployer par ProfileXML versionné.
• Tester réseaux représentatifs
• Mesurer gateway et NPS
• Migrer puis retirer l’ancien VPN

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour Concevoir les tunnels Always On VPN apparaissent notamment sous la forme Device tunnel absent, Pas de SSTP fallback, DNS incohérent, Deux tunnels instables. La preuve associée indique s’il faut corriger la configuration ou conserver une exception documentée.

Coût de maintien des exceptions

Une exception à Concevoir les tunnels Always On VPN crée une charge récurrente: elle doit être identifiée, surveillée et réévaluée jusqu’à sa suppression. Sans propriétaire ni date de revue, cette charge finit par devenir une configuration parallèle difficile à tester.

Rollback, gestion du changement et points de vigilance

Le rollback de Concevoir les tunnels Always On VPN restaure explicitement l’affectation, la valeur ou l’autorité précédente. Les actions et points de vigilance ci-dessous précisent ce qui doit être contrôlé après ce retour.