Waouh !...
1/ Voilà ce que je viens de découvrir en analysant ma configuration OpenVPN de la machine Stretch :
j'utilisais un fichier de configuration OpenVPN un poil trop âgé encore en AES128, alors que j'utilisais le nouveau fichier de conf en AES256 pour la machine Jessie (le serveur a été passé en AES256).
Cela provoquait un Warning ( 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher AES-256-CBC') et un message d'erreur ("Authenticate/Decrypt packet error: cipher final failed") trop discrets d'OpenVPN : ce qui expliquait le comportement bizarre du client qui cherchait à se reconnecter régulièrement et n'était en fait pas connecté comme l'indiquait faussement le serveur.
Dès que j'ai remis le bon fichier de conf en AES256 (au même bon endroit) le comportement de la machine Stretch est redevenu normal, cad identique à celui de la machine Jessie avec les commandes suivantes :
$ sudo systemctl start openvpn@monserveur.service
$ sudo systemctl restart openvpn@monserveur.service
$ sudo systemctl stop openvpn@monserveur.service
On voit sur le serveur OpenVPN que le client se connecte et se déconnecte _immédiatement_.
Et le ping via VPN entre les deux machines Jessie et Stretch fonctionne à nouveau.
$ ip r
default via 212.27.38.253 dev tun0
<
mon-ip-fixe-masquée> via 192.168.0.1 dev wlp32s0
169.254.0.0/16 dev tun0 scope link metric 1000
192.168.0.0/24 via 212.27.38.253 dev tun0
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102 metric 600
192.168.27.64/27 via 212.27.38.253 dev tun0
212.27.38.253 dev tun0 proto kernel scope link src 192.168.27.68
$ sudo ifconfig
enp8s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:17:42:7a:c8:74 txqueuelen 1000 (Ethernet)
RX...
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX...
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 192.168.27.68 netmask 255.255.255.255 destination 212.27.38.253
inet6 fe80::bb3e:ca65:f4bc:9df3 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX...
wlp32s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.102 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::728e:fd77:36f1:a585 prefixlen 64 scopeid 0x20<link>
ether 00:21:6a:35:c6:a4 txqueuelen 1000 (Ethernet)
RX...
Il semble que l'absence d'accès au réseau internet était causée par cette "transaction en échec en boucle" qui se prolongeait entre le client et le server OpenVPN.
2/ la connaissance du système de configuration des réseaux avec Stretch est encore plus d'actualité.
En effet, quand ça marche c'est bien, mais quand ça foire il est crucial de savoir ce qui se passe.
Et là,rien n'a indiqué ce qui était en train de clocher.
De plus, je comprends que ce serait un système en cours de transition.
Comment faudrait-il procéder pour savoir dans quel état se trouve la configuration de composants logiciels réseaux et la configuration réseau d'une machine Stretch ?
Daniel, merci beaucoup pour le temps que tu as passé pour m'aider à régler ce problème.