Impossible d'accéder à ma brique pourtant connectée au réseau

Bonjour,

Ma brique est inaccessible depuis l’extérieur. Pourtant, le VPN qu’elle utilise fonctionne et elle a accès au réseau (je peux pinger sans problème plusieurs destinations depuis la console série). Quel est ce mystère ?

à toute fins utiles:

root@stemy:~# systemctl status networking
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor prese
   Active: failed (Result: exit-code) since Tue 2018-09-18 15:55:31 CEST; 2min 4
     Docs: man:interfaces(5)
  Process: 283 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1
  Process: 270 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ 
 Main PID: 283 (code=exited, status=1/FAILURE)

Sep 18 15:55:31 stemy.me ifup[283]: than a configuration issue please read the s
Sep 18 15:55:31 stemy.me ifup[283]: bugs on either our web page at www.isc.org o
Sep 18 15:55:31 stemy.me ifup[283]: before submitting a bug.  These pages explai
Sep 18 15:55:31 stemy.me ifup[283]: process and the information we find helpful 
Sep 18 15:55:31 stemy.me ifup[283]: exiting.
Sep 18 15:55:31 stemy.me ifup[283]: ifup: failed to bring up usb0
Sep 18 15:55:31 stemy.me systemd[1]: networking.service: Main process exited, co
Sep 18 15:55:31 stemy.me systemd[1]: Failed to start Raise network interfaces.
Sep 18 15:55:31 stemy.me systemd[1]: networking.service: Unit entered failed sta
Sep 18 15:55:31 stemy.me systemd[1]: networking.service: Failed with result 'exi

Que donne :

  • un ping de l’ip du vpn
  • un ping depuis la brique vers wikipedia.org
  • iptables-save

?

Ah, j’ai un problème d’affichage qui est apparu, les lettres sont affichées dans le désordre, du coup la console est inutilisable. Voilà ce que ça donne quand je laisse la touche entrée enfoncée. À la place de «root@stemy.me:~#» à plusieurs reprises, j’ai ça:

rootroot@s
~#o
rooemy:~#
rootsemy:# 
ro@stem~#
rooemy:~# 
~ste
my:# @
r t#ro
root@sy:~# oo
tem:~# 
rootemy:~
ro
root@
roo root# t@~# 
root@ststemy:
#  
ro
ro~# 
t@s# 
stemy~# 
:~# 
root@ 
rt@:~# 
rot:~:~# rtemy#

Bon, par miracle, le ssh local fonctionne encore, donc je peux encore avoir des résultats lisibles.

Maintenant, le ping ne fonctionne plus du tout, ça me fait un «temporary failure in name resolution».

Et voici ce que donne iptables-save:

