Troubleshooting Always On VPN : du profil Windows à la ressource interne

Résumé opérationnel

Le diagnostic commence par le profil attendu dans la bonne portée. Get-VpnConnection sans AllUserConnection peut masquer un device tunnel pourtant présent, tandis qu’un profil utilisateur n’existe pas sous SYSTEM.

Je corrèle Microsoft-Windows-RasClient/Operational, événements IKE/RemoteAccess, journaux NPS et passerelle à la même tentative. Les codes 800 ou 809 orientent vers le chemin réseau, mais ne dispensent pas de vérifier DNS, ports et protocole.

Après connexion, je poursuis avec adresse, routes, métriques, NRPT, DNS et application. Une session VPN connectée peut parfaitement transporter aucun flux utile.

Le diagnostic commence par le profil attendu dans la bonne portée. Get-VpnConnection sans AllUserConnection peut masquer un device tunnel pourtant présent, tandis qu’un profil utilisateur n’existe pas sous SYSTEM.

Symptôme, contexte et périmètre de l’incident

Je note profil, tunnel user/device, réseau source, heure, message, code, utilisateur et comportement attendu. Je reproduis une seule fois après avoir activé les traces nécessaires, pour éviter une série de tentatives non corrélées.

Je vérifie le profil avec Get-VpnConnection dans la session utilisateur puis avec -AllUserConnection en administration. J’examine serveur, TunnelType, AuthenticationMethod, SplitTunneling et statut sans modifier le profil.

Le besoin opérationnel doit être défini avant de choisir un profil ou un outil. Il faut distinguer le résultat attendu, l’expérience utilisateur, le propriétaire de la configuration et les contrôles qui confirmeront son application. La présence d’un paramètre dans une console ne justifie pas son activation.

L’intention configurée dans le cloud, son applicabilité, l’état reçu par Windows et le résultat observé correspondent à quatre informations différentes. Une affectation réussie, un état vert ou une requête HTTP acceptée ne prouve pas à lui seul que tout le parcours fonctionne.

• Always On VPN, Troubleshooting, RasClient, IKEv2
• postes Windows gérés et services Microsoft officiellement documentés
• validation en laboratoire puis pilote représentatif avant généralisation

Questions à résoudre et méthode de diagnostic

Le diagnostic de « Troubleshooting Always On VPN » commence par le symptôme exact et son horodatage. Plusieurs causes restent possibles tant qu’un log, un état local ou une donnée du service ne les a pas confirmées ou écartées. Une affectation visible dans le portail, un code isolé ou un état ancien ne suffit pas.

La première collecte reste en lecture seule : contexte utilisateur ou SYSTEM, version de Windows et des composants, identifiants de corrélation, événements, logs et état du registre. Aucun cache, certificat, objet ou clé ne doit être supprimé avant cette collecte.

La première phase qui diverge détermine la suite. Une seule cause est corrigée à la fois, puis le scénario initial est rejoué. Un contournement temporaire ne doit pas être présenté comme une correction définitive.

Les heures du portail et du poste, le décalage UTC et les identifiants présents dans plusieurs logs forment une chronologie unique. Deux messages identiques peuvent appartenir à des tentatives différentes. La conclusion indique clairement les faits confirmés, les hypothèses probables et les points qui restent impossibles à vérifier.

• comprendre l’architecture, les dépendances et les limites
• mettre en œuvre un pilote mesurable et reproductible
• construire un diagnostic et un rollback utilisables par l’exploitation

Cartographie du flux à diagnostiquer

Je note profil, tunnel user/device, réseau source, heure, message, code, utilisateur et comportement attendu. Je reproduis une seule fois après avoir activé les traces nécessaires, pour éviter une série de tentatives non corrélées.

Je vérifie le profil avec Get-VpnConnection dans la session utilisateur puis avec -AllUserConnection en administration. J’examine serveur, TunnelType, AuthenticationMethod, SplitTunneling et statut sans modifier le profil.

La résolution DNS publique de la passerelle et la connectivité vers les ports/protocoles requis précèdent l’authentification. IKEv2 derrière NAT, filtrage opérateur ou inspection réseau peut conduire aux erreurs 800/809.

État initial et prérequis de collecte

Je fige l’état du poste avant toute correction : versions, heure, identité, contexte d’exécution, affectations, autorités de gestion et dernier cycle connu. Cette photographie permet de distinguer la cause initiale des effets produits par les essais suivants.

