Je me sens un peu bête mais j'avais deux instances du client OpenVPN qui "tournaient en parallèle". En supprimant l'une des deux instances, tout est rentré dans l'ordre.
Merci pour votre aide ! Le jeu. 27 janv. 2022 à 16:54, NoSpam <no-s...@tootai.net> a écrit : > > Bonjour > > Le 27/01/2022 à 16:41, Olivier a écrit : > > Bonjour, > > > > J'ai un serveur OpenVPN sur Debian 9, sur une machine fournie par un > > hébergeur Internet. > > À ce serveur, j'ai une cinquantaine de clients OpenVPN sur machine > > Debian de toutes les générations (Jessie, à Bullseye). > > Depuis quelques mois, j'observe des déconnexions temporaires. > > > > Sur une nouvelle machine dotée de Bullseye, j'ai décidé d'investiguer. > > > > Dans les logs du client, j'ai la séquence ci-après répétée toutes les > > 230 sec.2022-01-27 15:41:24 [server] Inactivity timeout > > (--ping-restart), restarting > > 2022-01-27 15:41:24 SIGUSR1[soft,ping-restart] received, process restarting > > 2022-01-27 15:41:29 WARNING: No server certificate verification method > > has been enabled. See http://openvpn.net/howto.html#mitm for more > > info. > > 2022-01-27 15:41:29 TCP/UDP: Preserving recently used remote address: > > [AF_INET]1.2.3.4:1194 > > 2022-01-27 15:41:29 UDP link local: (not bound) > > 2022-01-27 15:41:29 UDP link remote: [AF_INET]1.2.3.4:1194 > > 2022-01-27 15:41:29 [server] Peer Connection Initiated with > > [AF_INET]1.2.3.4:1194 > > 2022-01-27 15:41:30 Preserving previous TUN/TAP instance: tun0 > > 2022-01-27 15:41:30 Initialization Sequence Completed > > > > Voici la config du client: > > client > > dev tun > > proto udp > > remote 1.2.3.4 1194 > > resolv-retry infinite > > nobind > > user nobody > > group nogroup > > persist-key > > persist-tun > > ca /etc/openvpn/client/ca.crt > > cert /etc/openvpn/client/client_vie.crt > > key /etc/openvpn/client/client_vie.key > > comp-lzo > > verb 1 > > ping 30 > > > Je remplacerai ping 30 par keep-alive 10 60 et rajouterai tun-mtu 1500, > sur le serveur également. Pas de mssfix ? > > > > > > > > Voici la config du serveur: > > port 1194 > > proto udp > > dev tun > > topology subnet > > ca /etc/openvpn/easy-rsa/keys/ca.crt > > cert /etc/openvpn/easy-rsa/keys/server.crt > > key /etc/openvpn/easy-rsa/keys/server.key > > dh /etc/openvpn/easy-rsa/keys/dh1024.pem > > server 10.19.0.0 255.255.254.0 > > ifconfig-pool-persist /etc/openvpn/server1/ipp.txt > > client-to-client > > keepalive 10 120 > > comp-lzo > > user nobody > > group nogroup > > persist-key > > persist-tun > > status /etc/openvpn/server1/openvpn-status.log > > verb 1 > > > > Je lance en parallèle deux séries de ping: > > ping -c120 -q 1.2.3.4 > > ping -c120 -q 10.19.0.1 > > > > Aucune perte, sur la première. des pertes significatives sur la deuxième. > > > > Naivement, je pensais que le ping 10.19.0.1 a lieu seul, génère de > > l'activité OpenVPN qui interdit en retour le inactivity Timeout. > > > > Qu'en pensez-vous ? > > Dans quelle direction chercher ? > > > > Slts >
