Openvpn, transfère les paquets très lentement

10

J'ai redémarré mon serveur et un problème étrange vient de se produire. Je fonctionne sur ArchLinux, les clients sont Ubuntu, Android et Mac.

Le problème est que l'accès à Internet via les clients est lent, environ 2ko / s et s'arrête lentement.

Mais le téléchargement direct du serveur vers le client s'effectue à pleine vitesse. Et, évidemment, Internet depuis le serveur est à sa pleine vitesse (40mo / s).

Je ne sais pas ce qui s'est passé depuis le redémarrage, mais ce problème est présent sur tous les clients et est uniquement lié au trafic qui ouvre openvpn vers Internet.

EDIT: essayé avec TCP, n'a pas résolu. EDIT: Test de divers paramètres fragment / mtu, aucun changement.

Voici tous mes confs:

╭─<root@Alduin>-</etc/openvpn>-<1:45:07>-◇
╰─➤ cat Alduin.conf ccd/Thunderaan
local 212.83.129.104
port 1194
proto udp
dev tun
ca keys/ca.crt
cert keys/Alduin.crt
key keys/Alduin.key
dh keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 10.8.0.1"
client-to-client
keepalive 5 60
ping-timer-rem
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
client-config-dir ccd
topology subnet

ccd from here +++++++++++++++


ifconfig-push 10.8.0.2 255.255.255.0
push "redirect-gateway def1"

Client conf:

client
dev tun
proto udp
remote 212.83.129.104 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert name.crt
key name.key
ns-cert-type server
comp-lzo
verb 3

et quelques résultats qui pourraient vous aider: 

╭─<cubox@Alduin>-<~>-<1:49:43>-◇
╰─➤ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    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: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether b8:ac:6f:94:e2:4e brd ff:ff:ff:ff:ff:ff
    inet 88.190.15.135/24 scope global eno1
       valid_lft forever preferred_lft forever
    inet 212.83.129.104/32 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 2001:bc8:300a:dead::b12d/64 scope global
       valid_lft forever preferred_lft forever
    inet6 2a01:e0b:1000:15:baac:6fff:fe94:e24e/64 scope global dynamic
       valid_lft 2592000sec preferred_lft 604800sec
    inet6 fe80::baac:6fff:fe94:e24e/64 scope link
       valid_lft forever preferred_lft forever
3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether b8:ac:6f:94:e2:4f brd ff:ff:ff:ff:ff:ff
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
╭─<cubox@Alduin>-<~>-<1:49:47>-◇
╰─➤ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         88-190-15-1.rev 0.0.0.0         UG    0      0        0 eno1
10.8.0.0        *               255.255.255.0   U     0      0        0 tun0
88.190.15.0     *               255.255.255.0   U     0      0        0 eno1
╭─<cubox@Alduin>-<~>-<1:49:51>-◇
╰─➤ route -6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
::1/128                        ::                         U    256 0     0 lo
2001:bc8:300a:dead::/64        ::                         U    256 0     0 eno1
2a01:e0b:1000:15::/64          ::                         UAe  256 0     0 eno1
fe80::/64                      ::                         U    256 0     0 eno1
::/0                           fe80::225:45ff:fef6:947f   UGDAe 1024 2     0 eno1
::/0                           ::                         !n   -1  1  1891 lo
::1/128                        ::                         Un   0   2  5227 lo
2001:bc8:300a:dead::/128       ::                         Un   0   1     0 lo
2001:bc8:300a:dead::b12d/128   ::                         Un   0   1   131 lo
2a01:e0b:1000:15::/128         ::                         Un   0   1     0 lo
2a01:e0b:1000:15:baac:6fff:fe94:e24e/128 ::                         Un   0   3 29356 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::baac:6fff:fe94:e24e/128  ::                         Un   0   1   311 lo
ff00::/8                       ::                         U    256 0     0 eno1
::/0                           ::                         !n   -1  1  1891 lo



-A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE # The iptables rule

La règle iptables ici est la seule qui est active sur le serveur.

╰─➤ tc qd
qdisc mq 0: dev eno1 root
qdisc pfifo_fast 0: dev tun0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

EDIT: Voici un journal de connexion du client Archlinux.

Oct  2 16:54:17 Groat ovpn-openvpn[9216]: OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Feb 13 2013
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: LZO compression initialized
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: Socket Buffers: R=[212992->131072] S=[212992->131072]
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: Local Options hash (VER=V4): '41690919'
Oct  2 16:54:17 Groat ovpn-openvpn[9216]: Expected Remote Options hash (VER=V4): '530fdded'
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: UDPv4 link local: [undef]
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: UDPv4 link remote: [AF_INET]212.83.129.104:1194
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: TLS: Initial packet from [AF_INET]212.83.129.104:1194, sid=edfcb034 3452d72c
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: VERIFY OK: depth=1, /C=FR/ST=FR/L=Paris/O=Dragonborn/CN=Dragonborn_CA/[email protected]
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: VERIFY OK: nsCertType=SERVER
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: VERIFY OK: depth=0, /C=FR/ST=FR/L=Paris/O=Dragonborn/CN=Dragonborn/[email protected]
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Oct  2 16:54:17 Groat ovpn-openvpn[9217]: [Dragonborn] Peer Connection Initiated with [AF_INET]212.83.129.104:1194
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: SENT CONTROL [Dragonborn]: 'PUSH_REQUEST' (status=1)
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.8.0.1,route 212.83.129.0 255.255.255.0,route-gateway 10.8.0.1,topology subnet,ping 5,ping-restart 60,redirect-gateway def1,ifconfig 10.8.0.3 255.255.255.0'
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: OPTIONS IMPORT: timers and/or timeouts modified
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: OPTIONS IMPORT: --ifconfig/up options modified
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: OPTIONS IMPORT: route options modified
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: OPTIONS IMPORT: route-related options modified
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: ROUTE default_gateway=192.168.1.254
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: TUN/TAP device tun0 opened
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: TUN/TAP TX queue length set to 100
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: /sbin/ifconfig tun0 10.8.0.3 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: /sbin/route add -net 212.83.129.104 netmask 255.255.255.255 gw 192.168.1.254
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.8.0.1
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.8.0.1
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: /sbin/route add -net 212.83.129.0 netmask 255.255.255.0 gw 10.8.0.1
Oct  2 16:54:20 Groat ovpn-openvpn[9217]: Initialization Sequence Completed

