[openvpn] 2 petits problemes

Ah, la machine cliente est sous Windows, donc la commande appropriée est [mono]route print[/mono]. Je l’aurais vu si j’avais lu les logs du client.
Si je comprends bien,
XXX.XXX.XXX.198 = adresse du client
XXX.XXX.XXX.254 = passerelle du client
YYY.YYY.YYY.143 = adresse du serveur
YYY.YYY.YYY.254 = passerelle du serveur

J’élague les parties inutiles et je réordonne pour la clarté de l’explication.

Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique XXX.XXX.XXX.0 255.255.255.0 On-link XXX.XXX.XXX.198 276
La route pour la plage d’adresses du réseau local du client XXX.XXX.XXX.0/24, joignable directement (on-link).

Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique 0.0.0.0 0.0.0.0 XXX.XXX.XXX.254 XXX.XXX.XXX.198 20
La route par défaut initiale, via la passerelle du réseau local XXX.XXX.XXX.254. Tout le trafic qui n’est pas couvert par une route plus spécifique passe par là.

Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique XXX.XXX.XXX.1 255.255.255.255 XXX.XXX.XXX.254 XXX.XXX.XXX.198 20
Par contre celle-là, je ne la comprends pas. Une route pour atteindre XXX.XXX.XXX.1 via la passerelle du réseau local, alors que cette adresse fait partie du réseau local XXX.XXX.XXX.0/24 et devrait donc être joignable directement…

Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique 0.0.0.0 128.0.0.0 10.8.0.5 10.8.0.6 30 128.0.0.0 128.0.0.0 10.8.0.5 10.8.0.6 30
Ça, c’est une astuce d’OpenVPN pour forcer l’équivalent d’une nouvelle route par défaut via le VPN sans supprimer ou remplacer la route par défaut originelle. Chacune des deux routes couvre une moitié de l’espace d’adressage global, et a donc une priorité supérieure à la route par défaut qui couvre l’espace d’adressage global entier.

Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique YYY.YYY.YYY.143 255.255.255.255 XXX.XXX.XXX.254 XXX.XXX.XXX.198 20
Et la dernière mais pas la moindre. Elle dit que les paquets destinés à l’adresse publique du serveur YYY.YYY.YYY.143 doivent continuer à être envoyés via la passerelle du réseau local XXX.XXX.XXX.254 et non via le VPN. C’est indispensable car sans cela, le VPN s’effondrerait sur lui-même puisque les paquets transportant le VPN suivraient la nouvelle route par défaut et seraient envoyés dans le VPN ! L’effet secondaire, c’est que les communications entre le client et l’adresse publique du serveur, comme ta connexion SSH, ne passent pas dans le tunnel. Si tu veux communiquer avec le serveur via le VPN, il faut utiliser son adresse interne dans le VPN, 10.8.0.1.

Merci pour toutes ses explications, tout est très clair maintenant.
Je vais pouvoir me lancer dans la phase de test des demain matin.

Merci pour ton aide vraiment. Des que j’ai les résultats des tests, je les poste ici.

Bonjour !

Bon me revoici avec les résultats des tests. C’est vraiment catastrophique !

[code]XXX.XXX.XXX.XXX Server sans VPN
YYY.YYY.YYY.YYY Client sans VPN


root@domain:/home/login# iperf -s -i 1

Server listening on TCP port 1234
TCP window size: 85.3 KByte (default)

[ 4] local XXX.XXX.XXX.XXX port 1234 connected with 1YYY.YYY.YYY.YYY port 51071
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 1.0 sec 65.6 KBytes 537 Kbits/sec
[ 4] 1.0- 2.0 sec 307 KBytes 2.52 Mbits/sec
[ 4] 2.0- 3.0 sec 267 KBytes 2.19 Mbits/sec
[ 4] 3.0- 4.0 sec 320 KBytes 2.62 Mbits/sec
[ 4] 4.0- 5.0 sec 256 KBytes 2.10 Mbits/sec
[ 4] 0.0- 5.5 sec 1.38 MBytes 2.10 Mbits/sec
[ 5] local 10.8.0.1 port 1234 connected with 10.8.0.6 port 51072
[ 5] 0.0- 1.0 sec 7.91 KBytes 64.8 Kbits/sec
[ 5] 1.0- 2.0 sec 21.1 KBytes 173 Kbits/sec
[ 5] 2.0- 3.0 sec 51.4 KBytes 421 Kbits/sec
[ 5] 3.0- 4.0 sec 127 KBytes 1.04 Mbits/sec
[ 5] 4.0- 5.0 sec 120 KBytes 984 Kbits/sec
[ 5] 5.0- 6.0 sec 56.1 KBytes 459 Kbits/sec
[ 5] 0.0- 7.0 sec 512 KBytes 600 Kbits/sec


