[RESOLU] Re: Coupures OpenVPN (Inactivity timeout)
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-spam@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
>
Reply to: