Openvpn, leitet Pakete sehr langsam weiter

10

Ich habe meinen Server neu gestartet und es ist gerade ein seltsames Problem aufgetreten. Ich laufe unter ArchLinux, die Clients sind Ubuntu, Android und Mac.

Das Problem ist, dass der Zugriff auf das Internet über die Clients langsam ist, etwa 2 kO / s und langsam stoppt.

Das direkte Herunterladen von etwas vom Server auf den Client erfolgt jedoch mit voller Geschwindigkeit. Und natürlich ist das Internet vom Server auf Hochtouren (40 Monate / s).

Ich weiß nicht, was beim Neustart passiert ist, aber dieses Problem tritt bei allen Clients auf und bezieht sich nur auf den Datenverkehr, der openvpn an das Internet weiterleitet.

EDIT: Versucht mit TCP, nicht gelöst. BEARBEITEN: Verschiedene Fragment- / MTU-Einstellungen getestet, keine Änderungen.

Hier sind alle meine 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

und einige Ausgaben, die Ihnen helfen könnten: 

╭─<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

Die iptables-Regel hier ist die einzige, die auf dem Server aktiv ist.

╰─➤ 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

BEARBEITEN: Hier ist ein Protokoll vom Archlinux-Client, der eine Verbindung herstellt.

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/emailAddress=cubox@cubox.me
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/emailAddress=cubox@cubox.me
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

BEARBEITEN: Hier ist ein tcpdump des Servers, der direkt eine Datei herunterlädt: http://sprunge.us/aaJX Hier ist der Client, der diese Ressource herunterlädt: http://sprunge.us/WUCC und hier ist ein normaler Client von einem anderen openvpn ( Arbeitsserver: http://www4.slashusr.com/57552.tcpdump

BEARBEITEN: Wie in den Kommentaren gefragt, sind hier rohe tcpdump-Erfassungen. Die tun0-Erfassung vom Server ist fehlgeschlagen, ich weiß nicht warum. Server zeigt hier draußen , Client zeigt hier tun0 , Client zeigt hier draußen und Server lädt die Datei hier direkt herunter .

BEARBEITEN: Auf dem Server wird ein i3 ausgeführt, der zu keinem Zeitpunkt verwendet wird (auch nicht während der Verwendung von openvpn). Gleiches gilt für den Client, i7 völlig im Leerlauf.

EDIT: Das Problem ist immer noch hier. Bitte helfen Sie :(

linux  iptables  routing  ip  openvpn 
— Cubox
quelle
Ich nehme an, Sie haben sich einige Aufnahmen mit Wireshark / TCPDump angesehen? Die Antwort kann mit ziemlicher Sicherheit in einer Aufnahme gefunden werden, wenn Sie an der richtigen Stelle aufnehmen.
— Zoredache
Ich habe einen tcpdump von der eno1-Schnittstelle beim Herunterladen vom Client und einen vom Server (derselben Datei). Und einer von einem funktionierenden OpenVPN-Client auch. Ich werde die Frage bearbeiten.
— Cubox
Können Sie CPU-Informationen vom Client und Server hinzufügen, während der Datenverkehr übertragen wird?
— Jed Daniels
In Ihrem tcpdump sehe ich keinen langsamen Verkehr (es könnte jedoch zu kurz sein). Jeder Client erhält die gleiche IP-Adresse 10.8.0.2? Können Sie das weglassen und lieber eine Route zu Ihrem Netzwerk 212.83.129.0 verschieben?
— ott--
Jeder Kunde hat seine eigene CD mit seiner eigenen IP-Adresse. Ich verstehe nicht, was Sie unter einer Route zum Netzwerk verstehen.
— Cubox

Antworten:

1

Ich bin nicht sicher, ob es die gleiche Ursache ist, aber ich denke, es lohnt sich, über tun-mtu und mssfix anzupassen, wie in openvpn-on-android-tcp-retransmissions-after-openvpn-server-reboot erwähnt

BEARBEITEN: Ich fand, dass dies auch hilfreich sein könnte. [BEHOBEN] Inakzeptable openVPN-Leistung Ändern eines Kernel-Parameters: net.inet.ip.fastforwarding = 1 (fügen Sie /etc/sysctl.conf auf Ihrem Linux-Server hinzu)

— Wutiphong
quelle
Danke für die Antwort. Das Ändern der Optionen tun-mtu und mssfix hat nicht geholfen. Die Fastworwarding-Einstellung ist unter Linux nicht vorhanden. Nur BSD-Kernel.
— Cubox
0

Ist der VPN-Server auch der Gateway-Server? Versuchen Sie, das Push-Gateway zu entfernen. Ihre Clients benötigen nur eine zusätzliche Route.

— Alin Andrei
quelle
Wo sehen Sie eine Push-Gateway-Option?
— Cubox
Bei CCD-Optionen gibt es ein Redirect-Gateway. Sie müssen überprüfen, ob es eine statische Route zwischen Clients und ihrem tatsächlichen GW gibt.
— Mahlzeit
Es gibt. Kunden können mit allem im Internet sprechen, sie tun es nur langsam.
— Cubox
0

Ihre Postrouting-Iptables-Regel sieht seltsam aus. Versuchen Sie dies

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

anstelle der SNAT und löschen Sie eine der IPs auf eno1, wenn Sie nicht beide benötigen. Zwei öffentliche IP-Adressen auf einer Ethernet-Schnittstelle sehen einfach komisch aus. Warum dieses Setup?

Ich vermute, Ihr openvpn-Server schleift und verwirft Pakete hin und her, was zu diesem Problem führt.

— AntonioP
quelle
Ich habe jetzt die Maskerade-Regel, sie hat das Problem nicht gelöst. Ich habe zwei auf meinem Server, von denen einer das Failover und der andere der Haupt ist. Wenn Sie über ein Jahr lang einen Server mit vier IPs auf der eth0-Schnittstelle (auf einem anderen Archlinux-Server) haben, kann ich Ihnen sagen, dass hier mehrere IPs nicht das Problem sind ...
— Cubox
0

Führen Sie Ihren eigenen DNS-Server intern aus? Ich hatte Probleme mit meinem Netzwerk, als ich ein PowerDNS-Setup für interne DNS ausführte, aber keine Reverse Zone richtig konfiguriert hatte. Wireshark lieferte in diesem Fall die Antworten.

— Peter Nunn
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.