Installer un serveur mail complet sous Debian 9 Stretch

2017-08-27 Par sujet G2PC 
Bonjour,

Je cherche un tutoriel pour installer un serveur mail complet sous
Debian Stretch.

J'ai trouvé celui-ci :
https://blog.tetsumaki.net/articles/2017/08/installation-dune-solution-mail-complete-sous-debian-9-stretch.html

Si vous avez un support correct, complet, accessible, pour Debian
Stretch, en complément, ou, en remplacement, merci de vos retours.

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet Pascal Hambourg 

Le 27/08/2017 à 19:54, herve.thib...@free.fr a écrit :


systemd-resolve --status

avant et après l'établissement du VPN.

Avant
herve@herve-W54-55SU1-SUW:~$ systemd-resolve --status:
systemd-resolve: unrecognized option '--status:'


Tu n'as pas vu que tu avais fait une erreur de frappe, ":" en trop ?


herve@herve-W54-55SU1-SUW:~$

Après
herve@herve-W54-55SU1-SUW:~$ 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.

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet herve.thib...@free.fr 

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, herve.thib...@free.fr a écrit :


avant ou après la connexion
herve@herve-W54-55SU1-SUW:~$ 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
herve@herve-W54-55SU1-SUW:~$ systemd-resolve --status:
systemd-resolve: unrecognized option '--status:'
herve@herve-W54-55SU1-SUW:~$

Après
herve@herve-W54-55SU1-SUW:~$ 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






herve@herve-W54-55SU1-SUW:~$ host nic.fr
;; connection timed out; no servers could be reached


Donc pas de résolution DNS avec le VPN.


Common NameReal AddressVPN AddressBytes Sent Received

openvpn 88.174.36.83:58208172.27.232.35282.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.

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet herve.thib...@free.fr 

Le 27/08/2017 à 19:38, Pascal Hambourg a écrit :

Le 27/08/2017 à 18:23, herve.thib...@free.fr 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

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet 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, herve.thib...@free.fr a écrit :


avant ou après la connexion
herve@herve-W54-55SU1-SUW:~$ 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.


herve@herve-W54-55SU1-SUW:~$ host nic.fr
;; connection timed out; no servers could be reached


Donc pas de résolution DNS avec le VPN.


Common NameReal AddressVPN AddressBytes Sent Received

openvpn 88.174.36.83:58208172.27.232.35282.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.

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet Pascal Hambourg 

Le 27/08/2017 à 18:23, herve.thib...@free.fr 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).

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet herve.thib...@free.fr 

Le 27/08/2017 à 15:17, Pascal Hambourg a écrit :

Le 27/08/2017 à 14:36, herve.thib...@free.fr 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.



herve@herve-W54-55SU1-SUW:~$ 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 ttl=55 time=35.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=35.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=36.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=36.2 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=36.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=35.2 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=55 time=35.6 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=34.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=36.6 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=55 time=36.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
herve@herve-W54-55SU1-SUW:~$ 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

herve@herve-W54-55SU1-SUW:~$ 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 NameReal AddressVPN AddressBytes Sent Received

openvpn 88.174.36.83:58208172.27.232.35282.52KB 485.01KB
Connection Duration
2:46:41

donc l'adresse VPN est 172.27.232.35


herve@herve-W54-55SU1-SUW:~$ 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 ttl=64 time=0.038 ms
64 bytes from 172.27.232.35: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=3 ttl=64 time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=4 ttl=64 time=0.045 ms
64 bytes from 172.27.232.35: icmp_seq=5 ttl=64 time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=6 ttl=64 time=0.045 ms
64 bytes from 172.27.232.35: icmp_seq=7 ttl=64 time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=8 ttl=64 time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=9 ttl=64 time=0.048 ms
64 bytes from 172.27.232.35: icmp_seq=10 ttl=64 time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=11 ttl=64 time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=12 ttl=64 time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=13 ttl=64 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

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet herve.thib...@free.fr 

Le 27/08/2017 à 13:57, Pascal Hambourg a écrit :

Le 27/08/2017 à 13:22, herve.thib...@free.fr a écrit :

mais rapidement alors que la connexion n'est pas interrompue


Qu'entends-tu par "rapidement" et "pas interrompue" ?


herve@herve-W54-55SU1-SUW:~$ 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 ?


