Openvpn, переслати пакети дуже повільно

10

Я перезавантажив свій сервер, і вийшла незвичайна проблема. Я працюю на ArchLinux, клієнтами є Ubuntu, Android та Mac.

Проблема полягає в тому, що доступ до Інтернету через клієнтів повільний, близько 2 к / с і повільно зупиняється.

Але завантаження чогось із сервера до клієнта безпосередньо здійснюється на повній швидкості. І, очевидно, Інтернет з сервера працює на повній швидкості (40моль / с).

Я не знаю, що сталося з перезавантаженням, але ця проблема тут є у всіх клієнтів і пов'язана лише з трафіком, який openvpn спрямовує до Інтернету.

EDIT: Пробували з tcp, не вирішили. РЕДАКТУВАННЯ: Випробувано різні параметри фрагмента / mtu, без змін.

Ось усі мої конфс:

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

EDIT: Ось журнал підключення клієнта 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/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

EDIT: Ось tcpdump сервера, який завантажує файл безпосередньо: http://sprunge.us/aaJX Ось клієнт, що завантажує цей ресурс: http://sprunge.us/WUCC, і ось звичайний клієнт з іншого openvpn ( робочий) сервер: http://www4.slashusr.com/57552.tcpdump

РЕДАКТУВАННЯ: Як запитують у коментарях, тут є необроблені захоплення tcpdump. Не вдалося захопити tun0 з сервера, я не знаю чому. Сервер, який відображається тут , клієнт, який показує tun0 тут , клієнт, який показує тут, і сервер, завантажуючи файл безпосередньо тут .

EDIT: Сервер працює i3, який не використовується в будь-який час (навіть під час використання openvpn). Те саме для клієнта, i7 повністю простоює.

EDIT: Проблема все ще є тут. Будь ласка, допоможіть :(

linux  iptables  routing  ip  openvpn 
— Cubox
джерело
Я припускаю, що ви подивилися на деякі захоплення за допомогою wireshark / tcpdump? Відповідь майже напевно можна знайти у захопленні, якщо ви захопите у потрібному місці.
— Зоредаче
У мене є tcpdump з інтерфейсу eno1 при завантаженні з клієнта та один із сервера (того ж файлу). І один із робочого openvpn клієнта теж. Я відредагую питання.
— Cubox
Чи можете ви додавати інформацію про процесор від клієнта та сервера під час передачі трафіку?
— Джед Даніельс
У вашому tcpdump я не бачу повільного руху (це може бути занадто коротко). Кожен клієнт отримує однакову ip-адресу 10.8.0.2? Чи можете ви пропустити це і скоріше просунути маршрут до своєї мережі 212.83.129.0?
— ott--
У кожного клієнта є власний ccd із власною ip-адресою. Я не розумію, що ви маєте на увазі під маршрутом до мережі.
— Cubox

Відповіді:

1

Я не впевнений, що це та сама причина, але я вважаю, що варто налаштовуватися на налаштування tun-mtu та mssfix, як згадується у openvpn-on-android-tcp-retransmissions-after-openvpn-server-reboot.

EDIT: Я виявив, що і цей може бути корисним [RESOLVED] Неприйнятна продуктивність openVPN Зміна параметра ядра: net.inet.ip.fastforwarding = 1 (додати в /etc/sysctl.conf на вашому сервері Linux)

— об
джерело
Дякую за відповідь. Зміна параметра tun-mtu та mssfix не допомогла. Настройка швидкого розвитку не існує в Linux. Тільки ядра BSD.
— Cubox
0

Сервер vpn також є сервером шлюзу? спробуйте видалити шлюз push-шлюзу, клієнтам потрібно мати лише додатковий маршрут.

— Алін Андрій
джерело
Де ви бачите варіант push-gateway?
— Cubox
У параметрах CCD є шлюз для переадресації. Вам потрібно перевірити, чи є статичний маршрут клієнтів до їх реального GW.
— MealstroM
Існує. Клієнти можуть поговорити з чим завгодно в Інтернеті, вони просто роблять це повільно.
— Cubox
0

Ваше правило про встановлення iptables виглядає дивно, спробуйте це

-A РОЗМІСТАННЯ -s 10.8.0.0/24 -o eno1 -j MASQUERADE

замість SNAT та видаліть один із IP-адрес на eno1, якщо вони вам обох не потрібні. Дві загальнодоступні IP-адреси щодо інтерфейсу Ethernet виглядають просто дивно. Чому така установка?

Моя здогадка, ваш сервер openvpn циклічно і скидає пакети туди-сюди, що призводить до цієї проблеми.

— AntonioP
джерело
У мене зараз правило маскараду, це не вирішило питання. У мене два є на моєму сервері, один з них є аварійним, а другий основним. Якщо у вас є сервер з чотирма ips на інтерфейсі eth0 (на іншому сервері Archlinux) більше року, я можу вам сказати, що тут не проблема в декількох ips ...
— Cubox
0

Ви запускаєте власний dns-сервер внутрішньо? У мене були проблеми з моєю мережею, коли я запускав налаштування powerdns для внутрішніх dns, але не мав коректної зони зворотного налаштування. У цьому випадку Wireshark дав відповіді.

— Пітер Нанн
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.