Je vérifie également que le compte, l’appareil, la licence, la connectivité et les composants nécessaires rendent le scénario réellement applicable. Un prérequis absent doit être traité comme une cause potentielle, pas comme un détail de préparation.

• poste pilote et réseau reproductible
• accès aux journaux RasClient
• accès aux logs passerelle et NPS
• profil XML de référence
• inventaire certificats
• routes et DNS attendus
• moyen d’accès hors VPN

Collecte des preuves : journaux, registre et états

La chronologie relie l’heure de la demande, le check-in, l’événement local, la décision du composant et la remontée dans le portail. Conservez l’heure UTC et l’heure locale. Avant tout partage, anonymisez les UPN, DeviceId, TenantId, noms internes, certificats, adresses et contenus métiers.

La collecte initiale reste en lecture seule. Ne videz pas un cache, ne supprimez pas une clé, ne réinitialisez pas un agent et ne forcez pas un enrôlement avant d’avoir capturé les informations utiles. Ces actions changent l’état et peuvent faire disparaître la cause initiale.

Les scripts publiés ici illustrent la collecte décrite dans l’article et restent en lecture seule. Une remédiation doit proposer une simulation, limiter sa cible, expliquer son impact et restaurer l’état précédent. Une opération privilégiée ou à grande échelle exige en plus une validation formelle et un pilote représentatif.

• Qualifier tunnel et portée.
• Confirmer le profil effectif.
• Tester DNS et chemin passerelle.
• Corréler RasClient et gateway.
• Corréler NPS et certificat
• Tester routes/NRPT/DNS
• Reproduire après correction

Investigation pas à pas

Je suis l’ordre réel du traitement et je m’arrête à la première divergence démontrée. Poursuivre malgré une preuve manquante créerait des symptômes secondaires et rendrait la chronologie moins fiable.

Pour chaque étape, je note l’action, l’emplacement, le résultat attendu et la méthode de vérification. Les champs Impact et Retour arrière concernent l’éventuelle correction ; la phase d’observation reste en lecture seule autant que possible.

Fonctionnement détaillé et responsabilités

Je note profil, tunnel user/device, réseau source, heure, message, code, utilisateur et comportement attendu. Je reproduis une seule fois après avoir activé les traces nécessaires, pour éviter une série de tentatives non corrélées.

Je vérifie le profil avec Get-VpnConnection dans la session utilisateur puis avec -AllUserConnection en administration. J’examine serveur, TunnelType, AuthenticationMethod, SplitTunneling et statut sans modifier le profil.

La résolution DNS publique de la passerelle et la connectivité vers les ports/protocoles requis précèdent l’authentification. IKEv2 derrière NAT, filtrage opérateur ou inspection réseau peut conduire aux erreurs 800/809.

• poste pilote et réseau reproductible
• accès aux journaux RasClient
• accès aux logs passerelle et NPS
• profil XML de référence

Configuration, exploitation et cas limites

RasClient/Operational donne l’entrée de connexion, le code et le contexte. Les journaux IKEEXT, RemoteAccess et les traces réseau servent lorsque la négociation IPsec ou SSTP échoue avant RADIUS.

Pour l’authentification certificat, je contrôle chaîne, date, EKU, clé privée, SAN/mapping et révocation. Pour EAP, j’exporte la configuration effective et je vérifie le certificat serveur attendu.

NPS doit recevoir la requête du bon client RADIUS. Un Access-Reject est analysé par Reason Code, policy, groupe, méthode et contraintes ; l’absence d’événement oriente vers la passerelle ou le secret RADIUS.

• Corréler NPS et certificat
• Tester routes/NRPT/DNS
• Reproduire après correction

Lire les états et les résultats

Après Access-Accept, je contrôle adresse attribuée, interface, MTU, routes et métriques. Un préfixe local identique au réseau distant crée un conflit que le VPN ne peut résoudre par authentification.

Je vérifie NRPT et résolution avec Resolve-DnsName sur les espaces internes. Une IP joignable mais un nom en échec est un incident DNS ; une résolution correcte sans TCP est un incident de route ou de pare-feu.

La correction est testée sur le réseau initial puis sur un second réseau. Je valide reconnexion après veille, bascule Wi-Fi/Ethernet et renouvellement du certificat avant clôture.

