Le VPN ne se relance pas automatiquement

Support
1

Bonjour,

J’ai un nouveau soucis embêtant avec mon nouveau serveur. Le VPN Client semble buguer de temps à autre et mon serveur devient inaccessible via son IPv4 de VPN.

Un email du diagnostique de Yunohost m’est envoyé (mais que je ne le reçois pas avant d’avoir rétabli la situation, bien évidement) :

Issues found by automatic diagnosis on domain.tld

The automatic diagnosis on your YunoHost server identified some issues on your server. You will find a description of the issues below. You can manage those issues in the ‘Diagnosis’ section in your webadmin.

=================================

Connectivité Internet (ip)

[ERROR] Le serveur ne dispose pas d’une adresse IPv4.

Afin de résoudre mon problème, je suis obligé de me connecter au serveur par l’adresse IP locale et de lancer
sudo service ynh-vpnclient restart
Alors, le serveur est de nouveau accessible sur son IPv4 de VPN.

J’ai regardé dans les logs de /var/log/openvpn-client.log et j’y trouve ça
Fri Sep 11 00:08:18 2020 133 variation(s) on previous 5 message(s) suppressed by --mute
Fri Sep 11 00:08:18 2020 [vpn.provider.com] Inactivity timeout (–ping-restart), restarting
Fri Sep 11 00:08:18 2020 /sbin/ip route del XXX.XXX.XXX.XXX/32
Fri Sep 11 00:08:18 2020 /sbin/ip route del 0.0.0.0/1
Fri Sep 11 00:08:18 2020 /sbin/ip route del 128.0.0.0/1
Fri Sep 11 00:08:18 2020 Closing TUN/TAP interface
Fri Sep 11 00:08:18 2020 /sbin/ip addr del dev tun0 89.234.177.95/26
Fri Sep 11 00:08:18 2020 SIGUSR1[soft,ping-restart] received, process restarting
Fri Sep 11 00:08:18 2020 Restart pause, 5 second(s)
Fri Sep 11 00:08:23 2020 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Fri Sep 11 00:08:23 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:443
Fri Sep 11 00:08:23 2020 Socket Buffers: R=[131072->131072] S=[16384->16384]
Fri Sep 11 00:08:23 2020 Attempting to establish TCP connection with [AF_INET]XXX.XXX.XXX.XXX:443 [nonblock]
Fri Sep 11 00:08:55 2020 TCP: connect to [AF_INET]XXX.XXX.XXX.XXX:443 failed: Connection timed out
Fri Sep 11 00:08:55 2020 SIGUSR1[connection failed(soft),init_instance] received, process restarting
Fri Sep 11 00:08:55 2020 Restart pause, 5 second(s)
Fri Sep 11 00:09:00 2020 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Fri Sep 11 00:09:20 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 00:09:40 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)

Fri Sep 11 05:49:12 2020 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Fri Sep 11 05:49:32 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 05:49:52 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 05:49:52 2020 Could not determine IPv4/IPv6 protocol
Fri Sep 11 05:49:52 2020 SIGUSR1[soft,init_instance] received, process restarting
Fri Sep 11 05:49:52 2020 Restart pause, 300 second(s)
Fri Sep 11 05:54:52 2020 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Fri Sep 11 05:55:12 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 05:55:32 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 05:55:32 2020 Could not determine IPv4/IPv6 protocol
Fri Sep 11 05:55:32 2020 SIGUSR1[soft,init_instance] received, process restarting
Fri Sep 11 05:55:32 2020 Restart pause, 300 second(s)
Fri Sep 11 06:00:32 2020 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Fri Sep 11 06:00:52 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:01:12 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:01:12 2020 Could not determine IPv4/IPv6 protocol
Fri Sep 11 06:01:12 2020 SIGUSR1[soft,init_instance] received, process restarting
Fri Sep 11 06:01:12 2020 Restart pause, 300 second(s)
Fri Sep 11 06:06:12 2020 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Fri Sep 11 06:06:32 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:06:52 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:06:52 2020 Could not determine IPv4/IPv6 protocol
Fri Sep 11 06:06:52 2020 SIGUSR1[soft,init_instance] received, process restarting
Fri Sep 11 06:06:52 2020 Restart pause, 300 second(s)
Fri Sep 11 06:11:52 2020 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Fri Sep 11 06:11:53 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:11:53 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:11:53 2020 Could not determine IPv4/IPv6 protocol
Fri Sep 11 06:11:53 2020 SIGUSR1[soft,init_instance] received, process restarting
Fri Sep 11 06:11:53 2020 Restart pause, 300 second(s)
Fri Sep 11 06:16:53 2020 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Fri Sep 11 06:16:53 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:16:53 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:16:53 2020 Could not determine IPv4/IPv6 protocol
Fri Sep 11 06:16:53 2020 SIGUSR1[soft,init_instance] received, process restarting
Fri Sep 11 06:16:53 2020 Restart pause, 300 second(s)
Fri Sep 11 06:21:53 2020 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Fri Sep 11 06:21:53 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:21:53 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:21:53 2020 Could not determine IPv4/IPv6 protocol
Fri Sep 11 06:21:53 2020 SIGUSR1[soft,init_instance] received, process restarting
Fri Sep 11 06:21:53 2020 Restart pause, 300 second(s)
Fri Sep 11 06:26:53 2020 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Fri Sep 11 06:26:53 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:26:54 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:26:54 2020 Could not determine IPv4/IPv6 protocol
Fri Sep 11 06:26:54 2020 SIGUSR1[soft,init_instance] received, process restarting
Fri Sep 11 06:26:54 2020 Restart pause, 300 second(s)
Fri Sep 11 06:31:54 2020 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Fri Sep 11 06:31:54 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:31:54 2020 RESOLVE: Cannot resolve host address: vpn.provider.com:443 (Temporary failure in name resolution)
Fri Sep 11 06:31:54 2020 Could not determine IPv4/IPv6 protocol
Fri Sep 11 06:31:54 2020 SIGUSR1[soft,init_instance] received, process restarting
Fri Sep 11 06:31:54 2020 Restart pause, 300 second(s)