root@domain:/home/login# iperf -s -u -i 1

Server listening on UDP port 1234
Receiving 1470 byte datagrams
UDP buffer size: 224 KByte (default)

[ 3] local XXX.XXX.XXX.XXX port 1234 connected with YYY.YYY.YYY.YYY port 62340
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 1.0 sec 1.11 MBytes 9.34 Mbits/sec 0.240 ms 54/ 848 (6.4%)
[ 3] 0.0- 1.0 sec 5 datagrams received out-of-order
[ 3] 1.0- 2.0 sec 1.19 MBytes 9.95 Mbits/sec 0.245 ms 3/ 849 (0.35%)
[ 3] 2.0- 3.0 sec 1.19 MBytes 9.98 Mbits/sec 0.276 ms 4/ 853 (0.47%)
[ 3] 3.0- 4.0 sec 1.19 MBytes 9.98 Mbits/sec 0.301 ms 5/ 854 (0.59%)
[ 3] 4.0- 5.0 sec 1.18 MBytes 9.93 Mbits/sec 0.355 ms 6/ 850 (0.71%)
[ 3] 5.0- 6.0 sec 1.19 MBytes 9.96 Mbits/sec 0.290 ms 1/ 848 (0.12%)
[ 3] 6.0- 7.0 sec 1.19 MBytes 9.96 Mbits/sec 0.234 ms 2/ 849 (0.24%)
[ 3] 7.0- 8.0 sec 1.18 MBytes 9.91 Mbits/sec 0.319 ms 8/ 851 (0.94%)
[ 3] 8.0- 9.0 sec 1.18 MBytes 9.93 Mbits/sec 0.299 ms 5/ 849 (0.59%)
[ 3] 9.0-10.0 sec 1.18 MBytes 9.89 Mbits/sec 0.295 ms 7/ 848 (0.83%)
[ 3] 0.0-10.0 sec 11.8 MBytes 9.88 Mbits/sec 0.325 ms 95/ 8501 (1.1%)
[ 3] 0.0-10.0 sec 6 datagrams received out-of-order
[ 4] local 10.8.0.1 port 1234 connected with 10.8.0.6 port 58149
[ 4] 0.0- 1.0 sec 299 KBytes 2.45 Mbits/sec 2.690 ms 307/ 515 (60%)
[ 4] 1.0- 2.0 sec 385 KBytes 3.15 Mbits/sec 3.038 ms 667/ 935 (71%)
[ 4] 2.0- 3.0 sec 376 KBytes 3.08 Mbits/sec 2.469 ms 673/ 935 (72%)
[ 4] 3.0- 4.0 sec 314 KBytes 2.58 Mbits/sec 2.654 ms 543/ 762 (71%)
[ 4] 4.0- 5.0 sec 389 KBytes 3.19 Mbits/sec 2.415 ms 652/ 923 (71%)
[ 4] 5.0- 6.0 sec 314 KBytes 2.58 Mbits/sec 2.689 ms 518/ 737 (70%)
[ 4] 6.0- 7.0 sec 401 KBytes 3.28 Mbits/sec 2.902 ms 665/ 944 (70%)
[ 4] 7.0- 8.0 sec 333 KBytes 2.73 Mbits/sec 13.238 ms 640/ 872 (73%)
[ 4] 8.0- 9.0 sec 355 KBytes 2.90 Mbits/sec 4.223 ms 535/ 782 (68%)
[ 4] 9.0-10.0 sec 385 KBytes 3.15 Mbits/sec 2.627 ms 644/ 912 (71%)
[ 4] 0.0-10.2 sec 3.53 MBytes 2.89 Mbits/sec 6.896 ms 5976/ 8492 (70%)
[ 4] 0.0-10.2 sec 1 datagrams received out-of-order
read failed: Connection refused
[/code]