EDIT: Voici un tcpdump du serveur téléchargeant directement un fichier: http://sprunge.us/aaJX Voici le client téléchargeant cette ressource: http://sprunge.us/WUCC et voici un client normal d'un autre openvpn ( serveur): http://www4.slashusr.com/57552.tcpdump

EDIT: Comme demandé dans les commentaires, voici les captures brutes de tcpdump. La capture tun0 du serveur a échoué, je ne sais pas pourquoi. Serveur montrant dehors ici , client montrant tun0 ici , client montrant dehors ici et serveur téléchargeant directement le fichier ici .

EDIT: Le serveur exécute un i3, qui n'est pas utilisé à tout moment (même pas pendant l'utilisation d'Openvpn). Idem pour le client, i7 totalement inactif.

EDIT: Le problème est toujours là. S'il vous plaît, aidez :(

linux iptables routing ip openvpn Cubox
la source
Je suppose que vous avez regardé quelques captures avec Wireshark / tcpdump? La réponse se trouve presque certainement dans une capture, si vous capturez au bon endroit.
Zoredache
J'ai un tcpdump de l'interface eno1 sur un téléchargement du client et un du serveur (du même fichier). Et un d'un client openvpn qui fonctionne également. Je vais modifier la question.
Cubox
Pouvez-vous ajouter des informations sur le processeur du client et du serveur pendant le transfert du trafic?
Jed Daniels
Dans votre tcpdump, je ne vois pas de trafic lent (il pourrait être trop court). Chaque client obtient la même adresse IP 10.8.0.2? Pouvez-vous omettre cela et plutôt pousser un itinéraire vers votre réseau 212.83.129.0?
ott--
Chaque client a son propre ccd avec sa propre adresse IP. Je ne comprends pas ce que vous entendez par un itinéraire vers le réseau.
Cubox

Réponses:

1

Je ne sais pas si c'est la même cause mais je pense que cela vaut la peine d'ajuster tun-mtu et mssfix comme mentionné dans openvpn-on-android-tcp-retransmissions-after-openvpn-server-reboot

EDIT: j'ai trouvé que celui-ci pouvait aussi être utile [RÉSOLU] Performances inacceptables openVPN Modification d'un paramètre du noyau: net.inet.ip.fastforwarding = 1 (ajoutez /etc/sysctl.conf sur votre serveur Linux)

Wutiphong
la source
Merci d'avoir répondu. La modification des options tun-mtu et mssfix n'a pas aidé. Le paramètre fastworwarding n'existe pas sous Linux. Uniquement les noyaux BSD.
Cubox
0

Le serveur VPN est-il également le serveur de passerelle? essayez de supprimer la passerelle push, vos clients n'ont besoin que d'un itinéraire supplémentaire.

Alin Andrei
la source
Où voyez-vous une option de passerelle push?
Cubox
Aux options CCD, il y a une passerelle de redirection. Vous devez vérifier s'il existe une route statique sur les clients vers leur véritable GW.
MealstroM
Il y a. Les clients peuvent parler de n'importe quoi sur Internet, ils le font lentement.
Cubox
0

Votre règle iptables postrouting a l'air bizarre, essayez ceci

-A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE

au lieu du SNAT, et supprimez l'une des adresses IP sur eno1, si vous n'avez pas besoin des deux. Deux adresses IP publiques sur ce qui semble être une interface Ethernet semble tout simplement étrange. Pourquoi cette configuration?

Je suppose que votre serveur openvpn fait une boucle et laisse tomber des paquets d'avant en arrière, ce qui conduit à ce problème.

AntonioP
la source
J'ai la règle de la mascarade maintenant, cela ne résout pas le problème. J'en ai deux sur mon serveur, l'un d'eux étant le basculement et l'autre le principal. Pour avoir un serveur avec quatre ips sur l'interface eth0 (sur un autre serveur Archlinux) depuis plus d'un an, je peux vous dire que plusieurs ips ne sont pas le problème ici ...
Cubox
0

Exécutez-vous votre propre serveur DNS en interne? J'ai eu des problèmes avec mon réseau lorsque j'exécutais une configuration powerdns pour le DNS interne mais je n'avais pas de zone inversée configurée correctement. Wireshark a fourni les réponses dans ce cas.

Peter Nunn
la source