Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian utilisation open.vpn chez OVH

utilisation open.vpn chez OVH

23 réponses
Avatar
herve.thibaud
Bonjour,

j'ai installé en automatique un vps debian avec openvpn
j'ai autorisé l'utilisateur par défaut en autologin pour terminer la
configuration
j'ai téléchargé le client.openvpn
je lance "openvpn --config client.ovpn" sur un terminal
je test la connexion à l'adresse "https://ifconfig.ovh" qui affiche la
même IP que celle la connexion à OVH
je peux utiliser internet
au bout de 30s environ, la connexion se bloque et je suis obligé
d'interrompre le processus "openvpn --config client.ovpn" pour retrouver
l'IP de ma box
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
herve.thibaud
Le 27/08/2017 à 13:57, Pascal Hambourg a écrit :
Le 27/08/2017 à 13:22, a écrit :
mais rapidement alors que la connexion n'est pas interrompue

Qu'entends-tu par "rapidement" et "pas interrompue" ?
:~$ traceroute 172.27.232.29
traceroute to 172.27.232.29 (172.27.232.29), 64 hops max
1 172.27.232.1 29,875ms 30,224ms 30,131ms
2 * * *
3 * * *
4 * * *
5 * * *


lors de la connexion vpn j'ai
Sun Aug 27 13:44:01 2017 TUN/TAP device tun0 opened
Sun Aug 27 13:44:01 2017 TUN/TAP TX queue length set to 100
Sun Aug 27 13:44:01 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Aug 27 13:44:01 2017 /sbin/ip link set dev tun0 up mtu 1500
Sun Aug 27 13:44:01 2017 /sbin/ip addr add dev tun0 172.27.232.33/21
broadcast 172.27.239.255
A quoi correspondent les adresses 172.27.232.29 et 172.27.232.1 ?
En tout cas, il y quelque chose à l'autre bout du VPN qui répond avec
l'adresse 172.27.232.1.

je ne sais pas pourquoi j'ai tapé 29 alors que sans doute je devrais
taper 33
donc
traceroute to 172.27.232.33 (172.27.232.33), 64 hops max
1 172.27.232.33 0,006ms 0,002ms 0,001ms
et la route est trouvée immédiatement
Que donne un traceroute vers 8.8.8.8 par exemple ?

:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttlU time5.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttlU time5.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttlU time6.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttlU time6.2 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttlU time6.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttlU time5.2 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttlU time5.6 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttlU time4.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttlU time6.6 ms
64 bytes from 8.8.8.8: icmp_seq ttlU time6.1 ms
^C
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 34.705/35.770/36.615/0.619 ms
Mais le navigateur web est très rapidement inutilisable avec la connexion
pourquoi aussi pour connecter je suis obligé de le faire comme root par
sudo?
sudo openvpn --config client.ovpn
Avatar
Pascal Hambourg
Le 27/08/2017 à 14:36, a écrit :
lors de la connexion vpn j'ai
Sun Aug 27 13:44:01 2017 TUN/TAP device tun0 opened
Sun Aug 27 13:44:01 2017 TUN/TAP TX queue length set to 100
Sun Aug 27 13:44:01 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Aug 27 13:44:01 2017 /sbin/ip link set dev tun0 up mtu 1500
Sun Aug 27 13:44:01 2017 /sbin/ip addr add dev tun0 172.27.232.33/21
broadcast 172.27.239.255
A quoi correspondent les adresses 172.27.232.29 et 172.27.232.1 ?
En tout cas, il y quelque chose à l'autre bout du VPN qui répond avec
l'adresse 172.27.232.1.

je ne sais pas pourquoi j'ai tapé 29 alors que sans doute je devrais
taper 33

Non, ça c'est l'adresse de l'interface VPN (tun0) sur ta propre machine
cliente.
donc
traceroute to 172.27.232.33 (172.27.232.33), 64 hops max
1 172.27.232.33 0,006ms 0,002ms 0,001ms
et la route est trouvée immédiatement

