> For the complete documentation index, see [llms.txt](https://docs.plenit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.plenit.com/fr/productos/servers/how-to/vpn-logs-and-troubleshooting.md).
# 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 \*/}
> #### 📘 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 ... established`apparaît **non**? Si `, tu es dans un problème de Phase 1 (tu peux voir` initiating IKE\_SA **sans aller plus loin). Si**oui
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 :
```bash
ping
nc -vzu 500
nc -vzu 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) :
```powershell
Test-NetConnection
```
Pour la Phase 2, vérifie que tu atteins le sous-réseau distant et qu'il existe une route vers lui :
```bash
ping
ip route
```
```powershell
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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.plenit.com/fr/productos/servers/how-to/vpn-logs-and-troubleshooting.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