root@stemy:~# iptables-save
# Generated by iptables-save v1.6.0 on Tue Sep 18 19:00:32 2018
*nat
:PREROUTING ACCEPT [37:16221]
:INPUT ACCEPT [35:16149]
:OUTPUT ACCEPT [5062:331748]
:POSTROUTING ACCEPT [373:10972]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue Sep 18 19:00:32 2018
# Generated by iptables-save v1.6.0 on Tue Sep 18 19:00:32 2018
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [3531:248975]
:f2b-dovecot - [0:0]
:f2b-nginx-http-auth - [0:0]
:f2b-pam-generic - [0:0]
:f2b-postfix - [0:0]
:f2b-postfix-sasl - [0:0]
:f2b-recidive - [0:0]
:f2b-sshd - [0:0]
:f2b-sshd-ddos - [0:0]
:f2b-yunohost - [0:0]
:vpnclient_fwd - [0:0]
:vpnclient_in - [0:0]
:vpnclient_out - [0:0]
-A INPUT -p tcp -m multiport --dports 80,443 -j f2b-yunohost
-A INPUT -p tcp -j f2b-pam-generic
-A INPUT -p tcp -j f2b-recidive
-A INPUT -p tcp -m multiport --dports 110,995,143,993,587,465,4190 -j f2b-dovecot
-A INPUT -p tcp -m multiport --dports 25,465,587 -j f2b-postfix
-A INPUT -p tcp -m multiport --dports 80,443 -j f2b-nginx-http-auth
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd-ddos
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -i eth0 -j vpnclient_in
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5269 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4280 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8448 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5349 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5350 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 5353 -j ACCEPT
-A INPUT -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -p udp -m udp --dport 4253 -j ACCEPT
-A INPUT -p udp -m udp --dport 587 -j ACCEPT
-A INPUT -p udp -m udp --dport 5349 -j ACCEPT
-A INPUT -p udp -m udp --dport 5350 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A FORWARD -o eth0 -j vpnclient_fwd
-A OUTPUT -o eth0 -j vpnclient_out
-A f2b-dovecot -j RETURN
-A f2b-nginx-http-auth -j RETURN
-A f2b-pam-generic -j RETURN
-A f2b-postfix -j RETURN
-A f2b-postfix-sasl -j RETURN
-A f2b-recidive -j RETURN
-A f2b-sshd -j RETURN
-A f2b-sshd-ddos -j RETURN
-A f2b-yunohost -j RETURN
-A vpnclient_fwd -j DROP
-A vpnclient_in -p icmp -j ACCEPT
-A vpnclient_in -s 10.0.0.0/8 -j ACCEPT
-A vpnclient_in -s 172.16.0.0/12 -j ACCEPT
-A vpnclient_in -s 192.168.0.0/16 -j ACCEPT
-A vpnclient_in -s 169.254.0.0/16 -j ACCEPT
-A vpnclient_in -p tcp -m tcp --dport 22 -j ACCEPT
-A vpnclient_in -p tcp -m tcp --dport 443 -j ACCEPT
-A vpnclient_in -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A vpnclient_in -j DROP
-A vpnclient_out -d 80.67.181.3/32 -p udp -m udp --dport 1195 -j ACCEPT
-A vpnclient_out -d 89.234.141.66/32 -p udp -m udp --dport 53 -j ACCEPT
-A vpnclient_out -d 10.0.0.0/8 -j ACCEPT
-A vpnclient_out -d 172.16.0.0/12 -j ACCEPT
-A vpnclient_out -d 192.168.0.0/16 -j ACCEPT
-A vpnclient_out -d 169.254.0.0/16 -j ACCEPT
-A vpnclient_out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A vpnclient_out -j DROP
COMMIT
# Completed on Tue Sep 18 19:00:32 2018
root@stemy:~#

@stemy2 as-tu fait une mise à jour vers yunohost 3.X ?
Quel est ton fournisseur de VPN ?

À tout hasard, essaye cette (longue) commande là et copie ici le résultat :

for ip in $(cat /etc/resolv.dnsmasq.conf{,.ynh} | cut -d' ' -f2); do echo -n "Trying dig @${ip} => "; dig +short perdu.com @$ip +time=2 +tries=1 ; done

Oui, j’ai fait la MAJ vers la version la plus récente hier.
C’est neutrinet qui fournit mon VPN.
Voici le résultat de la commande:

cat: /etc/resolv.dnsmasq.conf.ynh: No such file or directory
Trying dig @nameserver => dig: couldn't get address for 'nameserver': failure
Trying dig @nameserver => dig: couldn't get address for 'nameserver': failure

Le problème s’est résolu tout seul pendant que je dormais.

Comme quoi c’est toujours une bonne idée de dormir :slight_smile:
Mais bon, je ne serais pas étonné que ce ne soit que temporaire.

Pfff ma commande ne fonctionne pas chez toi car tes fichiers resolv.xxx n’ont pas le même format que chez moi visiblement.
Peux-tu taper cette commande plutôt (elle devrait être plus tolérante sur le format de fichier) :

for ip in $(cat /etc/resolv.dnsmasq.conf{,.ynh} | sed 's/^\s*nameserver\s\+//'); do echo -n "Trying dig @${ip} => "; dig +short perdu.com @$ip +time=2 +tries=1 ; done

Ah non, il est réapparu.

Et ton autre commande me donne le même résultat que la première.

Bon et qu’affichent ces commandes ?

df -h
ip address show
ls -l /etc/resolv*
cat /etc/resolv*
sudo tail -n 80 /var/log/openvpn-client.log

Voilà.

root@stemy:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            231M     0  231M   0% /dev
tmpfs            50M  5.4M   45M  11% /run
/dev/mmcblk0p1   15G  5.8G  8.4G  42% /
tmpfs           248M  4.0K  248M   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           248M     0  248M   0% /sys/fs/cgroup
/dev/sda1       230G   97G  122G  45% /mnt/evo
tmpfs            50M     0   50M   0% /run/user/0

root@stemy:~# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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 pfifo_fast state UP group default qlen 1000
    link/ether 02:03:08:c1:3f:b4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.7/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::3:8ff:fec1:3fb4/64 scope link 
       valid_lft forever preferred_lft forever