herve@herve-W54-55SU1-SUW:~$ 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 ttl=55 time=35.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=35.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=36.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=36.2 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=36.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=35.2 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=55 time=35.6 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=34.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=36.6 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=55 time=36.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 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 


herve@herve-W54-55SU1-SUW:~$ 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 ttl=64 time=0.038 ms
64 bytes from 172.27.232.35: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=3 ttl=64 time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=4 ttl=64 time=0.045 ms
64 bytes from 172.27.232.35: icmp_seq=5 ttl=64 time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=6 ttl=64 time=0.045 ms
64 bytes from 172.27.232.35: icmp_seq=7 ttl=64 time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=8 ttl=64 time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=9 ttl=64 time=0.048 ms
64 bytes from 172.27.232.35: icmp_seq=10 ttl=64 time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=11 ttl=64 time=0.047 ms
64 bytes from 172.27.232.35: icmp_seq=12 ttl=64 time=0.046 ms
64 bytes from 172.27.232.35: icmp_seq=13 ttl=64 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

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet David Pinson 
Le 27/08/2017 à 14:52, maderios a écrit :
> On 08/27/2017 12:17 PM, Pascal Hambourg wrote:
>
>> Justement, bien souvent ceux qui suivent un tutoriels, on ne leur a
>> pas enseigné la théorie.
>>
> Salut
> Effectivement, les tutoriels donnent des "trucs" pour réussir une
> opération mais, malheureusement, n'expliquent rien. Il est beaucoup
> plus facile d'agir quand on comprend le pourquoi de ce que l'on fait.
> Certains tutoriels incluent un minimum de théorie, ce sont
> (paradoxalement) les plus simples à utiliser.
>
Je profite de ce message pour lancer une citation célèbre :

"La théorie, c’est quand on sait tout et que rien ne fonctionne.
La pratique, c’est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique :
Rien ne fonctionne… et personne ne sait pourquoi !*"
*(Albert Einstein)

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet David Pinson 
Le 27/08/2017 à 12:17, Pascal Hambourg a écrit :
> Le 27/08/2017 à 10:32, David Pinson a écrit :
>>
>> L'avantage des tutos est de comprendre par la pratique le pourquoi du
>> comment faire.
>
> Les tutoriels décrivent le comment, mais plus rarement le pourquoi.
> Parfois ce serait juste impossible, les explications théoriques
> dépasseraient en volume les instructions pratiques et ce ne serait
> plus vraiment un tutoriel.
>
> Je pense qu'il est impératif de comprendre la motivation et les effets
> de chaque action décrite dans un tutoriel. C'est nécessaire pour
> savoir quand ne pas suivre à la lettre un tutoriel parce qu'on est
> dans un cas particulier qui demande un ajustement.
>
>> On nous enseigne souvent la théorie avant la pratique et on a toujours
>> besoin d'un repère dans l'espace auquel appartient le sujet de la
>> théorie.
>
> Justement, bien souvent ceux qui suivent un tutoriels, on ne leur a
> pas enseigné la théorie.
>
>Salut
>Effectivement, les tutoriels donnent des "trucs" pour réussir une
opération mais, malheureusement,
>n'expliquent rien. Il est beaucoup plus facile d'agir quand on comprend
le pourquoi de ce que l'on fait. Certains
>tutoriels incluent un minimum de théorie, ce sont (paradoxalement) les
plus simples à utiliser.

Ce n'est pas faux ce que tu écris,
je pense qu'il serait très intéressant de distinguer les utilisateurs
qui utilisent les tutos.

Un exemple pour mon cas: je suis technicien supérieur et j'utilise cette
méthode pour mieux appréhender les théories et les explications issues
de la commande 'man'.
Libre à vous d'adapter vos avis, il y aura toujours le pour et le contre.

Librement,
David

"... La connaissance s’acquiert par l’expérience, tout le reste n’est
que de l’information..." *– Albert Einstein*

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet Pascal Hambourg 

Le 27/08/2017 à 14:36, herve.thib...@free.fr 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.



herve@herve-W54-55SU1-SUW:~$ 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 ttl=55 time=35.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=35.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=36.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=36.2 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=36.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=35.2 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=55 time=35.6 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=34.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=36.6 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=55 time=36.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.

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet herve.thib...@free.fr 