EDIT 2: J’ai vider les iptables et ca deconne toujours, je ne sais pas d’ou ca vient du coup !!!

EDIT : [Le soucis en dessous est resolu] Bon, je suis ultra mauvaise, j’avais pas de règle pour les DNS, du coup forcement ça ne marche pas. Par contre, ça ne change rien au niveau du vpn. Peut être que ca peut venir de mauvaises regles IPTABLES ?
Dans le doute :

[code]# Generated by iptables-save v1.4.14 on Fri Oct 24 12:37:51 2014
*nat
:PREROUTING ACCEPT [206:10452]
:INPUT ACCEPT [139:4656]
:OUTPUT ACCEPT [18:3683]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT

Completed on Fri Oct 24 12:37:51 2014

Generated by iptables-save v1.4.14 on Fri Oct 24 12:37:51 2014

*filter
:INPUT DROP [5:265]
:FORWARD DROP [0:0]
:OUTPUT DROP [18:3683]
-A INPUT -j LOG
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport https -j ACCEPT
-A INPUT -p tcp -m tcp --dport ssh -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -j LOG
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 465 -j ACCEPT
COMMIT

Completed on Fri Oct 24 12:37:51 2014

[/code]

Je continue de creuser !!!

---------------------------------------------------------------------------------------------------------------- RESOLU -----------------------------------------------------------------------------------------------------

Et je comprends pas une chose, je n’arrive pas a ping google.fr a partir de mon serveur, que ce soit en étant connecté via le VPN ou sans. Par contre, si je le ping de mon client, ça fonctionne, et il me donne l’adresse IP correspondante. De la je ping directement l’IP via le serveur, et ça fonctionne. Je pense donc qu’il y a un soucis de DNS quelque part, ce qui est bizarre car je n’y est pas touché (A par les DNS dans le configuration du VPN, j’avais les DNS google et je suis passé sur les DNS OPENDNS, mais j’ai fait la manip inverse pour un test et ça ne fonctionne toujours pas. Je suis donc repassé sur les DNS OPENDNS).

Voici un petit quelque chose qui pourra peut être aider à comprendre:

[code] dig www.google.fr

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.google.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27211
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.fr. IN A

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Oct 24 08:53:11 2014
;; MSG SIZE rcvd: 31

[/code]

[mono]cat /etc/resolv.conf[/mono]

nameserver 127.0.0.1 nameserver 213.186.33.99 search ovh.net

Je vais chercher du cote des DNS si je trouve quelque chose !

Quel sont les débits supposés des connexions réseau du client et du serveur, en émission et en réception (asymétriques en ADSL) ?

Je ne suis pas particulièrement versé dans les performances des réseaux, mais j’observe que le débit en TCP hors VPN est très inférieur au débit en UDP hors VPN, et du même ordre de grandeur que le débit en UDP dans le VPN, lui-même supérieur au débit en TCP dans le VPN. Le VPN lui-même utilisant un transport TCP, il semble qu’il y a une perte de débit à chaque fois que TCP intervient.

As-tu mesuré les performances dans l’autre sens avec iperf, du serveur vers le client ?

As-tu mesuré la latence et les pertes de paquets entre le client et le serveur, hors et dans le VPN, avec un simple ping et différentes tailles de paquet (de 30 à 1450) ?

Il serait intéressant de comparer avec les débits obtienus en TCP, par exemple en téléchargement HTTP ou FTP, entre le serveur ou le client et un autre serveur web ou FTP.

Tu écris que sans règles iptables ça ne change rien mais les règles de LOG de tous les paquets au début des chaînes ne doivent pas aider, en plus de flooder inutilement les logs système. Pour le reste, il y a quelques doublons inutiles mais ça ne gêne pas.

Bonjour !

Pas de net du weekend, j’en ai vraiment marre du cumul de soucis que j’ai avec les services de communication informatique !!!

J’ai enlevé les règles logs, je m’en servais a la base pour psad, mais je l’ai enlevé aussi.

C’est partit pour les résultats des tests :

