Openvpn, przekazywanie pakietów bardzo powoli

10

Uruchomiłem ponownie serwer i właśnie pojawił się dziwny problem. Pracuję na ArchLinux, klientami są Ubuntu, Android i Mac.

Problem polega na tym, że dostęp do Internetu przez klientów jest powolny, około 2ko / si powoli się zatrzymuje.

Ale pobieranie czegoś z serwera bezpośrednio do klienta odbywa się z pełną prędkością. I oczywiście internet z serwera jest na pełnej prędkości (40mo / s).

Nie wiem, co się stało po ponownym uruchomieniu komputera, ale ten problem występuje tutaj na wszystkich klientach i jest związany tylko z ruchem, który openvpn przekazuje do Internetu.

EDYCJA: Próbowałem z tcp, nie rozwiązałem. EDYCJA: Testowano różne ustawienia fragmentu / mtu, bez zmian.

Oto wszystkie moje 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"

Konf. Klienta:

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

i niektóre dane wyjściowe, które mogą ci pomóc: 

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

Tutaj reguła iptables jest jedyną aktywną na serwerze.

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

EDYCJA: Oto log z łączącego się klienta 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

EDYCJA: Oto zrzut serwera pobierania bezpośrednio pliku: http://sprunge.us/aaJX Oto klient pobierający to źródło: http://sprunge.us/WUCC, a tutaj jest normalny klient z innego openvpn ( działający) serwer: http://www4.slashusr.com/57552.tcpdump

EDYCJA: Jak pytano w komentarzach, oto surowe zrzuty tcpdump. Przechwytywanie tun0 z serwera nie powiodło się, nie wiem dlaczego. Serwer pokazuje tutaj tutaj , klient pokazuje tun0 tutaj , klient pokazuje tutaj tutaj i serwer pobiera bezpośrednio plik tutaj .

EDYCJA: Na serwerze działa i3, który nie jest używany w żadnym momencie (nawet podczas korzystania z openvpn). To samo dla klienta, i7 całkowicie bezczynny.

EDYCJA: Problem jest nadal obecny. Proszę pomóż :(

linux  iptables  routing  ip  openvpn 
— Cubox
źródło
Zakładam, że przeglądałeś niektóre zrzuty za pomocą wireshark / tcpdump? Odpowiedź prawie na pewno można znaleźć w ujęciu, jeśli ujęłeś we właściwym miejscu.
— Zoredache
Mam tcpdump z interfejsu eno1 do pobrania z klienta i jeden z serwera (tego samego pliku). I jeden z działającego klienta openvpn. Zmienię pytanie.
— Cubox
Czy możesz dodać informacje o procesorze od klienta i serwera podczas przesyłania ruchu?
— Jed Daniels
W twoim tcpdump nie widzę powolnego ruchu (może być za krótki). Każdy klient otrzymuje ten sam adres IP 10.8.0.2? Czy możesz to pominąć, a raczej wcisnąć trasę do sieci 212.83.129.0?
— ott--
Każdy klient ma swój własny komputer z własnym adresem IP. Nie rozumiem, co masz na myśli mówiąc o trasie do sieci.
— Cubox

Odpowiedzi:

1

Nie jestem pewien, czy to ta sama przyczyna, ale myślę, że warto dostosować się do tun-mtu i mssfix, jak wspomniano w openvpn-on-android-tcp-retransmissions-after-openvpn-server-reboot

EDYCJA: Odkryłem, że ten też może być pomocny [ROZWIĄZANE] Niedopuszczalna wydajność openVPN Zmiana parametru jądra: net.inet.ip.fastforwarding = 1 (dodaj /etc/sysctl.conf na serwerze linux)

— Wutiphong
źródło
Dziękuję za odpowiedź. Zmiana opcji tun-mtu i mssfix nie pomogła. Ustawienie szybkiego tworzenia nie istnieje w systemie Linux. Tylko jądra BSD.
— Cubox
0

Czy serwer VPN jest również serwerem bramy? spróbuj usunąć bramę push, klienci muszą mieć tylko dodatkową trasę.

— Alin Andrei
źródło
Gdzie widzisz opcję push-gateway?
— Cubox
W opcjach CCD jest brama przekierowania. Musisz sprawdzić, czy klienci mają statyczną trasę do ich rzeczywistej GW.
— MealstroM
Jest. Klienci mogą rozmawiać z dowolnymi elementami Internetu, po prostu robią to powoli.
— Cubox,
0

Twoja reguła iptables z trasowaniem wygląda dziwnie, spróbuj tego

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

zamiast SNAT i usuń jeden z adresów IP na eno1, jeśli nie potrzebujesz ich obu. Dwa publiczne adresy IP na czymś, co wygląda na interfejs Ethernet, wygląda dziwnie. Dlaczego taka konfiguracja?

Domyślam się, że twój serwer openvpn zapętla się i upuszcza pakiety tam iz powrotem, co prowadzi do tego problemu.

— AntonioP
źródło
Mam teraz regułę maskarady, która nie rozwiązała problemu. Mam dwa na moim serwerze, jeden z nich to tryb failover, a drugi główny. Za posiadanie serwera z czterema IP w interfejsie eth0 (na innym serwerze Archlinux) przez ponad rok, mogę powiedzieć, że wielokrotność IP nie jest tutaj problemem ...
— Cubox
0

Czy prowadzisz wewnętrzny serwer DNS? Miałem problemy z siecią, kiedy działałem z konfiguracją powerdns dla wewnętrznych dns, ale nie miałem poprawnie skonfigurowanej strefy odwrotnej. Wireshark udzielił odpowiedzi w tym przypadku.

— Peter Nunn
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.