Le 27/08/2017 à 13:57, Pascal Hambourg a écrit :

Le 27/08/2017 à 13:22, herve.thib...@free.fr a écrit :

mais rapidement alors que la connexion n'est pas interrompue


Qu'entends-tu par "rapidement" et "pas interrompue" ?


herve@herve-W54-55SU1-SUW:~$ 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 ?


herve@herve-W54-55SU1-SUW:~$ 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 ttl=55 time=35.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=35.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=36.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=36.2 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=36.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=35.2 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=55 time=35.6 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=34.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=36.6 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=55 time=36.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

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet maderios 

On 08/27/2017 12:17 PM, Pascal Hambourg wrote:

Justement, bien souvent ceux qui suivent un tutoriels, on ne leur a pas 
enseigné la théorie.



Salut
Effectivement, les tutoriels donnent des "trucs" pour réussir une 
opération mais, malheureusement, n'expliquent rien. Il est beaucoup plus 
facile d'agir quand on comprend le pourquoi de ce que l'on fait. 
Certains tutoriels incluent un minimum de théorie, ce sont 
(paradoxalement) les plus simples à utiliser.


--
Maderios

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet Pascal Hambourg 

Le 27/08/2017 à 13:22, herve.thib...@free.fr a écrit :

mais rapidement alors que la connexion n'est pas interrompue


Qu'entends-tu par "rapidement" et "pas interrompue" ?


herve@herve-W54-55SU1-SUW:~$ 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   *  *  *


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.


Que donne un traceroute vers 8.8.8.8 par exemple ?

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet herve.thib...@free.fr 

Le 26/08/2017 à 22:33, Pascal Hambourg a écrit :

Le 26/08/2017 à 16:39, hervé thibaud a écrit :


Package tout installé pour vous montrer mes capacités en infomatique


Qu'est-ce c'est censé nous dire de tes capacités ?


tes questions sur adresse publique et interne IP ne m'inspire pas


Je n'ai pas posé de questions, j'ai juste suggéré des tests.

L'adresse IP publique, c'est celle que tu mets dans la configuration 
de ton client VPN pour se connecter au serveur. Quand tu fais un ping 
ou traceroute vers cette adresse, ça ne passe pas dans le VPN mais ça 
prend le même chemin que lui.


L'adresse IP interne, c'est celle qui est configurée sur l'interface 
tun ou tap matérialisant le VPN sur le serveur. Quand tu fais un ping 
ou traceroute vers cette adresse, ça passe dans le VPN.


car à ma connaissance je n'ai qu'une ip qui m'a été fournie et l'état 
de l'interface VPN ne me parle pas beaucoup


ifconfig -a
ip addr

j'ai suivi le tuto pour installer le client sur mon linux ubuntu 
17.04 et android sur un mon smartphone galaxy s5


Je soupçonne que le "syndrome du tuto" a encore frappé : on suit des 
instructions bêtement sans rien y comprendre.



ping et traceroute vers adresse du VPS

herve@herve-W54-55SU1-SUW:~$ ping 37.59.122.236
PING 37.59.122.236 (37.59.122.236) 56(84) bytes of data.
64 bytes from 37.59.122.236: icmp_seq=1 ttl=51 time=30.1 ms
64 bytes from 37.59.122.236: icmp_seq=2 ttl=51 time=29.4 ms
64 bytes from 37.59.122.236: icmp_seq=3 ttl=51 time=28.8 ms
64 bytes from 37.59.122.236: icmp_seq=4 ttl=51 time=29.3 ms
64 bytes from 37.59.122.236: icmp_seq=5 ttl=51 time=29.0 ms
64 bytes from 37.59.122.236: icmp_seq=6 ttl=51 time=30.0 ms
64 bytes from 37.59.122.236: icmp_seq=7 ttl=51 time=30.0 ms
64 bytes from 37.59.122.236: icmp_seq=8 ttl=51 time=29.3 ms
^C
--- 37.59.122.236 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7010ms
rtt min/avg/max/mdev = 28.817/29.547/30.189/0.479 ms

