VPNv2 CSP : comprendre les profils VPN Windows gérés par Intune

L’essentiel

VPNv2 expose des nœuds de gestion par profil sous une portée utilisateur ou appareil. Intune peut configurer les paramètres natifs ou distribuer un ProfileXML lorsque la granularité exige des options avancées.

Le profil combine serveur, type de tunnel, méthode d’authentification, AlwaysOn, routes, DNS, NRPT, triggers et filtres. Une valeur XML valide syntaxiquement peut rester incohérente avec le concentrateur ou le contexte Windows.

Je vérifie séparément la présence du profil avec Get-VpnConnection, la configuration CSP, les événements RasClient et la connectivité finale. Un profil présent ne prouve pas qu’un tunnel a été négocié.

VPNv2 expose des nœuds de gestion par profil sous une portée utilisateur ou appareil. Intune peut configurer les paramètres natifs ou distribuer un ProfileXML lorsque la granularité exige des options avancées.

Pourquoi cette technologie existe

Le chemin VPNv2 contient un nom de profil encodé et des branches de portée User ou Device. Le choix de portée détermine le contexte de stockage, la visibilité de Get-VpnConnection et le moment où la connexion peut démarrer.

ProfileXML regroupe des options qui peuvent aussi exister comme nœuds CSP dédiés. Je maintiens une source unique et versionnée, car plusieurs profils portant des noms proches ou plusieurs outils écrivant le même profil produisent des comportements difficiles à expliquer.

NativeProfile décrit Servers, RoutingPolicyType, NativeProtocolType, Authentication et cryptographie. IKEv2 est essentiel pour le device tunnel; le user tunnel peut aussi employer SSTP ou une sélection automatique selon l’architecture.

Architecture du VPNv2 CSP s’appuie sur la chaîne MDM → PhoneBook → RasMan → Network. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont version et édition Windows compatibles, passerelle VPN documentée, méthode d’authentification prête, PKI et confiance si certificats. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Profil absent, Profil présent, pas de trigger et Erreur auth. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. MDM ouvre la séquence: Écrit le profil via VPNv2 CSP. PhoneBook prend ensuite le relais: Windows persiste portée et paramètres. Le traitement se poursuit avec RasMan, où Déclenche et négocie le tunnel. Enfin, Network ferme la boucle: Applique routes, DNS et filtres. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Profil absent » conduit d’abord à vérifier MDM et Get-VpnConnection, car la cause possible est Portée ou CSP en erreur. Pour « Profil présent, pas de trigger », la preuve utile devient Événements RasMan. Les cas « Erreur auth » et « Tunnel connecté, ressource absente » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont Architecture du VPNv2 CSP expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions version et édition Windows compatibles, passerelle VPN documentée, méthode d’authentification prête, PKI et confiance si certificats doivent être réunies en même temps. La validation porte ensuite sur Définir portée et nom stable, Versionner le ProfileXML, Déployer à un appareil pilote et Contrôler Get-VpnConnection. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

Le chemin VPNv2 contient un nom de profil encodé et des branches de portée User ou Device. Le choix de portée détermine le contexte de stockage, la visibilité de Get-VpnConnection et le moment où la connexion peut démarrer.

ProfileXML regroupe des options qui peuvent aussi exister comme nœuds CSP dédiés. Je maintiens une source unique et versionnée, car plusieurs profils portant des noms proches ou plusieurs outils écrivant le même profil produisent des comportements difficiles à expliquer.

NativeProfile décrit Servers, RoutingPolicyType, NativeProtocolType, Authentication et cryptographie. IKEv2 est essentiel pour le device tunnel; le user tunnel peut aussi employer SSTP ou une sélection automatique selon l’architecture.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose version et édition Windows compatibles, passerelle VPN documentée, méthode d’authentification prête, PKI et confiance si certificats, routes et espaces DNS recensés. Ces conditions permettent de distinguer une limite de Architecture du VPNv2 CSP d’un scénario simplement non éligible.

• version et édition Windows compatibles
• passerelle VPN documentée
• méthode d’authentification prête
• PKI et confiance si certificats
• routes et espaces DNS recensés
• profil XML validé
• absence d’autorité concurrente

Cycle de fonctionnement, étape par étape

Le cycle de Architecture du VPNv2 CSP traverse MDM → PhoneBook → RasMan → Network. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Architecture du VPNv2 CSP, les étapes « Identifier les composants », « Observer le traitement », « Relier les états », « Valider le modèle » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé de Architecture du VPNv2 CSP

Le chemin VPNv2 contient un nom de profil encodé et des branches de portée User ou Device. Le choix de portée détermine le contexte de stockage, la visibilité de Get-VpnConnection et le moment où la connexion peut démarrer.

ProfileXML regroupe des options qui peuvent aussi exister comme nœuds CSP dédiés. Je maintiens une source unique et versionnée, car plusieurs profils portant des noms proches ou plusieurs outils écrivant le même profil produisent des comportements difficiles à expliquer.