Forcément puisque c'est la machine cliente. On peut le voir à au temps
quasi-nul.
:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttlU time5.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttlU time5.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttlU time6.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttlU time6.2 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttlU time6.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttlU time5.2 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttlU time5.6 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttlU time4.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttlU time6.6 ms
64 bytes from 8.8.8.8: icmp_seq ttlU time6.1 ms
^C
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 34.705/35.770/36.615/0.619 ms
Mais le navigateur web est très rapidement inutilisable avec la connexion

Ah, le navigateur web ! Mais ce n'est pas "internet", ça ne prouve pas
que "la connexion se bloque".
La connectivité IP semble bonne. Il faut regarder la résolution DNS.
Que contient le fichier /etc/resolv.conf avec et sans VPN ?
Qu'affiche
host nic.fr
sans VPN, avec VPN quand le navigateur fonctionne et avec VPN quand le
navigateur ne fonctionne plus ?
pourquoi aussi pour connecter je suis obligé de le faire comme root par
sudo?

Parce que ça modifie la configuration réseau (création d'interface,
configuration d'adresse IP, modification des routes...), ce qui requiert
les privilèges administrateur.
Avatar
herve.thibaud
Le 27/08/2017 à 13:57, Pascal Hambourg a écrit :
Le 27/08/2017 à 13:22, a écrit :
mais rapidement alors que la connexion n'est pas interrompue

Qu'entends-tu par "rapidement" et "pas interrompue" ?
:~$ traceroute 172.27.232.29
traceroute to 172.27.232.29 (172.27.232.29), 64 hops max
1 172.27.232.1 29,875ms 30,224ms 30,131ms
2 * * *
3 * * *
4 * * *
5 * * *


lors de la connexion vpn j'ai
Sun Aug 27 13:44:01 2017 TUN/TAP device tun0 opened
Sun Aug 27 13:44:01 2017 TUN/TAP TX queue length set to 100
Sun Aug 27 13:44:01 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Aug 27 13:44:01 2017 /sbin/ip link set dev tun0 up mtu 1500
Sun Aug 27 13:44:01 2017 /sbin/ip addr add dev tun0 172.27.232.33/21
broadcast 172.27.239.255
A quoi correspondent les adresses 172.27.232.29 et 172.27.232.1 ?
En tout cas, il y quelque chose à l'autre bout du VPN qui répond avec
l'adresse 172.27.232.1.

je ne sais pas pourquoi j'ai tapé 29 alors que sans doute je devrais
taper 33
donc
traceroute to 172.27.232.33 (172.27.232.33), 64 hops max
1 172.27.232.33 0,006ms 0,002ms 0,001ms
et la route est trouvée immédiatement
Que donne un traceroute vers 8.8.8.8 par exemple ?

:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttlU time5.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttlU time5.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttlU time6.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttlU time6.2 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttlU time6.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttlU time5.2 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttlU time5.6 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttlU time4.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttlU time6.6 ms
64 bytes from 8.8.8.8: icmp_seq ttlU time6.1 ms
^C
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 34.705/35.770/36.615/0.619 ms
Mais le navigateur web est très rapidement inutilisable avec la connexion
if config.ovh ne r&pond plus
voilà ce ce que me donne
Current VPN Users
Common Name Real Address VPN Address Bytes Sent Received openvpn
88.174.36.83:58208 172.27.232.35 282.52KB 485.01KB
Connection Duration
2:46:41
:~$ ping 172.27.232.35
PING 172.27.232.35 (172.27.232.35) 56(84) bytes of data.
64 bytes from 172.27.232.35: icmp_seq=1 ttld time=0.038 ms
64 bytes from 172.27.232.35: icmp_seq=2 ttld time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=3 ttld time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=4 ttld time=0.045 ms
64 bytes from 172.27.232.35: icmp_seq=5 ttld time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=6 ttld time=0.045 ms
64 bytes from 172.27.232.35: icmp_seq=7 ttld time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=8 ttld time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=9 ttld time=0.048 ms
64 bytes from 172.27.232.35: icmp_seq ttld time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq ttld time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq ttld time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq ttld time=0.049 ms
^C
--- 172.27.232.35 ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12295ms
rtt min/avg/max/mdev = 0.038/0.045/0.049/0.009 ms
pourquoi aussi pour connecter je suis obligé de le faire comme root par
sudo?
sudo openvpn --config client.ovpn
la connexion est censée être active
Avatar
Pascal Hambourg
Le 27/08/2017 à 18:23, a écrit :
(coupé)

Pas grand-chose de nouveau, on dirait une copie de ton précédent message
en réponse à mon avant-dernier message.
Si tu veux qu'on avance, il vaudrait mieux répondre aux questions de mon
dernier message (suspect : DNS).
Avatar
herve.thibaud
Le 27/08/2017 à 15:17, Pascal Hambourg a écrit :
Le 27/08/2017 à 14:36, a écrit :
lors de la connexion vpn j'ai
Sun Aug 27 13:44:01 2017 TUN/TAP device tun0 opened
Sun Aug 27 13:44:01 2017 TUN/TAP TX queue length set to 100
Sun Aug 27 13:44:01 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Aug 27 13:44:01 2017 /sbin/ip link set dev tun0 up mtu 1500
Sun Aug 27 13:44:01 2017 /sbin/ip addr add dev tun0 172.27.232.33/21
broadcast 172.27.239.255
A quoi correspondent les adresses 172.27.232.29 et 172.27.232.1 ?
En tout cas, il y quelque chose à l'autre bout du VPN qui répond
avec l'adresse 172.27.232.1.

je ne sais pas pourquoi j'ai tapé 29 alors que sans doute je devrais
taper 33

Non, ça c'est l'adresse de l'interface VPN (tun0) sur ta propre
machine cliente.
donc
traceroute to 172.27.232.33 (172.27.232.33), 64 hops max
1 172.27.232.33 0,006ms 0,002ms 0,001ms
et la route est trouvée immédiatement

Forcément puisque c'est la machine cliente. On peut le voir à au temps
quasi-nul.
:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttlU time5.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttlU time5.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttlU time6.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttlU time6.2 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttlU time6.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttlU time5.2 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttlU time5.6 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttlU time4.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttlU time6.6 ms
64 bytes from 8.8.8.8: icmp_seq ttlU time6.1 ms
^C
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 34.705/35.770/36.615/0.619 ms
Mais le navigateur web est très rapidement inutilisable avec la
connexion

Ah, le navigateur web ! Mais ce n'est pas "internet", ça ne prouve pas
que "la connexion se bloque".
La connectivité IP semble bonne. Il faut regarder la résolution DNS.
Que contient le fichier /etc/resolv.conf avec et sans VPN ?

(dans le dernier message envoyé j'avais modifié la fin avec d'autres
informations)
avant ou après la connexion
:~$ cat /etc/resolv.conf
# 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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual
nameservers.
nameserver 127.0.0.53
Qu'affiche
host nic.fr

:~$ host nic.fr
;; connection timed out; no servers could be reached
même si je reactive la connexion pour faire immédiatement un host nic.fr
sans VPN, avec VPN quand le navigateur fonctionne et avec VPN quand le
navigateur ne fonctionne plus ?
pourquoi aussi pour connecter je suis obligé de le faire comme root
par sudo?

Parce que ça modifie la configuration réseau (création d'interface,
configuration d'adresse IP, modification des routes...), ce qui
requiert les privilèges administrateur.

ci dessous ce que j'avais ajouté à ma réponse
voilà ce ce que me donne
Current VPN Users
Common Name Real Address VPN Address Bytes Sent Received
openvpn 88.174.36.83:58208 172.27.232.35 282.52KB 485.01KB
Connection Duration
2:46:41
donc l'adresse VPN est 172.27.232.35
:~$ ping 172.27.232.35
PING 172.27.232.35 (172.27.232.35) 56(84) bytes of data.
64 bytes from 172.27.232.35: icmp_seq=1 ttld time=0.038 ms
64 bytes from 172.27.232.35: icmp_seq=2 ttld time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=3 ttld time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=4 ttld time=0.045 ms
64 bytes from 172.27.232.35: icmp_seq=5 ttld time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=6 ttld time=0.045 ms
64 bytes from 172.27.232.35: icmp_seq=7 ttld time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=8 ttld time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=9 ttld time=0.048 ms
64 bytes from 172.27.232.35: icmp_seq ttld time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq ttld time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq ttld time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq ttld time=0.049 ms
^C
--- 172.27.232.35 ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12295ms
rtt min/avg/max/mdev = 0.038/0.045/0.049/0.009 ms
Avatar
Pascal Hambourg
Ne tiens pas compte de ma réponse précédente, nos messages se sont croisés.
Le 27/08/2017 à 19:19, a écrit :
avant ou après la connexion
:~$ cat /etc/resolv.conf
# 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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual
nameservers.
nameserver 127.0.0.53

Et zut, c'est ce que je craignais, un résolveur local. Suivons donc le
jeu de piste avec la commande aimablement indiquée dans le fichier :
systemd-resolve --status
avant et après l'établissement du VPN.
:~$ host nic.fr
;; connection timed out; no servers could be reached

Donc pas de résolution DNS avec le VPN.
Common Name Real Address VPN Address Bytes Sent Received
openvpn 88.174.36.83:58208 172.27.232.35 282.52KB 485.01KB
Connection Duration
2:46:41
donc l'adresse VPN est 172.27.232.35

C'est encore l'adresse locale de ton PC, aucun intérêt. On n'en est plus
là de toute façon.
Avatar
herve.thibaud
Le 27/08/2017 à 19:38, Pascal Hambourg a écrit :
Le 27/08/2017 à 18:23, a écrit :
(coupé)

Pas grand-chose de nouveau, on dirait une copie de ton précédent
message en réponse à mon avant-dernier message.
Si tu veux qu'on avance, il vaudrait mieux répondre aux questions de
mon dernier message (suspect : DNS).

?
j'ai répondu à ta demande
nameserver 127.0.0.5 et host nic.fr
Avatar
herve.thibaud
Le 27/08/2017 à 19:44, Pascal Hambourg a écrit :
Ne tiens pas compte de ma réponse précédente, nos messages se sont
croisés.
Le 27/08/2017 à 19:19, a écrit :
avant ou après la connexion
:~$ cat /etc/resolv.conf
# 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
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual
nameservers.
nameserver 127.0.0.53

Et zut, c'est ce que je craignais, un résolveur local. Suivons donc le
jeu de piste avec la commande aimablement indiquée dans le fichier :
systemd-resolve --status
avant et après l'établissement du VPN.

Avant
:~$ systemd-resolve --status:
systemd-resolve: unrecognized option '--status:'
:~$
Après
:~$ systemd-resolve --status
Global
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 15 (tun0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 3 (wlp2s0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 2 (enp3s0f1)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 212.27.40.241
212.27.40.240
:~$ host nic.fr
;; connection timed out; no servers could be reached

Donc pas de résolution DNS avec le VPN.
Common Name Real Address VPN Address Bytes Sent Received
openvpn 88.174.36.83:58208 172.27.232.35 282.52KB 485.01KB
Connection Duration
2:46:41
donc l'adresse VPN est 172.27.232.35

C'est encore l'adresse locale de ton PC, aucun intérêt. On n'en est
plus là de toute façon.
Avatar
Pascal Hambourg
Le 27/08/2017 à 19:54, a écrit :
systemd-resolve --status
avant et après l'établissement du VPN.

Avant
:~$ systemd-resolve --status:
systemd-resolve: unrecognized option '--status:'

Tu n'as pas vu que tu avais fait une erreur de frappe, ":" en trop ?
:~$
Après
:~$ systemd-resolve --status

(coupe)
Link 15 (tun0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no

Le VPN n'a pas configuré de DNS.
Link 2 (enp3s0f1)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 212.27.40.241
212.27.40.240

Ce sont les DNS du FAI reçus par l'interface ethernet. Or les DNS d'un
FAI sont généralement inaccessibles seulement depuis une adresse IP
appartenant au FAI. Les DNS de Free sont inaccessibles depuis l'adresse
IP du VPS appartenant à OVH.
Il faut que le serveur VPN fournisse les adresses de DNS qui sont
indiquées dans son propre /etc/resolv.conf.
Avatar
herve.thibaud
J'ai abandonné l'utilisation du client openvpn car en fait la version
(debian 2.3.4 ou ubuntu 2.4.0) et la version utilisée pour créer le
serveur OVH openvpn version 2.1.6 ne sont pas compatibles
j'ai donc installé network-manager-openvpn et network-manager-openvpn-gnome
tout se passe bien sur ubuntu qui décortique le fichier de
configuration client.ovpn récupéré. Il configure la connexion OVH pour
network-manager par contre debian ne sait pas interpréter le fichier de
configuration client.ovpn et je n'arrive pas à le faire manuellement en
récupérant les informations sur la partition ubuntu
Déjà je réussis à me connecter via ubuntu et mon smatphone android.
c'est un grand pas.
Voici ce que me donne le dernier essai de connexion dans le fichier syslog
Sep 5 13:01:23 debian NetworkManager[485]: <info> VPN connection 'OVH
2' (ConnectInteractive) reply received.
Sep 5 13:01:23 debian nm-openvpn[1730]: OpenVPN 2.3.4
x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6]
built on Jun 26 2017
Sep 5 13:01:23 debian nm-openvpn[1730]: library versions: OpenSSL
1.0.1t 3 May 2016, LZO 2.08
Sep 5 13:01:23 debian nm-openvpn[1730]: NOTE: the current
--script-security setting may allow this configuration to call
user-defined scripts
Sep 5 13:01:23 debian nm-openvpn[1730]: Control Channel Authentication:
using '/home/herve/.cert/nm-openvpn/client-tls-auth.pem' as a OpenVPN
static key file
Sep 5 13:01:23 debian nm-openvpn[1730]: RESOLVE: Cannot resolve host
address: 37.59.122.236:1194:udp: Name or service not known
Sep 5 13:01:23 debian nm-openvpn[1730]: RESOLVE: Cannot resolve host
address: 37.59.122.236:1194:udp: Name or service not known
Sep 5 13:01:23 debian nm-openvpn[1730]: SIGUSR1[soft,init_instance]
received, process restarting
..............................................................................
Sep 5 13:01:59 debian nm-openvpn[1730]: NOTE: the current
--script-security setting may allow this configuration to call
user-defined scripts
Sep 5 13:01:59 debian nm-openvpn[1730]: RESOLVE: Cannot resolve host
address: 37.59.122.236:443:tcp: Name or service not known
Sep 5 13:01:59 debian nm-openvpn[1730]: RESOLVE: Cannot resolve host
address: 37.59.122.236:443:tcp: Name or service not known
Sep 5 13:01:59 debian nm-openvpn[1730]: SIGUSR1[soft,init_instance]
received, process restarting
Sep 5 13:02:01 debian nm-openvpn[1730]: NOTE: the current
--script-security setting may allow this configuration to call
user-defined scripts
Sep 5 13:02:01 debian nm-openvpn[1730]: RESOLVE: Cannot resolve host
address: 37.59.122.236:1194:udp: Name or service not known
Sep 5 13:02:01 debian nm-openvpn[1730]: RESOLVE: Cannot resolve host
address: 37.59.122.236:1194:udp: Name or service not known
Sep 5 13:02:01 debian nm-openvpn[1730]: SIGUSR1[soft,init_instance]
received, process restarting
Sep 5 13:02:03 debian NetworkManager[485]: <warn> VPN connection 'OVH
2' connect timeout exceeded.
Sep 5 13:02:03 debian nm-openvpn[1730]: SIGTERM[hard,init_instance]
received, process exiting
Sep 5 13:02:03 debian NetworkManager[485]: nm-openvpn-Message:
Terminated openvpn daemon with PID 1730.
Sep 5 13:02:23 debian NetworkManager[485]: <info> VPN service 'openvpn'
disappeared
1 2 3