herve@herve-W54-55SU1-SUW:~$ traceroute 37.59.122.236
traceroute to 37.59.122.236 (37.59.122.236), 64 hops max
  1   192.168.0.254  0,697ms  0,591ms  0,579ms
  2   88.174.36.254  16,800ms  18,146ms  18,201ms
  3   213.228.11.254  18,541ms  17,733ms  17,937ms
  4   194.149.161.177  18,963ms  19,585ms  19,872ms
  5   194.149.162.109  26,845ms  23,755ms  31,956ms
  6   194.149.163.170  26,182ms  24,217ms  24,945ms
  7   213.186.32.237  26,220ms  24,187ms  24,608ms
  8   *  *  *
  9   *  *  *
 10   37.187.232.75  30,111ms  29,353ms  29,320ms
 11   *  *  *
 12   51.255.246.234  30,537ms  28,498ms  28,361ms
 13   *  *  *
 14   37.59.122.236  30,058ms  29,441ms  29,552ms

ifconfig -a
enp3s0f1: flags=4163  mtu 1500
inet 192.168.0.13  netmask 255.255.255.0  broadcast 192.168.0.255
inet6 fe80::5507:f86b:a9c7:861b  prefixlen 64  scopeid 0x20
ether 80:fa:5b:22:80:0d  txqueuelen 1000  (Ethernet)
RX packets 20125  bytes 12536818 (12.5 MB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 18703  bytes 2659753 (2.6 MB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1000  (Boucle locale)
RX packets 1113  bytes 82953 (82.9 KB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 1113  bytes 82953 (82.9 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305 mtu 1500
inet 172.27.232.31  netmask 255.255.248.0  destination 
172.27.232.31

inet6 fe80::8d1d:6d3e:afef:fcd  prefixlen 64  scopeid 0x20
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
txqueuelen 100  (UNSPEC)

RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 7  bytes 352 (352.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp2s0: flags=4098  mtu 1500
ether 1e:16:20:60:1c:1c  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000

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: enp3s0f1:  mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000

link/ether 80:fa:5b:22:80:0d brd ff:ff:ff:ff:ff:ff
inet 192.168.0.13/24 brd 192.168.0.255 scope global dynamic enp3s0f1
   valid_lft 849460sec preferred_lft 849460sec
inet6 fe80::5507:f86b:a9c7:861b/64 scope link

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet Pascal Hambourg 

Le 27/08/2017 à 10:32, David Pinson a écrit :


L'avantage des tutos est de comprendre par la pratique le pourquoi du
comment faire.


Les tutoriels décrivent le comment, mais plus rarement le pourquoi.
Parfois ce serait juste impossible, les explications théoriques 
dépasseraient en volume les instructions pratiques et ce ne serait plus 
vraiment un tutoriel.


Je pense qu'il est impératif de comprendre la motivation et les effets 
de chaque action décrite dans un tutoriel. C'est nécessaire pour savoir 
quand ne pas suivre à la lettre un tutoriel parce qu'on est dans un cas 
particulier qui demande un ajustement.



On nous enseigne souvent la théorie avant la pratique et on a toujours
besoin d'un repère dans l'espace auquel appartient le sujet de la théorie.


Justement, bien souvent ceux qui suivent un tutoriels, on ne leur a pas 
enseigné la théorie.

Re: utilisation open.vpn chez OVH

2017-08-27 Par sujet David Pinson 
Le 27/08/2017 à 00:02, Pierre L. a écrit :
> Bon faut avouer aussi que bien souvent, le "tuto" n'apporte pas les
> infos nécessaires à comprendre les commandes qu'on balance dans un
> terminal ;)
> Parfois c'est très bien documenté, avec chaque argument bien détaillé,
> un bonheur !
>
> Sinon il se trouve où le tuto que tu as suivi ? Il y a peut-être une
> coquille dedans ? Les experts dans l'ombre pourront zieuter au cas où...
>
>
>
> Le 26/08/2017 à 22:33, Pascal Hambourg a écrit :
>> Je soupçonne que le "syndrome du tuto" a encore frappé : on suit des
>> instructions bêtement sans rien y comprendre.
Bonjour,

L'avantage des tutos est de comprendre par la pratique le pourquoi du
comment faire.

On nous enseigne souvent la théorie avant la pratique et on a toujours
besoin d'un repère
dans l'espace auquel appartient le sujet de la théorie.
Me tromperai-je ?

Librement vôtre,
David