En ce qui concerne iperf, j’ai le même type de résultats, même si je change qui est client et qui est serveur.

Voici pour les pings :

[code]nvoi d’une requˆte ‘Ping’ 94.23.5.143 avec 30 octets de donn‚esÿ:
R‚ponse de 94.23.5.143ÿ: octets=30 temps=213 ms TTL=51
R‚ponse de 94.23.5.143ÿ: octets=30 temps=216 ms TTL=51
R‚ponse de 94.23.5.143ÿ: octets=30 temps=214 ms TTL=51
R‚ponse de 94.23.5.143ÿ: octets=30 temps=212 ms TTL=51

Statistiques Ping pour 94.23.5.143:
Paquetsÿ: envoy‚s = 4, re‡us = 4, perdus = 0 (perte 0%),
Dur‚e approximative des boucles en millisecondes :
Minimum = 212ms, Maximum = 216ms, Moyenne = 213ms

Envoi d’une requˆte ‘Ping’ 10.8.0.1 avec 30 octets de donn‚esÿ:
R‚ponse de 10.8.0.1ÿ: octets=30 temps=215 ms TTL=64
R‚ponse de 10.8.0.1ÿ: octets=30 temps=214 ms TTL=64
R‚ponse de 10.8.0.1ÿ: octets=30 temps=217 ms TTL=64
R‚ponse de 10.8.0.1ÿ: octets=30 temps=222 ms TTL=64

Statistiques Ping pour 10.8.0.1:
Paquetsÿ: envoy‚s = 4, re‡us = 4, perdus = 0 (perte 0%),
Dur‚e approximative des boucles en millisecondes :
Minimum = 214ms, Maximum = 222ms, Moyenne = 217ms

Envoi d’une requˆte ‘Ping’ 94.23.5.143 avec 1450 octets de donn‚esÿ:
R‚ponse de 94.23.5.143ÿ: octets=1450 temps=223 ms TTL=51
R‚ponse de 94.23.5.143ÿ: octets=1450 temps=225 ms TTL=51
R‚ponse de 94.23.5.143ÿ: octets=1450 temps=226 ms TTL=51
R‚ponse de 94.23.5.143ÿ: octets=1450 temps=223 ms TTL=51

Statistiques Ping pour 94.23.5.143:
Paquetsÿ: envoy‚s = 4, re‡us = 4, perdus = 0 (perte 0%),
Dur‚e approximative des boucles en millisecondes :
Minimum = 223ms, Maximum = 226ms, Moyenne = 224ms

Envoi d’une requˆte ‘Ping’ 10.8.0.1 avec 1450 octets de donn‚esÿ:
R‚ponse de 10.8.0.1ÿ: octets=1450 temps=214 ms TTL=64
R‚ponse de 10.8.0.1ÿ: octets=1450 temps=214 ms TTL=64
R‚ponse de 10.8.0.1ÿ: octets=1450 temps=222 ms TTL=64
R‚ponse de 10.8.0.1ÿ: octets=1450 temps=220 ms TTL=64

Statistiques Ping pour 10.8.0.1:
Paquetsÿ: envoy‚s = 4, re‡us = 4, perdus = 0 (perte 0%),
Dur‚e approximative des boucles en millisecondes :
Minimum = 214ms, Maximum = 222ms, Moyenne = 217ms[/code]

Pour les debits, apres divers tests, c’est toujours les memes resultats :
FTP : 90kbs contre 420kbs hors VPN.
HTTP : 93kbs contre 406kbs hors VPN.

J’essaie de bien réfléchir a tout ce que j’ai pu faire lors de l’installation de base de mon serveur qui pourrait provoqué ses soucis mais je ne vois rien, et ça fait prés d’une semaine que je passe 8 heures par jour dessus. J’y pense meme avant d’aller me coucher… J’hésite à réinstaller encore une fois le serveur, mais ça fera plus de 10 fois. Ou à passer en UDP… Mais j’ai besoin de comprendre ce qu’il se passe…

Liste des paquets installés :

systemd
exim4
mysql-server
apache2 
apache2-mpm-prefork
php5
git
fail2ban
openvpn

Avec des configurations minimalistes et des iptables. Rien d’autre sinon.

Uname -a