mon fournisseur de VPN m’a demandé de regarder ce qui est contenu dans
/etc/resolv.conf et dans /etc/resolv.dnsmasq.conf quand le service ynh-vpnclient est en fonctionnement et quand je l’arrête.
/etc/resolv.conf a le même contenu dans les deux cas,

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

mais le contenu de /etc/resolv.dnsmasq.conf change.
Quand le service ynh-vpnclient est en fonctionnement, il contient les deux adresse ip des deux serveur DNS renseigné dans l’application VPN-Client
Quand le le service ynh-vpnclient est à l’arrêt, son contenu est celui par défaut de Yunohost (je crois) à savoir

nameserver 80.67.190.200
nameserver 84.200.70.40
nameserver 80.67.188.188
nameserver 2001:67c:28a4::
nameserver 2a0c:e300::100
nameserver 185.233.100.101
nameserver 2001:910:800::40
nameserver 2a00:5881:8100:1000::3
nameserver 2001:910:800::12
nameserver 80.67.169.12
nameserver 80.67.169.40
nameserver 194.150.168.168
nameserver 89.233.43.71
nameserver 2001:1608:10:25::1c04:b12f
nameserver 91.239.100.100
nameserver 84.200.69.80
nameserver 2a00:5884:8218::1
nameserver 2001:1608:10:25::9249:d69b
nameserver 2a0c:e300::101
nameserver 2001:913::8
nameserver 89.234.141.66
nameserver 195.160.173.53
nameserver 85.214.20.141
nameserver 185.233.100.100
nameserver 2a01:3a0:53:53::

Ils m’ont ensuite dit cette phrase mystérieuse mais que certains ici comprendront peut-être:

Okay. pour contourner le problème il faudrait que tu dises à resolvconf de rajouter un serveur DNS en fallback quand tu es connecté au VPN. comme ça, quand le client réinitialisera sa connexion il aura un serveur utilisable malgré les deux premiers qui le rejetteront
le plus propre ce serait qu’openvpn nettoie ses changements resolvconf avant de réinitialiser sa connexion, mais jene vois pas comment faire ça proprement, là

Un idée de comment résoudre mon problème?

2

Je me permets de soumettre ce script que j’ai adapté de https://github.com/ltpitt/bash-network-repair-automation .

Qu’en pensez-vous? Est-ce que le code que j’ai modifié vous semble fonctionnel? acceptable? au niveau sécurité etc…?

#!/bin/bash

# How to install this VPN check script :
#Copy this script in your serveur
#Make the script executable: sudo chmod +x vpn_check.sh
#Edit your root user's crontab using: sudo crontab -e
#Add to your crontab the following line, it will execute the check every 30 minutes. Please customize the script path according to the folder where you cloned the repo: */30 * * * * /yourpath/vpn_check.sh >> /var/log/netcheck.log 2>&1

# Checking if requirements (fping) is installed 
command -v fping >/dev/null 2>&1 || { echo >&2 "Sorry but fping is not installed. Aborting.";  exit 1; }

clear

###
# Configuration variables, customize if needed
###

# Set gateway_ip to the gateway that you want to check to declare VPN working or not
gateway_ip='faimaison.net'
# Set nic to your Network card name, as seen in ifconfig output
nic='eth0'
# Set vpn_check_threshold to the maximum number of failed checks
vpn_check_threshold=5

###
# Script logic
###

# Initializing the vpn check counter to zero
vpn_check_tries=0

# This loop will run for vpn_check_tries times, in case there are
# vpn_check_threshold failures the VPN will be declared as
# not functional and the ynh-vpnclient service will be restarted
while [ $vpn_check_tries -lt $vpn_check_threshold ]; do
    # Checking if ping to gateway is working using fping
    host_status=$(fping $gateway_ip)
    # Increasing network_check_tries by 1
    vpn_check_tries=$[$vpn_check_tries+1]
    
    if [[ $host_status == *"alive"* ]]; then
        # VPN is up
        echo "VPN is working correctly" && exit 0
    else
        # VPN is down
        echo "VPN is down, failed check number $vpn_check_tries of $vpn_check_threshold"
    fi
    
    # Once the vpn_check_threshold is reached
    if [ $vpn_check_tries -ge $vpn_check_threshold ]; then
        # Trying VPN restart
    	echo "VPN was not working for the previous $vpn_check_tries checks."
    	echo "Restarting VPN"
   	service ynh-vpnclient restart
	sleep 60
	# If VPN is still down
	host_status=$(fping $gateway_ip)
	if [[ $host_status != *"alive"* ]]; then
		echo "VPN is still not working, rebooting."
		reboot
	fi
    fi
    sleep 5
