OK.
J’ai éxécuté la commande et j’ai :
$ sudo journalctl -u ynh-vpnclient --since today
Journal file /var/log/journal/6ed9c2313db84d09935e72b49bf501ec/user-1007.journal is truncated, ignoring file.
-- Journal begins at Mon 2023-06-12 20:09:19 UTC, ends at Tue 2023-06-20 17:21:57 UTC. --
-- No entries --
il y a bien un fichier /var/log/openvpn-client.log avec son contenu ci-après : hastebin
C’est étrange ça, d’après ce log on dirait que la connexion VPN fonctionne bien et qu’elle se renouvelle toutes les heures. Et pourtant le service ynh-vpnclient échoue.
Peux-tu taper les commandes suivantes en tant que root (ou en les préfixant avec sudo) ?
systemctl stop ynh-vpnclient-checker
systemctl stop ynh-vpnclient
ip link # pour voir si par hasard il n'y aurait pas des interfaces tunX parasites
ps aux | grep -i vpn # voir si y a pas un processus vpn qui tourne déjà
Si ces commandes ne montrent rien de surprenant, essaye de lancer manuellement le vpn comme ceci :
openvpn /etc/openvpn/client.conf
En espérant que ça nous donne plus d’infos…
oui bien sûr.
Alors voilà 
$ sudo systemctl stop ynh-vpnclient-checker
Warning: Stopping ynh-vpnclient-checker.service, but it can still be activated by:
ynh-vpnclient-checker.timer
$ sudo systemctl stop ynh-vpnclient
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether [xx:yy:zz:aa:bb:cc] brd ff:ff:ff:ff:ff:ff
3: wlx[nnn]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether [dd:ee:ff:gg:hh:ii] brd ff:ff:ff:ff:ff:ff permaddr [jj:kk:ll:mm:nn:oo]
J’ai anonymisé les link/ether et le permaddr avec des suites de ‘xx’ à ‘oo’, j’espère avoir bien fait.
$ ps aux | grep -i vpn
admin 19634 0.0 0.0 6840 596 pts/0 S+ 20:31 0:00 grep -i vpn
Il n’y a pas de processus VPN en cours.
J’essaie de lancer manuellement le VPN avec openvpn /etc/openvpn/client.conf et cela reste “bloqué” (cad je ne récupère pas la main au niveau du terminal), normal ?
$ sudo openvpn /etc/openvpn/client.conf
2023-06-20 20:32:45 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
2023-06-20 20:32:45 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Oui c’est normal, j’avais oublié de préciser
Là je m’attendais à beaucoup plus d’infos…
Du coup, sans stopper cette commande déjà lancée, en ouvrant une seconde connexion SSH vers la brique, regarde si l’interface VPN est UP :
ip address show
ip route show
Salut @pitchum, merci pour ton aide 
voilà le résultat des commandes :
$ ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether [xx:xx:xx:xx:xx:xx] brd ff:ff:ff:ff:ff:ff
inet 192.168.1.158/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 77665sec preferred_lft 77665sec
inet6 [yyyy:yyyy:y:yyyy:y:yyy:yyyy:yyyy]/64 scope global dynamic mngtmpaddr
valid_lft 2005881483sec preferred_lft 2005881483sec
inet6 [zzzz::zz:zzzz]/128 scope link
valid_lft forever preferred_lft forever
inet6 [aaaa::a:aaa:aaaa:aaaa]/64 scope link
valid_lft forever preferred_lft forever
3: wlx[nn]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether [bb:bb:bb:bb:bb:bb] brd ff:ff:ff:ff:ff:ff permaddr [cc:cc:cc:cc:cc:cc]
inet 10.0.242.1/24 scope global wlx[nn]
valid_lft forever preferred_lft forever
inet6 [dddd::dd:dddd:dddd:dddd]/64 scope link
valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 89.234.[x.y]/26 scope global tun0
valid_lft forever preferred_lft forever
inet6 [eeee]:[eeee]:[eeee]:[eee]::[eee]/64 scope global
valid_lft forever preferred_lft forever
inet6 [fff::ffff:ffff:ffff:ffff]/64 scope link stable-privacy
valid_lft forever preferred_lft forever
$ ip route show
0.0.0.0/1 via 89.234.141.1 dev tun0
default via 192.168.1.1 dev eth0
10.0.242.0/24 dev wlx[nn] proto kernel scope link src 10.0.242.1
89.234.[x].0/26 dev tun0 proto kernel scope link src 89.234.[x.y]
89.234.141.94 via 192.168.1.1 dev eth0
128.0.0.0/1 via 89.234.141.1 dev tun0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.158
Alors sans être experte en la matière, je dirai que l’interface VPN est lancée. J’ai regardé mon adresse IP dans les résultats… enfin celle étant présente dans le fichier .cube.
Mais en me connectant sur le wifi de la brique internet, je n’accède pas à l’Internet libéré 
Oui, le tunnel VPN est effectivement lancé. Mais pas de la bonne manière. On l’a lancé à la main avec la commande openvpn directement. Il faut qu’on trouve comment réparer le service ynh-vpnclient.
Je propose qu’on continue cet échange en privé, et qu’on repasse en discussion publique quand on aura trouvé la solution.
Si tu veux.
Si c’est trop compliqué, je peux aussi refaire une installation… comme tu veux.
Bonjour,
j’ai un gros soucis aussi avec mon vpn, ce n’est pas un vpn d’ARN mais d’Illyse…
Depuis cet après-midi, j’ai l’impression que cela est venu avec une mise à jour de bind et bind9…
Impossible de me connecter à mon serveur, ou je n’y arrive que avec un écran et un clavier pour l’instant !
Du coup j’essaie aussi de lance manuellement openvpn…
Ce n’est pas gagner, j’ai bien la même ligne après avoir lancer openvpn
~# openvpn /etc/openvpn/client.conf
2023-06-20 20:32:45 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
mais ça s’arrête là on dirait…
Ce qui est embêtant c’est que même si le service est failed, je n’arrive pas loçalement à me connecter !!
te connecter à quoi ?
Hello, c’est résolu après une nuit blanche et le resolveur dns de la FDN qui a été réparé (entre temps désinstallation et réinstallation de vpn_client, etc…).
Je n’arrivais plus à me connecter même localement au serveur, je n’avais que l’écran et le clavier disponibles… Je crois pour résoudre, j’ai désinstallé clinet_vpn et hotspot, fait un regen-conf dnsmasq pour qu’il change les résolveurs afin d’avoir de nouveau une connexion, puis plus tard réinstallé client_vpn et le .cube en changeant un résolveur dns qui semble plus très compatible
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.