root@stemy:~# ls -l /etc/resolv*
lrwxrwxrwx 1 root root   31 Jan  1  1970 /etc/resolv.conf -> /etc/resolvconf/run/resolv.conf
-rw-r--r-- 1 root root   22 Jan 21  2018 /etc/resolv.dnsmasq.conf
/etc/resolvconf:
total 16
-rw-r--r-- 1 root root  511 Apr  1  2016 interface-order
drwxr-xr-x 2 root root 4096 Jul  3 05:13 resolv.conf.d
lrwxrwxrwx 1 root root   15 Aug 30  2017 run -> /run/resolvconf
drwxr-xr-x 2 root root 4096 Jul  3 05:13 update.d
drwxr-xr-x 2 root root 4096 Jul  3 04:57 update-libc.d

root@stemy:~# cat /etc/resolv*
cat: /etc/resolvconf: Is a directory
nameserver 80.67.169.40
nameserver
nameserver

root@stemy:~# sudo tail -n 80 /var/log/openvpn-client.log
Tue Sep 25 17:41:33 2018 RESOLVE: Cannot resolve host address: vpn.neutrinet.be:1195 (Temporary failure in name resolution)
Tue Sep 25 17:41:33 2018 RESOLVE: Cannot resolve host address: vpn.neutrinet.be:1195 (Temporary failure in name resolution)
Tue Sep 25 17:41:33 2018 Could not determine IPv4/IPv6 protocol
Tue Sep 25 17:41:33 2018 SIGUSR1[soft,init_instance] received, process restarting
Tue Sep 25 17:41:33 2018 Restart pause, 20 second(s)
Tue Sep 25 17:41:54 2018 RESOLVE: Cannot resolve host address: vpn.neutrinet.be:1195 (Temporary failure in name resolution)
Tue Sep 25 17:41:54 2018 RESOLVE: Cannot resolve host address: vpn.neutrinet.be:1195 (Temporary failure in name resolution)
Tue Sep 25 17:41:54 2018 Could not determine IPv4/IPv6 protocol
Tue Sep 25 17:41:54 2018 SIGUSR1[soft,init_instance] received, process restarting
Tue Sep 25 17:41:54 2018 Restart pause, 40 second(s)
Tue Sep 25 17:42:34 2018 RESOLVE: Cannot resolve host address: vpn.neutrinet.be:1195 (Temporary failure in name resolution)
Tue Sep 25 17:42:34 2018 RESOLVE: Cannot resolve host address: vpn.neutrinet.be:1195 (Temporary failure in name resolution)
Tue Sep 25 17:42:34 2018 Could not determine IPv4/IPv6 protocol
Tue Sep 25 17:42:34 2018 SIGUSR1[soft,init_instance] received, process restarting
Tue Sep 25 17:42:34 2018 Restart pause, 80 second(s)
Tue Sep 25 17:44:10 2018 RESOLVE: Cannot resolve host address: vpn.neutrinet.be:1195 (Temporary failure in name resolution)
Tue Sep 25 17:44:15 2018 RESOLVE: Cannot resolve host address: vpn.neutrinet.be:1195 (Temporary failure in name resolution)
Tue Sep 25 17:44:15 2018 Could not determine IPv4/IPv6 protocol
Tue Sep 25 17:44:16 2018 SIGUSR1[soft,init_instance] received, process restarting
Tue Sep 25 17:44:16 2018 Restart pause, 160 second(s)
Tue Sep 25 17:46:57 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]80.67.181.3:1195
Tue Sep 25 17:46:57 2018 Socket Buffers: R=[163840->163840] S=[163840->163840]
Tue Sep 25 17:46:57 2018 UDP link local: (not bound)
Tue Sep 25 17:46:57 2018 UDP link remote: [AF_INET]80.67.181.3:1195
Tue Sep 25 17:46:58 2018 TLS: Initial packet from [AF_INET]80.67.181.3:1195, sid=4a94c25d af674721
Tue Sep 25 17:46:58 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue Sep 25 17:46:59 2018 VERIFY OK: depth=1, C=BE, ST=Brussels Capital Region, L=Brussels, O=Neutrinet, OU=VPN, CN=vpn.neutrinet.be, name=VPN, emailAddress=contact@neutrinet.be
Tue Sep 25 17:46:59 2018 VERIFY OK: nsCertType=SERVER
Tue Sep 25 17:46:59 2018 Validating certificate key usage
Tue Sep 25 17:46:59 2018 ++ Certificate has key usage  00a0, expects 00a0
Tue Sep 25 17:46:59 2018 VERIFY KU OK
Tue Sep 25 17:46:59 2018 NOTE: --mute triggered...
Tue Sep 25 17:47:06 2018 5 variation(s) on previous 5 message(s) suppressed by --mute
Tue Sep 25 17:47:06 2018 [vpn.neutrinet.be] Peer Connection Initiated with [AF_INET]80.67.181.3:1195
Tue Sep 25 17:47:07 2018 SENT CONTROL [vpn.neutrinet.be]: 'PUSH_REQUEST' (status=1)
Tue Sep 25 17:47:07 2018 PUSH: Received control message: 'PUSH_REPLY,ifconfig-ipv6 2001:913:1fff:ffff::b:d130/64 2001:913:1fff:ff00::1,route 80.67.181.128 255.255.255.128 80.67.181.129,route 80.67.181.3 255.255.255.255 net_gateway,redirect-gateway def1,route-gateway 80.67.181.129,tun-ipv6,route-ipv6 2000::/3,ping 10,ping-restart 60,ifconfig 80.67.181.213 255.255.255.128'
Tue Sep 25 17:47:07 2018 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
Tue Sep 25 17:47:07 2018 OPTIONS IMPORT: timers and/or timeouts modified
Tue Sep 25 17:47:07 2018 OPTIONS IMPORT: --ifconfig/up options modified
Tue Sep 25 17:47:07 2018 OPTIONS IMPORT: route options modified
Tue Sep 25 17:47:07 2018 OPTIONS IMPORT: route-related options modified
Tue Sep 25 17:47:07 2018 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Sep 25 17:47:07 2018 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Tue Sep 25 17:47:07 2018 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Sep 25 17:47:07 2018 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Tue Sep 25 17:47:07 2018 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=eth0 HWADDR=02:03:08:c1:3f:b4
Tue Sep 25 17:47:07 2018 GDG6: remote_host_ipv6=n/a
Tue Sep 25 17:47:07 2018 ROUTE6: default_gateway=UNDEF
Tue Sep 25 17:47:07 2018 TUN/TAP device tun0 opened
Tue Sep 25 17:47:07 2018 TUN/TAP TX queue length set to 100
Tue Sep 25 17:47:07 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Tue Sep 25 17:47:07 2018 /sbin/ip link set dev tun0 up mtu 1500
Tue Sep 25 17:47:07 2018 /sbin/ip addr add dev tun0 80.67.181.213/25 broadcast 80.67.181.255
Tue Sep 25 17:47:07 2018 /sbin/ip -6 addr add 2001:913:1fff:ffff::b:d130/64 dev tun0
Tue Sep 25 17:47:07 2018 /sbin/ip route add 80.67.181.3/32 via 192.168.1.1
Tue Sep 25 17:47:07 2018 /sbin/ip route add 0.0.0.0/1 via 80.67.181.129
Tue Sep 25 17:47:07 2018 /sbin/ip route add 128.0.0.0/1 via 80.67.181.129
Tue Sep 25 17:47:07 2018 /sbin/ip route add 80.67.181.128/25 via 80.67.181.129
RTNETLINK answers: File exists
Tue Sep 25 17:47:07 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Tue Sep 25 17:47:07 2018 /sbin/ip route add 80.67.181.3/32 via 192.168.1.1
RTNETLINK answers: File exists
Tue Sep 25 17:47:07 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Tue Sep 25 17:47:07 2018 add_route_ipv6(2000::/3 -> 2001:913:1fff:ff00::1 metric -1) dev tun0
Tue Sep 25 17:47:07 2018 /sbin/ip -6 route add 2000::/3 dev tun0
Tue Sep 25 17:47:08 2018 add_route_ipv6(2000::/3 -> 2001:913:1fff:ff00::1 metric -1) dev tun0
Tue Sep 25 17:47:08 2018 /sbin/ip -6 route add 2000::/3 dev tun0
RTNETLINK answers: File exists
Tue Sep 25 17:47:08 2018 ERROR: Linux route -6/-A inet6 add command failed: external program exited with error status: 2
Tue Sep 25 17:47:08 2018 Initialization Sequence Completed
Tue Sep 25 17:50:49 2018 SIGTERM received, sending exit notification to peer
Tue Sep 25 17:50:51 2018 /sbin/ip route del 80.67.181.3/32
Tue Sep 25 17:50:52 2018 /sbin/ip route del 0.0.0.0/1
Tue Sep 25 17:50:52 2018 /sbin/ip route del 128.0.0.0/1
Tue Sep 25 17:50:52 2018 delete_route_ipv6(2000::/3)
Tue Sep 25 17:50:52 2018 /sbin/ip -6 route del 2000::/3 dev tun0
Tue Sep 25 17:50:52 2018 Closing TUN/TAP interface
Tue Sep 25 17:50:52 2018 /sbin/ip addr del dev tun0 80.67.181.213/25
Tue Sep 25 17:50:52 2018 /sbin/ip -6 addr del 2001:913:1fff:ffff::b:d130/64 dev tun0
Tue Sep 25 17:50:52 2018 SIGTERM[soft,exit-with-notification] received, process exiting

