> 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-1/how-to/vpn-logs-and-troubleshooting.md).
# Comment gérer les journaux de votre VPN et diagnostiquer les incidents
La console de troubleshooting vous permet de **générer, consulter et télécharger** les logs du tunnel VPN depuis le panneau, et diagnostiquer la plupart des incidents par vous-même.
La clé est de lire le log pour savoir **à quelle phase** la connexion échoue.
> #### 👍 Ce que tu obtiens
>
> Localiser le point exact de la panne (la connexion initiale ou le passage des données) et l’action qui la corrige, sans dépendre du support dans la plupart des cas.
### Avant de commencer
* Avoir accès au panneau avec des autorisations sur l’abonnement réseau.
* Avoir un tunnel VPN créé, qu’il soit opérationnel ou non.
* De façon optionnelle, accès aux logs de l’équipement distant pour les corréler si vous devez aller plus loin.
### Étape 1. Générez et consultez les logs
1. Entrez dans votre abonnement avec VPN et ouvrez **Troubleshooting / Logs**.
2. Clique **Générer des logs**.
3. Dans la console, vous pouvez **voir** les événements de l’échange, **rechercher** des termes, **copier** des fragments et **télécharger** le fichier `.log` pour le vérifier en local.
Termes de recherche recommandés : `error`, `failed`, `proposal`, `AUTH`, `TS_`, `CHILD_SA`, `responding`.
{/\* 📸 CAPTURE 1 · console Troubleshooting / Logs avec le bouton Générer des logs et le moteur de recherche \*/}
> #### 📘 Deux détails pour ne pas vous tromper
>
> * **Fuseau horaire**: les logs affichent l’heure convertie dans votre fuseau horaire, afin que l’horodatage corresponde au moment réel du test et que vous puissiez le comparer avec le log de l’équipement distant.
> * **Rotation par taille**: l’historique est géré par taille, pas par jours. Si vous traquez une panne précise, reproduisez-la et générez les logs juste après.
### Les deux phases de la connexion
Un tunnel site-to-site se monte en deux phases. Savoir dans laquelle il échoue vous mène directement à la cause.
#### Phase 1 — Connexion initiale (IKE)
Les deux extrémités se valident et conviennent de la manière dont elles vont communiquer. Quand tout va bien, le log affiche `IKE_SA ... established`. En cas d’échec, le plus courant est que l’autre extrémité ne réponde pas (connectivité ou ports fermés), que des paramètres de base ne correspondent pas (par exemple le chiffrement) ou que la clé (PSK) ou l’identité ne correspondent pas.
#### Phase 2 — Passage des 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, il apparaît `CHILD_SA ... established`. En cas d’échec, 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 vous voyez `IKE_SA ... established` mais pas `CHILD_SA ... established`, le problème vient des réseaux, des routes ou du pare-feu (Phase 2). Si vous n’arrivez pas à `IKE_SA ... established`, il se situe dans la connexion initiale (Phase 1).
### Interprétez les messages du log
### Checklist de diagnostic
1. Générez des logs et recherchez `error`, `failed`, `proposal`, `AUTH`, `TS_`.
2. Apparaît-il `IKE_SA ... established` ? Si **non**, vous êtes face à un problème de Phase 1 (vous pouvez voir `initiating IKE_SA` sans aller plus loin). Si **oui**, continuez.
3. Apparaît-il `CHILD_SA ... established` ? Si vous voyez `failed to establish CHILD_SA`, il s’agit généralement de réseaux, de routes ou de pare-feu (Phase 2). Si **oui** apparaît, le tunnel est correct ; si malgré cela il n’y a pas de trafic, regardez les routes et les politiques, pas le tunnel.
4. `peer not responding` → vérifiez l’UDP 500/4500 et le pare-feu/NAT.
5. `no proposal chosen` → certains paramètres ne correspondent pas (chiffrements, groupes, durées).
6. `AUTHENTICATION_FAILED` → vérifiez la clé (PSK) ou les certificats et les ID.
7. `TS_UNACCEPTABLE` → vérifiez que les sous-réseaux correspondent exactement des deux côtés.
### Vérifiez depuis le côté client
Les logs vous indiquent la phase ; ces commandes vous confirment la cause depuis un serveur de votre réseau.
Pour la Phase 1, vérifiez la connectivité avec le pair 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érifiez que vous atteignez le sous-réseau distant et qu’il existe une route vers celui-ci :
```bash
ping
ip route
```
```powershell
route print
```
### Quand escalader vers Partenaire Success
Si après ces étapes vous êtes toujours bloqué, l’équipe Partenaire Success vous donne un coup de main. Pour le résoudre au plus vite, envoyez :
* **Du log**: la première erreur qui apparaît, 20 à 30 lignes avant et après pour voir le contexte, et les horodatages tels qu’ils apparaissent.
* **Du tunnel**: version d’IKE (v1/v2/Auto), IP ou FQDN du pair, 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 logs tournent selon la taille, reproduisez la panne et générez les logs juste après : ainsi, le fichier contient exactement ce qu’il faut examiner.
### Conclusion
Avec la console de troubleshooting, vous passez de « le VPN ne fonctionne pas » à « ça échoue en Phase 2 à cause de sous-réseaux qui ne correspondent pas » en quelques minutes. La méthode est toujours la même : localisez si vous arrivez à `IKE_SA established` et à `CHILD_SA established`, et cela vous indique si vous devez regarder la connexion initiale ou le passage des données. À partir de là, le tableau et les commandes vous 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-1/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.
