Comment gérer les journaux de votre VPN et diagnostiquer les incidents

La console de dépannage te permet de générer, consulter et télécharger les journaux du tunnel VPN depuis le panneau, et diagnostiquer la plupart des incidents par toi-même.

La clé est de lire le journal pour savoir à quelle phase la connexion échoue.

👍 Ce que tu obtiens

Localiser le point exact de l'échec (la connexion initiale ou le passage de données) et l'action qui le corrige, sans dépendre du support dans la plupart des cas.

Avant de commencer

• Accès au panneau avec des Autorisations sur l'Abonnement de Réseau.
• Avoir un tunnel VPN créé, qu'il soit opérationnel ou non.
• De manière facultative, accès aux journaux de l'équipement distant pour corréler si tu dois aller plus loin.

Étape 1. Génère et consulte les journaux

1. Entre dans ton Abonnement VPN et ouvre Dépannage / Journaux.
2. Clique sur Générer des journaux.
3. Dans la console, tu peux voir les Événements de l'échange, chercher des termes, copier des extraits et télécharger le fichier .log pour le revoir en local.

Termes de recherche recommandés : error, failed, proposal, AUTH, TS_, CHILD_SA, responding.

{/* 📸 CAPTURE 1 · console Dépannage / Journaux avec le bouton Générer des journaux et le moteur de recherche */}

Console de dépannage avec la génération et la recherche de journaux

📘 Deux détails pour ne pas te tromper

• Fuseau horaire: les journaux affichent l'heure convertie dans ton fuseau horaire, afin que l'horodatage corresponde au moment réel du test et que tu puisses le comparer avec le journal de l'équipement distant.
• Rotation par taille: l'historique est géré par taille, pas par jours. Si tu traques un incident précis, reproduis-le et génère les journaux juste après.

Les deux phases de la connexion

Un tunnel site-to-site se met en place en deux phases. Savoir dans laquelle il échoue te mène directement à la cause.

Phase 1 — Connexion initiale (IKE)

Les deux extrémités se valident et s'accordent sur la manière de communiquer. Quand tout va bien, le journal affiche IKE_SA ... established. Si ça échoue, le plus courant est que l'autre extrémité ne répond pas (connectivité ou ports fermés), que les paramètres de base ne correspondent pas (par exemple le Chiffrement) ou que la clé (PSK) ou l'identité ne concordent pas.

Phase 2 — Passage de données (IPsec / CHILD_SA)

Une fois la connexion initiale prête, le tunnel par lequel passe le trafic réel est créé. Quand tout va bien, apparaît CHILD_SA ... established. Si ça échoue, le plus courant est que les sous-réseaux ne correspondent pas des deux côtés, qu'un Pare-feu ou une politique bloque le trafic, ou qu'il manque des routes vers le réseau distant.

📘 Règle rapide

Si tu vois IKE_SA ... established mais pas CHILD_SA ... established, le problème vient des réseaux, des routes ou du Pare-feu (Phase 2). Si tu n'atteins pas IKE_SA ... established, c'est dans la connexion initiale (Phase 1).

Interprète les messages du journal

Checklist de diagnostic

1. Génère des journaux et cherche error, failed, proposal, AUTH, TS_.
2. Est-ce que IKE_SA ... establishedapparaît non? Si , tu es dans un problème de Phase 1 (tu peux voir initiating IKE_SA sans aller plus loin). Sioui
3. Est-ce que CHILD_SA ... established, continue. failed to establish CHILD_SA, c'est souvent des réseaux, des routes ou le Pare-feu (Phase 2). Si sans aller plus loin). Si apparaît, le tunnel est bon ; si malgré tout il n'y a pas de trafic, regarde les routes et les politiques, pas le tunnel.
4. peer not responding → vérifie UDP 500/4500 et Pare-feu/NAT.
5. no proposal chosen → il y a des paramètres qui ne correspondent pas (Chiffrement, groupes, temporisations).
6. AUTHENTICATION_FAILED → vérifie la clé (PSK) ou les certificats et les ID.
7. TS_UNACCEPTABLE → vérifie que les sous-réseaux correspondent exactement des deux côtés.

Vérifie depuis le côté client

Les journaux t'indiquent la phase ; ces commandes te confirment la cause depuis un serveur de ton Réseau.

Pour la Phase 1, vérifie la connectivité avec le peer et que les ports IPsec sont ouverts. Sous Linux :

ping <IP-PEER>
nc -vzu <IP-PEER> 500
nc -vzu <IP-PEER> 4500

Sous Windows, connectivité de base depuis PowerShell (les ports UDP 500/4500 doivent être ouverts dans le Pare-feu et le NAT des deux côtés) :

Test-NetConnection <IP-PEER>

Pour la Phase 2, vérifie que tu atteins le sous-réseau distant et qu'il existe une route vers lui :

ping <IP-DANS-LE-SOUS-RÉSEAU-DISTANT>
ip route

route print

Quand faire remonter à Partenaire Success

Si, après ces étapes, tu es toujours bloqué, l'équipe de Partenaire Success t'aide. Pour résoudre cela au plus vite, envoie :

• Du journal: la première erreur qui apparaît, 20 à 30 lignes avant et après pour voir le contexte, et les horodatages tels qu'ils sortent.
• Du tunnel: version d'IKE (v1/v2/Auto), IP ou FQDN du peer, sous-réseaux local et distant en CIDR, s'il y a un NAT ou un Pare-feu entre les deux, et l'heure exacte du test.

Comme les journaux tournent par taille, reproduis l'incident et génère les journaux juste après : ainsi le fichier contient exactement ce qu'il faut regarder.

Conclusion

Avec la console de dépannage, tu passes de « le VPN ne fonctionne pas » à « échec en Phase 2 à cause de sous-réseaux qui ne correspondent pas » en quelques minutes. La méthode est toujours la même : localise si tu atteins IKE_SA established et CHILD_SA established, et cela te dit si tu dois examiner la connexion initiale ou le passage de données. À partir de là, le tableau et les commandes te mènent à la cause.