Openvpn,非常缓慢地转发数据包

我重启了我的服务器,一个奇怪的问题刚刚出来。 我在ArchLinux上运行,客户端是Ubuntu,Android和Mac。

问题是,通过客户端访问互联网是慢,约2ko / s,并缓慢停止。

但是直接从服务器上下载东西到客户端是全速的。 而且,显然,服务器的互联网正在全速(40mo / s)。

我不知道重启后发生了什么事,但是这个问题在所有的客户端都有,只和openvpn转发到互联网的stream量有关。

编辑:尝试与TCP,没有解决。 编辑:testing各种片段/ MTU设置,没有变化。

这里是我所有的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" 

客户端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 

和一些输出可能会帮助你:

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

这里的iptables规则是唯一在服务器上处于活动状态的规则。

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

编辑:这是从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 

编辑:这是一个tcpdump的服务器直接下载一个文件: http : //sprunge.us/aaJX这里是客户端下载这个资源: http ://sprunge.us/WUCC这里是一个普通的客户端从另一个openvpn工作)服务器: http : //www4.slashusr.com/57552.tcpdump

编辑:如注释中所述,这里是原始的tcpdump捕获。 从服务器tun0捕获失败,我不知道为什么。 服务器在这里显示 , 客户端显示tun0在这里 , 客户端显示在这里 , 服务器直接在这里下载文件 。

编辑:服务器运行一个i3,这是不是在任何时候(即使在openvpn使用)没有使用)。 同样的客户端,i7总共闲置。

编辑:问题仍然在这里。 请帮忙 :(

我不知道,如果这是同样的原因,但我认为这是值得调整的tun-mtu和mssfix中提到openvpn-on-android-tcp-retransmissions-after-openvpn-server-reboot

编辑:我发现这也许是有帮助的[已解决]不可接受的openVPN性能更改内核参数:net.inet.ip.fastforwarding = 1(在您的Linux服务器上添加/etc/sysctl.conf)

vpn服务器也是网关服务器吗? 尝试删除推送网关,你的客户只需要一个额外的路线。

你的布告iptables规则看起来很奇怪,试试这个

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

而不是SNAT,并删除eno1上的一个IP,如果你不需要它们两个。 看起来是一个以太网接口的两个公共IP地址看起来很奇怪。 为什么设置?

我的猜测是你的openvpn服务器正在循环和丢弃数据包来回导致这个问题。

你在内部运行你自己的DNS服务器吗? 我在运行内部dns的powerdns设置时遇到了networking问题,但没有正确configuration反向区域。 Wireshark在这种情况下提供了答案。