Une configuration décrit ce qui devrait arriver. L’inventaire montre un état observé à un instant donné, tandis qu’un log d’exécution indique ce que le composant a réellement tenté. Les horodatages et les contextes doivent correspondre avant de relier ces informations.

Les états non applicable, pending, conflict, error et success doivent rester séparés. L’absence d’un poste dans un rapport ne permet pas de conclure : il peut être hors ligne, non éligible, non ciblé, en retard de télémétrie ou exclu de la collecte.

Pilote, généralisation et maintien en conditions opérationnelles

Le pilote couvre plusieurs modèles matériels, versions de Windows, profils réseau, populations utilisateur et exceptions métier. Une cohorte témoin aide à distinguer l’effet du changement d’une évolution globale du service, d’une mise à jour applicative ou d’un incident réseau.

Les critères GO sont définis avant le début : couverture, taux de succès, délai de convergence, incidents, tickets support, régressions et temps de rollback. Une moyenne satisfaisante ne masque pas un sous-groupe en échec ; les résultats sont donc segmentés par version, modèle, site et mode de gestion.

Les cas négatifs sont testés volontairement : appareil hors ligne, licence absente, identité non éligible, règle non applicable, réseau filtré et retour arrière. Un design exploitable doit échouer de manière visible, sûre et compréhensible pour le support.

Après généralisation, les exceptions, permissions, versions de profil et dépendances doivent être revues régulièrement. Le service cloud et Windows évoluent ; une décision correcte aujourd’hui doit rester traçable et être revalidée lorsqu’un prérequis ou une interface change.

Commandes et scripts de diagnostic en lecture seule

Les commandes de cette section servent à inventorier, corréler ou illustrer. Les scripts de diagnostic restent en lecture seule : ils arrêtent leur exécution en cas d’erreur et ne modifient volontairement aucun paramètre du poste.

Je vérifie toujours le contexte d’exécution. Une commande lancée dans la session utilisateur n’observe pas forcément les mêmes certificats, variables, chemins ou ruches de registre qu’un processus exécuté sous SYSTEM.

# Exemple de collecte en lecture seule — à adapter avant utilisation
$ErrorActionPreference = 'Stop'
try {
  Get-VpnConnection -ErrorAction SilentlyContinue
  Get-VpnConnection -AllUserConnection -ErrorAction SilentlyContinue
  Get-WinEvent -LogName 'Microsoft-Windows-RasClient/Operational' -MaxEvents 160 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
  Get-NetIPConfiguration; Get-DnsClientNrptPolicy -Effective
} catch { Write-Error "Collecte AOVPN impossible : $($_.Exception.Message)"; exit 1 }

Arbre de décision : symptômes, causes et corrections

Le symptôme oriente l’enquête, mais ne sélectionne jamais seul une correction. Je n’applique la réponse proposée que lorsque la preuve recherchée confirme la cause et que les autres hypothèses importantes sont écartées.

Après correction, je rejoue exactement le scénario initial avec les mêmes points de mesure. Si le symptôme se déplace vers une autre phase, je poursuis l’analyse au lieu de déclarer l’incident résolu.

Validation de la correction et critères de clôture

Je valide le comportement local, puis la remontée dans le service. Les délais du portail sont pris en compte, mais l’état attendu sur le poste doit être vérifiable immédiatement ou selon le cycle officiellement documenté.

La clôture exige un résultat reproductible, l’absence de régression, une cause documentée et une correction minimale. La généralisation reste NO-GO si le résultat varie entre deux postes comparables ou si le retour arrière n’est pas maîtrisé.

• Qualifier tunnel et portée.
• Confirmer le profil effectif.
• Tester DNS et chemin passerelle.
• Corréler RasClient et gateway.
• Corréler NPS et certificat
• Tester routes/NRPT/DNS
• Reproduire après correction

Retour arrière, escalade et points de vigilance

Le rollback restaure l’état ou l’autorité précédente et doit lui aussi être vérifié sur le poste. Retirer une affectation sans confirmer la convergence locale ne constitue pas un retour arrière terminé.

Si la cause reste indéterminée, je conserve la chronologie, les journaux anonymisés, les identifiants de corrélation et la liste des hypothèses déjà écartées avant l’escalade. Je n’efface jamais les preuves pour tenter une réparation générique.