OpenVPN en RoadWarrior : problème de routes ?
Gorkk
Messages postés
23
Statut
Membre
-
Peterpan69007 -
Peterpan69007 -
Bonjour,
Je configure actuellement OpenVPN en RoadWarrior (un serveur, plusieurs clients).
Pour commencer voici une topologie de mon réseau : topologie du réseau (le serveur est en 192.168.125.253)
Le réseau OpenVPN est sur 10.8.0.0/255.255.255.0
Les machines du réseau local sont en DHCP et DNS automatique, avec le modem / routeur comme passerelle, et je n'ai aucun contrôle direct sur le routeur (il faut passer par FT pour modifier la configuration). Ces derniers jours, j'ai fait modifier par FT la configuration du routeur pour ajouter :
- un forward du port 1194 en UDP accédé par une de nos IPs supplémentaires vers le serveur OpenVPN (192.168.125.253)
- une route statique pour envoyer le trafic vers le réseau 10.8.0.0/255.255.255.0 sur le serveur OpenVPN (pour que les ordinateurs du LAN soient envoyés sur le serveur OpenVPN lorsqu''ils veulent contacter un client VPN).
Je fais mes tests en :
- me connectant avec VNC par un tunnel SSH (sur port non standard redirigé sur ma machine personnelle) à mon ordinateur personnel chez moi depuis mon poste de travail sur le LAN (192.168.125.mmm)
- me connectant au VPN depuis mon ordinateur personnel (il est lui-même derrière un routeur, avec comme IP privée 192.168.0.16 (mon réseau local est en 192.168.0.0/255.255.255.0), et n'ayant pas d'IP fixe, j'y accède (pour le tunnel SSH) sur un domaine DynDNS (l'IP associée étant mise à jour par un autre ordinateur du réseau local), on l'appellera chez.moi si nécessaire.
D'autre part je fais également quelques tests en me connectant directement au VPN depuis mon poste sur le LAN, mais là y a des blocages supplémentaires : tout d'abord quand je me connecte par l'IP publique spécifique au VPN (différente donc de mon IP de sortie sur le net), l'authentification TLS timeout, donc je dois utiliser l'IP privée.
Le serveur VPN tourne sous Windows Server 2003 (et mon ordinateur personnel qui s'y connecte sous Windows Vista 64, mon poste sur le LAN étant sous XP SP2), et gère le domaine Active Directory mon.domaine (ce n'est bien sûr par le nom réel, toutefois c'est un domaine AD pré-Windows 2000, étant donné que ce n'est pas un domaine internet (uniquement local donc).
J'en arrive à mes problèmes, qui sont a priori causés par une mauvaise configuration des routes :
1/ lorsque je me connecte depuis mon poste sur le LAN (par l'IP privée du serveur donc) :
- je ne ping pas le serveur, que ce soit sur l'adresse VPN 10.8.0.1 ou sur l'adresse LAN, ou encore par son nom
- je ne ping plus aucune machine du LAN non plus (ni le modem / routeur d'ailleurs)
- en conséquence je perds ma connexion bureau à distance avec le serveur
- la connexion VPN se retrouve assez rapidement interrompue aussi, avec des timeouts à la reconnexion automatique (pour le keepalive a priori)
- par contre je conserve l'accès à internet
- mais je perds mon tunnel SSH vers ma machine personnelle - en fait pas toujours, c'est bizarre ;) - (toutefois je peux en rouvrir un - et le serveur SSH voit bien toujours la même IP de connexion)
2/ lorsque je me connecte depuis ma machine personnelle distante :
- je ping le serveur sur son IP VPN et LAN entreprise, ainsi que sur son nom complet (serveur.mon.domaine)
- je ne ping rien sur le LAN entreprise (il faudrait que je rajoute des routes locales pour ça a priori, mais tous mes essais ont été voués à l'échec, et ont le plus souvent mis le client distant dans la même situation que le client local : impossible de pinger le serveur bien qu'y étant connecté).
- par contre un tracert sur l'adresse locale du serveur (192.168.125.253) timeout et ne donne rien (sur 10.8.0.1 ça passe bien sûr, en un seul saut ;)).
- je conserve mon accès internet
- je perds mon tunnel SSH et je ne peux pas en rouvrir un depuis mon poste sur le réseau entreprise (ça rend les tests quelque peu difficiles, il faut que je me programme un reboot et quelques batchs de ping/traceroute avant d'activer le VPN pour pouvoir y réaccéder après reboot.
Dans les deux cas la connexion auprès du serveur VPN est acceptée et les routes demandées (avec push) créées.
En ce qui concerne la config, j'avais rajouté également une authentification avec les comptes domaine pour activer la connexion VPN avec ce script VBS qui marche bien, je l'ai désactivé le temps de résoudre mes autres problèmes.
Au niveau serveur, j'ai ceci :
Et au niveau client :
(les deux dernières lignes sont supposées être pour résoudre un problème d'ajout des rroutes sous Vista, mais ça a l'air d'avoir marché sans)
Où yyy.yyy.yyy.yyy est l'IP publique dédiée du modem / routeur dont les connexions UDP 1194 sont redirigées sur le serveur VPN (pour les tests depuis le poste de travail sur le LAN entreprise, je dois mettre l'IP privée du serveur 192.168.125.253).
Pour les routes :
- sur le serveur :
- sur le client distant :
Est-ce que quelqu'un aurait des suggestions donc pour résoudre mes problèmes d'accès au reste du LAN depuis le client distant (quelles routes ajouter dans le fichier de config du serveur ?) ? D'ailleurs a vue de nez les clients ne sont pas visibles depuis le serveur quand ils sont connectés (mais difficile de tester dans de bonnes conditions cependant).
De même, est-ce que quelqu'un aurait une suggestion de modification de la configuration pour que je puisse conserver mon tunnel SSH lorsque je connecte le VPN, ou du moins que je puisse m'y reconnecter ? Autant cette situation ne se reproduira probablement pas en production, autant si ça merde pour le tunnel SSH, il y a peut-être d'autres situations où ça ne fonctionnera pas correctement, et ça je préférerais éviter. De plus ça me permettrait aussi de tester voir si je peux accéder au répertoires partagés du serveur avec \\serveur\nomPartage, parce que je vais en avoir besoin (pour l'utilisation de certaines applications utilisant une base de donnée stockée sur le serveur et dont le chemin est définit a priori sous la forme \\serveur\nomPartage (le chemin se définit en parcourant les répertoires à la recherche de celui qu'on utilisera, avec l'interface de recherche d'emplacement de sauvegarde classique de Windows, et tous les utilisateurs VPN doivent pouvoir utiliser l'application sans modification de configuration à la fois quand ils sont dans les locaux et quand ils sont à distance).
Enfin, si quelqu'un a une idée pour :
- permettre la connexion fonctionnelle au VPN depuis le réseau local sur l'adresse IP publique (ce serait le mieux)
ou
- permettre la connexion fonctionnelle au VPN depuis le réseau local sur l'adresse IP privée
ou même encore
- avoir une configuration différente (un réseau VPN différent) pour une connexion au VPN depuis le LAN
ça m'intéresse aussi ;)
Merci d'avance (et désolé pour le long pavé, mais j'ai préféré donner d'emblée un maximum d'informations).
Note : les clients lancent le VPN avec OpenVPN Gui sans utiliser le service (lancé en tant qu'administrateur puisque c'est nécessaire pour OpenVPN), le serveur utilise le service en démarrage automatique (avec le Gui configuré pour ne piloter que le service pour une administration plus simple).
PS : je vais probablement refaire un test avec l'identification sur AD - le dernier n'était pas avec cette configuration - pour être sûr mais normalement le comportement restera le même (puisque lors de mes tests précédents ça ne changeait rien au comportement et que l'authentification marchait correctement).
Je configure actuellement OpenVPN en RoadWarrior (un serveur, plusieurs clients).
Pour commencer voici une topologie de mon réseau : topologie du réseau (le serveur est en 192.168.125.253)
Le réseau OpenVPN est sur 10.8.0.0/255.255.255.0
Les machines du réseau local sont en DHCP et DNS automatique, avec le modem / routeur comme passerelle, et je n'ai aucun contrôle direct sur le routeur (il faut passer par FT pour modifier la configuration). Ces derniers jours, j'ai fait modifier par FT la configuration du routeur pour ajouter :
- un forward du port 1194 en UDP accédé par une de nos IPs supplémentaires vers le serveur OpenVPN (192.168.125.253)
- une route statique pour envoyer le trafic vers le réseau 10.8.0.0/255.255.255.0 sur le serveur OpenVPN (pour que les ordinateurs du LAN soient envoyés sur le serveur OpenVPN lorsqu''ils veulent contacter un client VPN).
Je fais mes tests en :
- me connectant avec VNC par un tunnel SSH (sur port non standard redirigé sur ma machine personnelle) à mon ordinateur personnel chez moi depuis mon poste de travail sur le LAN (192.168.125.mmm)
- me connectant au VPN depuis mon ordinateur personnel (il est lui-même derrière un routeur, avec comme IP privée 192.168.0.16 (mon réseau local est en 192.168.0.0/255.255.255.0), et n'ayant pas d'IP fixe, j'y accède (pour le tunnel SSH) sur un domaine DynDNS (l'IP associée étant mise à jour par un autre ordinateur du réseau local), on l'appellera chez.moi si nécessaire.
D'autre part je fais également quelques tests en me connectant directement au VPN depuis mon poste sur le LAN, mais là y a des blocages supplémentaires : tout d'abord quand je me connecte par l'IP publique spécifique au VPN (différente donc de mon IP de sortie sur le net), l'authentification TLS timeout, donc je dois utiliser l'IP privée.
Le serveur VPN tourne sous Windows Server 2003 (et mon ordinateur personnel qui s'y connecte sous Windows Vista 64, mon poste sur le LAN étant sous XP SP2), et gère le domaine Active Directory mon.domaine (ce n'est bien sûr par le nom réel, toutefois c'est un domaine AD pré-Windows 2000, étant donné que ce n'est pas un domaine internet (uniquement local donc).
J'en arrive à mes problèmes, qui sont a priori causés par une mauvaise configuration des routes :
1/ lorsque je me connecte depuis mon poste sur le LAN (par l'IP privée du serveur donc) :
- je ne ping pas le serveur, que ce soit sur l'adresse VPN 10.8.0.1 ou sur l'adresse LAN, ou encore par son nom
- je ne ping plus aucune machine du LAN non plus (ni le modem / routeur d'ailleurs)
- en conséquence je perds ma connexion bureau à distance avec le serveur
- la connexion VPN se retrouve assez rapidement interrompue aussi, avec des timeouts à la reconnexion automatique (pour le keepalive a priori)
- par contre je conserve l'accès à internet
- mais je perds mon tunnel SSH vers ma machine personnelle - en fait pas toujours, c'est bizarre ;) - (toutefois je peux en rouvrir un - et le serveur SSH voit bien toujours la même IP de connexion)
2/ lorsque je me connecte depuis ma machine personnelle distante :
- je ping le serveur sur son IP VPN et LAN entreprise, ainsi que sur son nom complet (serveur.mon.domaine)
- je ne ping rien sur le LAN entreprise (il faudrait que je rajoute des routes locales pour ça a priori, mais tous mes essais ont été voués à l'échec, et ont le plus souvent mis le client distant dans la même situation que le client local : impossible de pinger le serveur bien qu'y étant connecté).
- par contre un tracert sur l'adresse locale du serveur (192.168.125.253) timeout et ne donne rien (sur 10.8.0.1 ça passe bien sûr, en un seul saut ;)).
- je conserve mon accès internet
- je perds mon tunnel SSH et je ne peux pas en rouvrir un depuis mon poste sur le réseau entreprise (ça rend les tests quelque peu difficiles, il faut que je me programme un reboot et quelques batchs de ping/traceroute avant d'activer le VPN pour pouvoir y réaccéder après reboot.
Dans les deux cas la connexion auprès du serveur VPN est acceptée et les routes demandées (avec push) créées.
En ce qui concerne la config, j'avais rajouté également une authentification avec les comptes domaine pour activer la connexion VPN avec ce script VBS qui marche bien, je l'ai désactivé le temps de résoudre mes autres problèmes.
Au niveau serveur, j'ai ceci :
port 1194 proto udp dev tun dev-node "TAPDeviceName" mode server tls-server tun-mtu 1500 mssfix persist-key persist-tun ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh1024.pem tls-auth ta.key 0 # This file is secret server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt cipher BF-CBC comp-lzo max-clients 100 status openvpn-status.log crl-verify crl.pem push "route 192.168.125.0 255.255.255.0" #route to company network push "dhcp-option DOMAIN tavref.local" #push the DNS domain suffix push "dhcp-option DNS 192.168.125.253" #push DNS entries to client ;push "dhcp-option WINS 192.168.125.253" #push WINS entries to client (to get shared folders browsing) push "route 10.8.0.0 255.255.255.0" # add route to protected network keepalive 10 120 verb 3 ;auth-user-pass-verify Auth4OpenVPN.vbs via-env
Et au niveau client :
client dev tun dev-node "TAPDeviceName" proto udp remote yyy.yyy.yyy.yyy 1194 resolv-retry infinite nobind tls-client persist-key persist-tun ca ca.crt cert client.crt key client.key ns-cert-type server tls-auth ta.key 1 cipher BF-CBC pull comp-lzo verb 3 mute 5 mute-replay-warnings # additionnal authentification with active directory credentials ;auth-user-pass ;auth-retry interact # fixing add route error in Vista ;route-method exe ;route-delay 2
(les deux dernières lignes sont supposées être pour résoudre un problème d'ajout des rroutes sous Vista, mais ça a l'air d'avoir marché sans)
Où yyy.yyy.yyy.yyy est l'IP publique dédiée du modem / routeur dont les connexions UDP 1194 sont redirigées sur le serveur VPN (pour les tests depuis le poste de travail sur le LAN entreprise, je dois mettre l'IP privée du serveur 192.168.125.253).
Pour les routes :
- sur le serveur :
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.125.254 192.168.125.253 20
10.8.0.0 255.255.255.252 10.8.0.1 10.8.0.1 30
10.8.0.0 255.255.255.0 10.8.0.2 10.8.0.1 1
10.8.0.1 255.255.255.255 127.0.0.1 127.0.0.1 30
10.255.255.255 255.255.255.255 10.8.0.1 10.8.0.1 30
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.125.0 255.255.255.0 192.168.125.253 192.168.125.253 20
192.168.125.253 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.125.255 255.255.255.255 192.168.125.253 192.168.125.253 20
224.0.0.0 240.0.0.0 10.8.0.1 10.8.0.1 30
224.0.0.0 240.0.0.0 192.168.125.253 192.168.125.253 20
255.255.255.255 255.255.255.255 10.8.0.1 10.8.0.1 1
255.255.255.255 255.255.255.255 192.168.125.253 192.168.125.253 1
Passerelle par défaut : 192.168.125.254
- sur le client distant :
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.16 276
10.8.0.0 255.255.255.0 10.8.0.9 10.8.0.10 30
10.8.0.1 255.255.255.255 10.8.0.9 10.8.0.10 30
10.8.0.8 255.255.255.252 On-link 10.8.0.10 286
10.8.0.10 255.255.255.255 On-link 10.8.0.10 286
10.8.0.11 255.255.255.255 On-link 10.8.0.10 286
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.0.0 255.255.255.0 On-link 192.168.0.16 276
192.168.0.16 255.255.255.255 On-link 192.168.0.16 276
192.168.0.255 255.255.255.255 On-link 192.168.0.16 276
192.168.125.0 255.255.255.0 10.8.0.9 10.8.0.10 30
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 10.8.0.10 286
224.0.0.0 240.0.0.0 On-link 192.168.0.16 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 10.8.0.10 286
255.255.255.255 255.255.255.255 On-link 192.168.0.16 276
Est-ce que quelqu'un aurait des suggestions donc pour résoudre mes problèmes d'accès au reste du LAN depuis le client distant (quelles routes ajouter dans le fichier de config du serveur ?) ? D'ailleurs a vue de nez les clients ne sont pas visibles depuis le serveur quand ils sont connectés (mais difficile de tester dans de bonnes conditions cependant).
De même, est-ce que quelqu'un aurait une suggestion de modification de la configuration pour que je puisse conserver mon tunnel SSH lorsque je connecte le VPN, ou du moins que je puisse m'y reconnecter ? Autant cette situation ne se reproduira probablement pas en production, autant si ça merde pour le tunnel SSH, il y a peut-être d'autres situations où ça ne fonctionnera pas correctement, et ça je préférerais éviter. De plus ça me permettrait aussi de tester voir si je peux accéder au répertoires partagés du serveur avec \\serveur\nomPartage, parce que je vais en avoir besoin (pour l'utilisation de certaines applications utilisant une base de donnée stockée sur le serveur et dont le chemin est définit a priori sous la forme \\serveur\nomPartage (le chemin se définit en parcourant les répertoires à la recherche de celui qu'on utilisera, avec l'interface de recherche d'emplacement de sauvegarde classique de Windows, et tous les utilisateurs VPN doivent pouvoir utiliser l'application sans modification de configuration à la fois quand ils sont dans les locaux et quand ils sont à distance).
Enfin, si quelqu'un a une idée pour :
- permettre la connexion fonctionnelle au VPN depuis le réseau local sur l'adresse IP publique (ce serait le mieux)
ou
- permettre la connexion fonctionnelle au VPN depuis le réseau local sur l'adresse IP privée
ou même encore
- avoir une configuration différente (un réseau VPN différent) pour une connexion au VPN depuis le LAN
ça m'intéresse aussi ;)
Merci d'avance (et désolé pour le long pavé, mais j'ai préféré donner d'emblée un maximum d'informations).
Note : les clients lancent le VPN avec OpenVPN Gui sans utiliser le service (lancé en tant qu'administrateur puisque c'est nécessaire pour OpenVPN), le serveur utilise le service en démarrage automatique (avec le Gui configuré pour ne piloter que le service pour une administration plus simple).
PS : je vais probablement refaire un test avec l'identification sur AD - le dernier n'était pas avec cette configuration - pour être sûr mais normalement le comportement restera le même (puisque lors de mes tests précédents ça ne changeait rien au comportement et que l'authentification marchait correctement).
A voir également:
- OpenVPN en RoadWarrior : problème de routes ?
- OpenVPN - Télécharger - Divers Réseau & Wi-Fi
- Nordlynx vs openvpn - Guide
- Les VPN : parmi les 9 solutions efficaces pour masquer votre IP en 2025 - Guide
- Les meilleurs VPN 2025 : quel service choisir pour protéger vos données ? - Guide
- Openvpn udp ou tcp - Guide
5 réponses
Je me réponds pour l'instant à moi-même pour apporter de nouvelles précisions : comme je le disais j'ai refais un test en réactivant l'authentification sur le domaine, et ça marche de la même façon.
J'ai également pu tester (depuis chez moi directement cette fois) l'accès aux partages réseau du serveur. On y accède bien en inscrivant le chemin \\Serveur\nomPartage
Par contre comme mentionné précédemment : connecter la machine distante au VPN coupe la liaison SSH initiée par le poste de travail sur le LAN entreprise (192.168.125.mmm) et il ne peut pas la réactiver (ça je n'ai pas retesté après avoir remis l'authentification AD, mais ça n'a aucune raison de changer). C'est quand même étonnant vu que la machine distante accède toujours à internet.
De même, on n'accède pas au reste du LAN (pourtant il y a bien sur le serveur une route vers le LAN qui apparaît avec "route print" comme vu ci-dessus). Je n'ai pas pu vérifier là, mais a priori les ordinateurs du LAN entreprise ne voient pas non plus le client VPN connecté.
Rien de changé pour la connexion au VPN depuis une machine du LAN entreprise.
J'ai également pu tester (depuis chez moi directement cette fois) l'accès aux partages réseau du serveur. On y accède bien en inscrivant le chemin \\Serveur\nomPartage
Par contre comme mentionné précédemment : connecter la machine distante au VPN coupe la liaison SSH initiée par le poste de travail sur le LAN entreprise (192.168.125.mmm) et il ne peut pas la réactiver (ça je n'ai pas retesté après avoir remis l'authentification AD, mais ça n'a aucune raison de changer). C'est quand même étonnant vu que la machine distante accède toujours à internet.
De même, on n'accède pas au reste du LAN (pourtant il y a bien sur le serveur une route vers le LAN qui apparaît avec "route print" comme vu ci-dessus). Je n'ai pas pu vérifier là, mais a priori les ordinateurs du LAN entreprise ne voient pas non plus le client VPN connecté.
Rien de changé pour la connexion au VPN depuis une machine du LAN entreprise.
Petite mise à jour : désormais je peux réinitialiser mon tunnel une fois le VPN connecté sur la machine distante. C'est de suite plus logique, mais par contre je ne comprends pas pourquoi je n'y arrivais pas avant, d'autant que je n'ai changé la configuration qu'en un seul point : j'ai généré à nouveau les différentes clefs en 2048 (donc modification du fichier de config juste pour la ligne "dh dh1024.pem" qui devient "dh dh2048.pem").
La déconnexion en elle-même est tout à fait logique puisque lors de la connexion au VPN la table de routage est réécrite il me semble. Enfin bon ce problème là est donc réglé.
Si quelqu'un a des idées pour le reste, n'hésitez pas ;) Pour rappel :
- impossibilité de se connecter au VPN sur l'IP publique dédiée depuis une machine du réseau local, pourquoi ? (ce n'est pas la même IP que l'IP de sortie de la connexion, mais ça passe par le même routeur, c'est peut-être pour ça).
- comment rendre fonctionnelle la connexion depuis le réseau local ? (j'ai comme dans l'idée que le problème vient de la route envoyée au client pour le réseau local qui fait que ça boucle plus ou moins).
- routes à ajouter pour que les clients VPNs puissent voir les autres postes du réseau local, et réciproquement ? Nécessité également de modifier d'une façon ou d'une autre la configuration de Windows 2003 sur le serveur ?
La déconnexion en elle-même est tout à fait logique puisque lors de la connexion au VPN la table de routage est réécrite il me semble. Enfin bon ce problème là est donc réglé.
Si quelqu'un a des idées pour le reste, n'hésitez pas ;) Pour rappel :
- impossibilité de se connecter au VPN sur l'IP publique dédiée depuis une machine du réseau local, pourquoi ? (ce n'est pas la même IP que l'IP de sortie de la connexion, mais ça passe par le même routeur, c'est peut-être pour ça).
- comment rendre fonctionnelle la connexion depuis le réseau local ? (j'ai comme dans l'idée que le problème vient de la route envoyée au client pour le réseau local qui fait que ça boucle plus ou moins).
- routes à ajouter pour que les clients VPNs puissent voir les autres postes du réseau local, et réciproquement ? Nécessité également de modifier d'une façon ou d'une autre la configuration de Windows 2003 sur le serveur ?
Dis moi ta societe n'ai pas situé a bry sur marne ? de l'evennementiel etc ...
Car j'ai les meme conf que toi ( j'y suis en stage ) et sa marche pas la y me demande un pass quand je lance OpenVPN GUI d'un client (chez moi )
?
Car j'ai les meme conf que toi ( j'y suis en stage ) et sa marche pas la y me demande un pass quand je lance OpenVPN GUI d'un client (chez moi )
?
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
J'ai pas la solution à ton problème et puis j'ai eu la flème de tout lire !
Mais ne serait-ce pas des problèmes de firewall tout simplement ?
En tous cas, envoie les résultats de "iptables -L -n -v", tes logs de "/var/log/kern.log" et d'autres traces parceque comme ça, c'est un peu chaud!
Le debug, ça passe par lire les traces ...
Bon courage,
Pp
Mais ne serait-ce pas des problèmes de firewall tout simplement ?
En tous cas, envoie les résultats de "iptables -L -n -v", tes logs de "/var/log/kern.log" et d'autres traces parceque comme ça, c'est un peu chaud!
Le debug, ça passe par lire les traces ...
Bon courage,
Pp