NativeProfile décrit Servers, RoutingPolicyType, NativeProtocolType, Authentication et cryptographie. IKEv2 est essentiel pour le device tunnel; le user tunnel peut aussi employer SSTP ou une sélection automatique selon l’architecture.

• version et édition Windows compatibles
• passerelle VPN documentée
• méthode d’authentification prête
• PKI et confiance si certificats

Traitement, exploitation et cas limites de Architecture du VPNv2 CSP

AlwaysOn et AlwaysOnActive ne sont pas identiques: le premier active le comportement toujours connecté, le second contrôle l’état actif initial. Les triggers par application ou nom peuvent provoquer un lancement même si l’utilisateur n’a pas cliqué.

Route et DomainNameInformation déterminent le trafic qui traverse le tunnel et la résolution de noms. Split tunnel, force tunnel, NRPT et métriques doivent être conçus ensemble pour éviter fuite DNS, asymétrie ou perte d’accès Internet.

TrafficFilter et AppTrigger restreignent les flux sortants ou lient le tunnel à des applications. Lorsque des traffic filters sont actifs, le trafic entrant depuis le réseau d’entreprise vers le client est bloqué selon la documentation Always On VPN.

• Déclencher et lire RasClient
• Tester routes et DNS
• Tester suppression et recréation

Lire les états propres à Architecture du VPNv2 CSP

Le profil peut référencer EAP XML, certificats, noms d’issuer et EKU. Le choix réel du certificat appartient au moteur d’authentification; je vérifie magasin, clé, chaîne et compatibilité avec la passerelle.

Windows persiste les connexions dans des phonebooks utilisateur ou tous utilisateurs. Ces fichiers et certaines clés sont des détails d’observation; je préfère les cmdlets VPN et le CSP pour les changements supportés.

Les événements RasClient/Operational et RemoteAccess montrent négociation et erreurs. Je complète par ipconfig, route print, Get-DnsClientNrptPolicy et Test-NetConnection pour distinguer tunnel, routage, DNS et application.

• Profil absent — MDM et Get-VpnConnection
• Profil présent, pas de trigger — Événements RasMan
• Erreur auth — RasClient et passerelle
• Tunnel connecté, ressource absente — Table de routes/NRPT

Pilote et suivi opérationnel de Architecture du VPNv2 CSP

Le pilote couvre le périmètre Windows, VPNv2 CSP, Intune, ProfileXML et contrôle Définir portée et nom stable. Versionner le ProfileXML. Déployer à un appareil pilote. Les résultats sont segmentés selon les populations réellement concernées par Architecture du VPNv2 CSP.

Les cas d’échec « Profil absent », « Profil présent, pas de trigger », « Erreur auth » 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 encoder correctement le nom du profil CSP, ne pas modifier les phonebooks comme méthode de gestion, tester SYSTEM et utilisateur, une connexion établie ne valide pas chaque route. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Définir portée et nom stable. Versionner le ProfileXML. Déployer à un appareil pilote. Contrôler Get-VpnConnection. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Architecture du VPNv2 CSP, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  Get-VpnConnection -AllUserConnection -ErrorAction SilentlyContinue
  Get-VpnConnection -ErrorAction SilentlyContinue
  Get-NetRoute | Sort-Object InterfaceMetric,DestinationPrefix | Select-Object -First 80
  Get-DnsClientNrptPolicy -Effective
} catch { Write-Error "Inventaire VPN impossible : $($_.Exception.Message)"; exit 1 }

Observabilité : où lire l’état réel

La chronologie de Architecture du VPNv2 CSP relie MDM, PhoneBook, RasMan, Network. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Définir portée et nom stable. Versionner le ProfileXML. Déployer à un appareil pilote. Contrôler Get-VpnConnection. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Portée ou CSP en erreur », « AlwaysOnActive ou trigger », « EAP ou certificat » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Définir portée et nom stable.
• Versionner le ProfileXML.
• Déployer à un appareil pilote.
• Contrôler Get-VpnConnection.
• Déclencher et lire RasClient
• Tester routes et DNS
• Tester suppression et recréation

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Définir portée et nom stable, Versionner le ProfileXML, Déployer à un appareil pilote et Contrôler Get-VpnConnection. Ces contrôles relient la configuration du service au résultat réellement observé.

• Définir portée et nom stable.
• Versionner le ProfileXML.
• Déployer à un appareil pilote.
• Contrôler Get-VpnConnection.
• Déclencher et lire RasClient
• Tester routes et DNS
• Tester suppression et recréation

Limites, modes de panne et lecture des erreurs

Les écarts connus de Architecture du VPNv2 CSP incluent Profil absent, Profil présent, pas de trigger, Erreur auth, Tunnel connecté, ressource absente. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Architecture du VPNv2 CSP commence sur le périmètre Windows, VPNv2 CSP, Intune, ProfileXML, Under the Hood — MDM, PhoneBook, RasMan, Network, version et édition Windows compatibles, passerelle VPN documentée, méthode d’authentification prête. Les limites et actions de réversibilité ci-dessous cadrent la progression.