Server OVH. Domaine configuré automatiquement lors de la création du serveur.
DNS d’OPEN DNS.

cat /etc/sysctl.conf

[code]cat /etc/sysctl.conf

/etc/sysctl.conf - Configuration file for setting system variables

See /etc/sysctl.d/ for additonal system variables

See sysctl.conf (5) for information.

#kernel.domainname = example.com

Uncomment the following to stop low-level messages on console

#kernel.printk = 3 4 1 3

##############################################################3

Functions previously found in netbase

Uncomment the next two lines to enable Spoof protection (reverse-path filter)

Turn on Source Address Verification in all interfaces to

prevent some spoofing attacks

#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

Uncomment the next line to enable TCP/IP SYN cookies

See http://lwn.net/Articles/277146/

Note: This may impact IPv6 TCP sessions too

#net.ipv4.tcp_syncookies=1

Uncomment the next line to enable packet forwarding for IPv4

net.ipv4.ip_forward=1

Uncomment the next line to enable packet forwarding for IPv6

Enabling this option disables Stateless Address Autoconfiguration

based on Router Advertisements for this host

#net.ipv6.conf.all.forwarding=1

###################################################################

Additional settings - these settings can improve the network

security of the host and prevent against some network attacks

including spoofing attacks and man in the middle attacks through

redirection. Some network environments, however, require that these

settings are disabled so review and enable them as needed.

Do not accept ICMP redirects (prevent MITM attacks)

#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0

or

Accept ICMP redirects only for gateways listed in our default

gateway list (enabled by default)

net.ipv4.conf.all.secure_redirects = 1

Do not send ICMP redirects (we are not a router)

#net.ipv4.conf.all.send_redirects = 0

Do not accept IP source route packets (we are not a router)

#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0

Log Martian Packets

#net.ipv4.conf.all.log_martians = 1

Disable IPv6 autoconf

net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.eth0.accept_ra = 0
[/code]

Voila, j’essaie de donner toutes les infos (qui me semble) pertinentes.

EDIT : Je viens juste de tester en passant en UDP et ça fonctionne parfaitement. J’ai même moins de perte de paquet en passant via le VPN plutôt qu’en me connectant directement au serveur.
Du coup, ça vient bien du tcp, c’est très étonnant…

Surtout que pas mal de gens utilisent un VPN sur le port 443 en TCP pour pouvoir passer les proxys d’entreprise trop violent… Du coup j’aimerais tout de même réussir a passer en TCP.

Merci.

La latence est assez élevée, mais augmente peu avec la taille des paquets, ce qui est une bonne chose.
Par contre 4 paquets ne suffisent pas à estimer le taux de perte, il en faudrait au moins quelques dizaines (de gros).

[quote=“MissJane”]FTP : 90kbs contre 420kbs hors VPN.
HTTP : 93kbs contre 406kbs hors VPN.[/quote]
Entre quelles machines ?
Tes kbs sont-ils des kilo-bits par seconde ou des kilo-octets par seconde ?
Aussi, tu n’as pas répondu sur les débits supportés par les deux machines.

Si l’utilisation de TCP bride le débit, c’est peut-être du à la conjugaison de la latence avec un taille de fenêtre TCP trop petite, notamment si l’option “TCP window scaling” (valeur dans /proc/sys/net/ipv4/tcp_window_scaling pour Linux) est désactivée sur l’une des deux machines. Avec une latence de ~200 ms, le débit en TCP sans cette option serait bridé à ~300 ko/s.

Bonjour !!!

De retour après une nouvelle enquête intensive.

J’ai donc installé sur deux autres serveurs un VPN, et je me retrouve toujours avec le même soucis. Il est évident que cela ne vient donc pas de la configuration en elle me me, mais probablement du réseau sur le quelle se trouve ma machine.

J’ai testé de réduire le MTU (Le firewall du réseau a peut-être du mal a traiter les paquets de grande taille), mais rien n’y fait.

D’où est ce que cela pourrait venir et quel genre de test puis faire pour glaner des informations a propos de ce problème ?

Merci.

Au même endroit que le premier ?

Avec le même poste client ?

Quel type de réseau ? Comment se fait l’accès à internet ?
As-tu testé depuis un autre poste et/ou via un autre accès internet ?