OK l’interface tun0 est absente ce qui signifie que la connexion VPN n’est pas active. D’ailleurs c’est confirmé par le log openvpn-client.log :

Tue Sep 25 17:47:07 2018 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
...
Tue Sep 25 17:47:07 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Tue Sep 25 17:47:07 2018 /sbin/ip link set dev tun0 up mtu 1500
Tue Sep 25 17:47:07 2018 /sbin/ip addr add dev tun0 80.67.181.213/25 broadcast 80.67.181.255
Tue Sep 25 17:47:07 2018 /sbin/ip -6 addr add 2001:913:1fff:ffff::b:d130/64 dev tun0
Tue Sep 25 17:47:07 2018 /sbin/ip route add 80.67.181.3/32 via 192.168.1.1
Tue Sep 25 17:47:07 2018 /sbin/ip route add 0.0.0.0/1 via 80.67.181.129
Tue Sep 25 17:47:07 2018 /sbin/ip route add 128.0.0.0/1 via 80.67.181.129
Tue Sep 25 17:47:07 2018 /sbin/ip route add 80.67.181.128/25 via 80.67.181.129
RTNETLINK answers: File exists
Tue Sep 25 17:47:07 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Tue Sep 25 17:47:07 2018 /sbin/ip route add 80.67.181.3/32 via 192.168.1.1
RTNETLINK answers: File exists
Tue Sep 25 17:47:07 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Tue Sep 25 17:47:07 2018 add_route_ipv6(2000::/3 -> 2001:913:1fff:ff00::1 metric -1) dev tun0
Tue Sep 25 17:47:07 2018 /sbin/ip -6 route add 2000::/3 dev tun0
Tue Sep 25 17:47:08 2018 add_route_ipv6(2000::/3 -> 2001:913:1fff:ff00::1 metric -1) dev tun0
Tue Sep 25 17:47:08 2018 /sbin/ip -6 route add 2000::/3 dev tun0
RTNETLINK answers: File exists
Tue Sep 25 17:47:08 2018 ERROR: Linux route -6/-A inet6 add command failed: external program exited with error status: 2
Tue Sep 25 17:47:08 2018 Initialization Sequence Completed
Tue Sep 25 17:50:49 2018 SIGTERM received, sending exit notification to peer
Tue Sep 25 17:50:51 2018 /sbin/ip route del 80.67.181.3/32
Tue Sep 25 17:50:52 2018 /sbin/ip route del 0.0.0.0/1
Tue Sep 25 17:50:52 2018 /sbin/ip route del 128.0.0.0/1
Tue Sep 25 17:50:52 2018 delete_route_ipv6(2000::/3)
Tue Sep 25 17:50:52 2018 /sbin/ip -6 route del 2000::/3 dev tun0
Tue Sep 25 17:50:52 2018 Closing TUN/TAP interface
Tue Sep 25 17:50:52 2018 /sbin/ip addr del dev tun0 80.67.181.213/25
Tue Sep 25 17:50:52 2018 /sbin/ip -6 addr del 2001:913:1fff:ffff::b:d130/64 dev tun0
Tue Sep 25 17:50:52 2018 SIGTERM[soft,exit-with-notification] received,

Là tout de suite j’ai pas le temps d’analyser ça mais il faudrait chercher la signification (les causes) des messages suivants en particulier :

ERROR: Linux route add command failed: external program exited with error status: 2

et

RTNETLINK answers: File exists

Mais peut-être et surtout comprendre pourquoi la connexion qui, malgré les messages d’erreur précédents, semblait s’être établie à 17:47 a-t-elle été stoppée 3 minutes après.

Tue Sep 25 17:47:08 2018 Initialization Sequence Completed
Tue Sep 25 17:50:49 2018 SIGTERM received, sending exit notification to peer

Il y a du nouveau. J’ai de nouveau accès à mon portail, mais

  1. La connexion est inhabituellement lente.
  2. Nextcloud reste inaccessible (mon browser me dit «délai d’attente dépassé» et mon appli dit «operation canceled»).

C’est bon, tout est rentré dans l’ordre tout seul encore une fois. Existe-t-il un moyen pour que ça n’arrive plus ?