done
3

J’hésite notamment sur la dernière partie

host_status=$(fping $gateway_ip)
    	if [[ $host_status != *"alive"* ]]; then
    		echo "VPN is still not working, rebooting."
    		reboot
    	fi

J’ai peur que dans certains cas que je n’envisage pas, mon serveur se retrouve dans une loop de redémarrage.

Merci de bien vouloir commenter.

4

Oui ça ressemble à un truc super dangereux …

Perso plutôt que de faire un script qui fait des checks mystiques de l’espace, je resterais sur l’idée donnée par les koupaings de ton fournisseur de VPN de comprendre l’histoire des DNS resolver …

En écrivant mon message, je réalise que :

  • si je comprends bien, ton serveur n’a pas d’IPv4 mis à part par le VPN … (ce qui est inhabituel, mais ok)
  • du coup lorsque ton VPN est down, les résolveurs DNS IPv4 ne fonctionnent pas (car pas d’IPv4)
  • … du coup il faudrait avoir un résolveur IPv6 défini ?

Est-ce que tu peux confirmer que lorsque ton VPN est up, alors cat /etc/resolv.dnsmasq.conf montre seulement deux IPv4 comme nameserver ?

Si c’est le cas alors à mon avis, un correctif simple est de configurer un résolveur IPv6 dans ton vpnclient … Par exemple tu peux en choisir un dans la liste par défaut de Yunohost (qui est basé sur cette liste)

(Il faut ptete juste vérifier que le resolveur est bien fonctionnel car des fois certains sont en panne, comme gozmail/grifon en ce moment :wink: (en tout cas en ipv4))

5

Si, mon serveur a bien deux IPv4, une IP sur tun0, celle du VPN et une Ipv4 locale sur eth0 (c’est plus eth0 maintenant mais bon, je pense que tu comprendras) en 192.168.1.x donné par la box.
Le serveur n’a en revanche aucune IPv6, ni via la box (à activer peut-être, faut que je vérifie), ni via le VPN (pas encore dispo par Cogent à Nantes pour FAImaison).

Oui, orsque mon VPN est up, alors cat /etc/resolv.dnsmasq.conf montre seulement deux IPv4 comme nameserver.

6

Woké mais du coup on parle précisément de la situation où ton VPN est down (donc pas de tun0) … et le fait que tu ait une IPv4 locale (192.168.x.y) ne signifie pas nécessaire que tu as une IPv4 globale …

En tout cas ça expliquerait pourquoi le diagnostique dit que :

[ERROR] Le serveur ne dispose pas d'une adresse IPv4.

et ça expliquerait aussi pourquoi il y a un soucis de résolution de domaine lorsqu’il essaye de remonter le VPN …

Si on veut en avoir le coeur net, alors il faut désactiver ton VPN et faire un curl ip.yunohost.org

7 
sudo service ynh-vpnclient stop
admin@xxxx:~$ curl ip.yunohost.org
93.6.122.9admin@xxxx:~$

aucune idée de ce que ça signifie, quelle est cette ip étrange, pas celle de mon vpn évidement, ni la locale, qu’est-ce que c’est?

8

C’est ton IP globale, celle fournie par ton fournisseur d’accès de chez toi (Orange / Free / SFR / …)

9

ah ok, celle qui change quand on reboot la box, ok.
Et donc, ça signifierait quoi?

10

J’ai oublié de préciser que chez FAImaison, on m’a dit :
à propos des deux nameservers (les deux ip des deux serveur DNS renseigné dans l’application VPN-Client)

ces DNS ne sont utilisables que depuis les adresses IP de Faimaison. donc quand ton tunnel n’est pas utilisé/utilisable, ces serveurs DNS refuseront de te répondre

Je ne sais pas si c’est évident, si ça aide à cerner le problème…

11

Oui du coup ça explique clairement le soucis … je pense que VPN client n’a pas été designer avec l’idée que les resolveurs DNS ne sont accessibles que via le VPN …

Donc pour pallier à ton soucis, une solution relativement simple consiste à rajouter/remplacer un DNS resolver dans la conf de VPN client (sur tondomaine.tld/vpnclient) par un résolveur accessible aussi sans passer par le VPN …

Par exemple. un de ceux listés sur DNS resolvers [Do-It-Yourself Internet Service Providers] (par exemple celui d’ARN : 89.234.141.66 )

12

Ok, je teste ça alors pendant quelques jours et je te tiens au courant.
Ce qui est étrange c’est que jusqu’au 04/09/20, je n’ai jamais éprouvé de problème (ou bien je ne m’en rendais pas compte).

13

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.