Niska wydajność OpenVPN. Czy mam problemy z MTU? Zrzuca do środka

Mam problemy z tunelem OpenVPN, który nie osiąga prędkości linii. Bramą jest wirtualny serwer Debian Jessy hostowany w OVH. Klientem jest mój serwer domowy freebsd 10.2 (Intel I3 Ivy Bridge) lub mój RaspberryPI2. Dezaktywowałem szyfrowanie i uwierzytelnianie. Mam symetryczne połączenie FTTH 100 Mb / s, ale tunel osiąga prędkość tylko 20–40 Mb / s. Bezpośrednie połączenie (bez tunelu) zawsze zapewnia oczekiwane 100 Mb / s. Testowałem wydajność z iperf3. Najpierw spróbowałem z moim freebsd homeserver. Próbowałem wszystkich zalecanych ustawień dotyczących mssfix, fragmentu itp. Nic nie pomogło.

Pomyślałem wtedy, że może to moja maszyna FreeBSD. Więc zainstalowałem świeżą, malinową Jessy na moim RPI2 i wykonałem kilka szczegółowych testów:

Przede wszystkim usunąłem wszystkie ustawienia MTU z konfiguracji OpenVPN i pozwoliłem ścieżce MTU obsługiwać różne rzeczy (mam nadzieję). Ponieważ nie mam aktywnej zapory ogniowej na obu komputerach, powinna działać. Oto moje konfiguracje VPN:

server 10.8.0.0 255.255.255.0
port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0

user nobody
group nogroup
persist-key
persist-tun
ifconfig-pool-persist ipp.txt
keepalive 10 120
push "redirect-gateway def1"
status openvpn-status.log
verb 3

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/vpn.theissen.io.crt
key /etc/openvpn/easy-rsa/keys/vpn.theissen.io.key
dh /etc/openvpn/easy-rsa/keys/dh4096.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher none
auth none
comp-lzo no



client
proto udp
dev tun12
remote xxx.io 1194
resolv-retry infinite
sndbuf 0
rcvbuf 0

nobind
user nobody
group nogroup
persist-key
persist-tun
verb 3

pkcs12 /etc/openvpn/vpn.theissen.io/alex.p12
tls-auth /etc/openvpn/vpn.theissen.io/ta.key 1
ns-cert-type server
cipher none
auth none
comp-lzo no

Przede wszystkim test bez tunelu, aby wykazać, że połączenie z serwerem rzeczywiście ma prawie 100 Mb / s:

iperf3 -c vpn.theissen.io
Connecting to host vpn.theissen.io, port 5201
[  4] local 192.168.1.253 port 34512 connected to 149.202.58.183 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  10.8 MBytes  90.5 Mbits/sec    0    335 KBytes       
[  4]   1.00-2.00   sec  11.4 MBytes  95.7 Mbits/sec    0    335 KBytes       
[  4]   2.00-3.00   sec  11.1 MBytes  93.0 Mbits/sec    0    352 KBytes       
[  4]   3.00-4.00   sec  11.2 MBytes  94.0 Mbits/sec    0    369 KBytes       
[  4]   4.00-5.00   sec  11.5 MBytes  95.9 Mbits/sec    0    390 KBytes       
[  4]   5.00-6.00   sec  11.0 MBytes  92.5 Mbits/sec    0    390 KBytes       
[  4]   6.00-7.00   sec  11.4 MBytes  95.2 Mbits/sec    0    390 KBytes       
[  4]   7.00-8.00   sec  11.2 MBytes  94.3 Mbits/sec    0    390 KBytes       
[  4]   8.00-9.00   sec  11.1 MBytes  93.3 Mbits/sec    0    390 KBytes       
[  4]   9.00-10.00  sec  11.3 MBytes  95.1 Mbits/sec    0    390 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   112 MBytes  93.9 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   112 MBytes  93.5 Mbits/sec                  receiver

iperf Done.

Pakiety tego połączenia zrzuciłem z tcpdump na serwerze. Możesz je pobrać tutaj (musisz rozpakować, aby je otworzyć za pomocą wireshark): dumpraw.cap.xz

Tak właśnie wygląda zrzut „OK”. Maksymalny zauważony przeze mnie rozmiar ramki to 1514.

Teraz przeprowadziłem test nad tunelem:

iperf3 -c 10.8.0.1
Connecting to host 10.8.0.1, port 5201
[  4] local 10.8.0.14 port 36388 connected to 10.8.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  5.96 MBytes  50.0 Mbits/sec  127    133 KBytes       
[  4]   1.00-2.00   sec  5.19 MBytes  43.5 Mbits/sec    6    120 KBytes       
[  4]   2.00-3.00   sec  5.80 MBytes  48.7 Mbits/sec    0    151 KBytes       
[  4]   3.00-4.00   sec  4.27 MBytes  35.9 Mbits/sec   23   96.5 KBytes       
[  4]   4.00-5.00   sec  4.89 MBytes  41.0 Mbits/sec    0    129 KBytes       
[  4]   5.00-6.00   sec  6.11 MBytes  51.2 Mbits/sec   26    111 KBytes       
[  4]   6.00-7.00   sec  5.50 MBytes  46.1 Mbits/sec    0    143 KBytes       
[  4]   7.00-8.00   sec  5.25 MBytes  44.1 Mbits/sec   15    126 KBytes       
[  4]   8.00-9.00   sec  5.80 MBytes  48.7 Mbits/sec    0    158 KBytes       
[  4]   9.00-10.00  sec  3.97 MBytes  33.3 Mbits/sec   22    105 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  52.7 MBytes  44.2 Mbits/sec  219             sender
[  4]   0.00-10.00  sec  52.3 MBytes  43.8 Mbits/sec                  receiver

iperf Done.

Ups Już nie taki miły. Zwłaszcza ta kolumna „Retr” nie wygląda tak dobrze. Zakładałem, że to retransmisja tcp i powinno być coś na zrzucie. Zobaczymy, że tak nie jest:. Procesor nie jest tutaj wąskim gardłem, ponieważ dezaktywowałem szyfrowanie i uwierzytelnianie. Procesor ma 20% na serwerze i 50% na PI podczas testu.

Tak wygląda ruch OpenVPN testu:

Dla mnie to wygląda dobrze. Ale nie wiem, czego szukać. Proszę spojrzeć na zrzut z wireshark: dump_physical.cap.xz

Również ruch na interfejsie tunelu wygląda dobrze. Wygląda na to, że poprawnie obniżył rozmiar ramki (jak się wydaje do 1444):

Oto zrzut: dump_tunnel.cap.xz

Dla mnie wszystko wygląda dobrze, ale tak naprawdę nie mam pojęcia, czego dokładnie szukać. Naprawdę wszystko przetestowałem z ustawieniami OpenVPN. Może ktoś może mi powiedzieć, czy ruch wygląda dobrze.

Czego oczekuję jako odpowiedzi

Przynajmniej wyjaśnienie, co się tutaj dzieje i dlaczego wydaje się być niezależne od oprogramowania VPN, którego używam. Wszystko, co znalazłem w Internecie, dotyczyło problemów z MTU, ale to powinno być łatwo naprawione przez zmniejszenie MTU tunelu lub innych parametrów OpenVPN. Dla mnie to niewiele się zmienia. Gdy spojrzysz na zrzut, zobaczysz, że zmniejsza on rozmiar segmentu TCP i pakiety nie są pofragmentowane. Musi być coś jeszcze. Naprawdę lubię wiedzieć co .

Aktualizacja

Testowałem to z strongswan, a nawet z softetherem. To właściwie ten sam problem (porównywalna prędkość, brak wąskiego gardła procesora). Jestem naprawdę zaskoczony, w czym tkwi problem. Próbowałem także innej bramy (RaspberryPi2 na połączenie domowe znajomych 100/100).

Aktualizacja 2

Zauważyłem, że iperf3 zgłasza retransmisje TCP (retr), ale nie ma retransmisji w zrzucie (Wireshark powinien je podświetlić). Co się dzieje?

Próbowałem nawet OpenVPN w mojej sieci lokalnej (RaspberryPi2 do FreebsdServer). Nawet tam mam dużo retransmisji (w sieci LAN ?!):

Connecting to host 192.168.222.11, port 5201
[  4] local 192.168.222.10 port 46196 connected to 192.168.222.11 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  9.19 MBytes  77.0 Mbits/sec    8    141 KBytes       
[  4]   1.00-2.00   sec  8.71 MBytes  73.1 Mbits/sec    3    130 KBytes       
[  4]   2.00-3.00   sec  8.59 MBytes  72.0 Mbits/sec    3    120 KBytes       
[  4]   3.00-4.00   sec  8.65 MBytes  72.5 Mbits/sec    4    108 KBytes       
[  4]   4.00-5.00   sec  8.65 MBytes  72.5 Mbits/sec    4   95.6 KBytes       
[  4]   5.00-6.00   sec  8.52 MBytes  71.5 Mbits/sec    2   80.5 KBytes       
[  4]   6.00-7.00   sec  8.83 MBytes  74.1 Mbits/sec    0    141 KBytes       
[  4]   7.00-8.00   sec  8.59 MBytes  72.0 Mbits/sec    7    106 KBytes       
[  4]   8.00-9.00   sec  8.71 MBytes  73.1 Mbits/sec    3   94.2 KBytes       
[  4]   9.00-10.00  sec  8.59 MBytes  72.0 Mbits/sec    3   79.2 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  87.0 MBytes  73.0 Mbits/sec   37             sender
[  4]   0.00-10.00  sec  86.8 MBytes  72.8 Mbits/sec                  receiver

W trybie odwrotnym mam naprawdę dziwne okno przeciążenia (wtf?):

Accepted connection from 192.168.222.10, port 46197
[  5] local 192.168.222.11 port 5201 connected to 192.168.222.10 port 46198
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  5]   0.00-1.00   sec  8.90 MBytes  74.7 Mbits/sec    3   1.48 GBytes       
[  5]   1.00-2.00   sec  8.45 MBytes  70.9 Mbits/sec    2   1.59 GBytes       
[  5]   2.00-3.00   sec  8.66 MBytes  72.7 Mbits/sec  518    214 MBytes       
[  5]   3.00-4.00   sec  7.96 MBytes  66.8 Mbits/sec   37    703 MBytes       
[  5]   4.00-5.00   sec  8.09 MBytes  67.9 Mbits/sec    0    719 MBytes       
[  5]   5.00-6.00   sec  8.04 MBytes  67.5 Mbits/sec    0    734 MBytes       
[  5]   6.00-7.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   7.00-8.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   8.00-9.00   sec  7.99 MBytes  67.1 Mbits/sec    2    693 MBytes       
[  5]   9.00-10.00  sec  8.06 MBytes  67.6 Mbits/sec    1    693 MBytes       
[  5]  10.00-10.09  sec   684 KBytes  64.5 Mbits/sec    0    695 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.09  sec  83.0 MBytes  69.0 Mbits/sec  565             sender
[  5]   0.00-10.09  sec  0.00 Bytes  0.00 bits/sec                  receiver

Aktualizacja 3

Używanie iperf z udp powoduje tymczasowe zablokowanie tego portu przez ovh (wysyłają mi wiadomość e-mail z informacją o ataku) i ogromną utratę pakietów:

-----------------------------------------------------------
Server listening on 1194
-----------------------------------------------------------
Accepted connection from 185.22.143.160, port 15906
[  5] local 149.202.58.183 port 1194 connected to 185.22.143.160 port 4355
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  2.89 MBytes  24.2 Mbits/sec  0.727 ms  1017/1387 (73%)  
iperf3: OUT OF ORDER - incoming packet = 1409 and received packet = 1470 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1410 and received packet = 1471 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1411 and received packet = 1472 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1445 and received packet = 1473 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1463 and received packet = 1473 AND SP = 5
[  5]   1.00-2.00   sec  3.29 MBytes  27.6 Mbits/sec  0.716 ms  1110/1526 (73%)  
[  5]   2.00-3.00   sec  3.30 MBytes  27.7 Mbits/sec  0.732 ms  1103/1526 (72%)  
[  5]   3.00-4.00   sec  3.27 MBytes  27.4 Mbits/sec  0.717 ms  1108/1526 (73%)  
[  5]   4.00-5.00   sec  1.56 MBytes  13.1 Mbits/sec  0.837 ms  546/746 (73%)  
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]  10.00-10.06  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.06  sec   118 MBytes  98.5 Mbits/sec  0.837 ms  4884/6711 (73%)  
[SUM]  0.0-10.1 sec  4884 datagrams received out-of-order

— Alexander Theißen
źródło

Jeśli jeszcze tego nie zrobiłeś, możesz spróbować: tun-mtu 9000 fragment 0 mssfix 0(opcje muszą być dodane w trzech różnych wierszach)

— Diamant

Już to testuję. Ale przetestowałem ponownie. Stało się tak, że zaczyna się z tą samą prędkością, ale potem połączenia się zatrzymują. A tak przy okazji, zawsze dzieje się to, kiedy wyłączam fragmentację pakietów OpenVPN. Ten przewodnik community.openvpn.net/openvpn/wiki/Gigabit_Networks każe ci myśleć, że system operacyjny powinien sobie z tym poradzić, ale oczywiście nie.

— Alexander Theißen

Och wow. Widzę dokładnie to samo zachowanie w moich sieciach VPN i mam potężny sprzęt na obu końcach i wolniejsze połączenie internetowe. Zamierzam zbadać dalej; jeśli znajdę coś konkretnego, opublikuję tutaj.

— Harald

Po przełączeniu testu na UDP (iperf3 -u -b 25m) uzyskuję pełną prędkość zarówno w tunelu openvpn, jak i poza nim. Potwierdziłem, że nie ma fragmentacji podczas korzystania z TCP - openvpn poprawnie zgłasza mały MSS, moje pakiety tcp wewnątrz tunelu mają 1354 bajty, a pakiety UDP przychodzą bez fragmentacji. Widzę to samo zjawisko co ty - wartości CWND w tunelu są o połowę mniejsze niż na zewnątrz tunelu, a przepustowość również o połowę, ale nie potrafię wyjaśnić, dlaczego . Fascynujący.

— Harald

Ok, przepraszam za stworzenie fałszywej nadziei. Próbując wyeliminować całą masę zmiennych, skonfigurowałem OpenVPN z tymi samymi parametrami konfiguracyjnymi, działającymi w mojej lokalnej sieci LAN. Poza tunelem 750 Mb / s. Wewnątrz tunelu 117 Mb / s. Ale - openvpn zużywał 100% jednego rdzenia procesora w obu punktach końcowych. Następnie przeniosłem domowy punkt końcowy mojego tunelu internetowego na „prawdziwy” serwer i zobaczyłem oczekiwane 25 Mb / s przez mój tunel. OpenVPN na obu punktach końcowych zużywał około 20% procesora. Krótko mówiąc - w moim przypadku problemem jest to, że mój punkt końcowy tunelu od strony domowej jest związany z procesorem. Przepraszam!

— Harald

Na początek twój „normalny” iperf zewnętrzny tunel powinien być UDP / 1194 jako przepływ, na którym masz problem, a nie TCP / 5201. Spróbuj najpierw z -b 100M, ale pamiętaj, że spowoduje to wygenerowanie datagramów o maksymalnym rozmiarze, który nie jest reprezentatywny dla twojego ruchu VPN (rozmiar datagramu powinien być nieco losowy). Dostrój z opcją -l dla rozmiaru datagramu i sprawdź wyniki. Jeśli wyniki nie są dobre (powiedziałbym, że> 15 lub 20% strat), możesz podejrzewać przeciążony router internetowy, który upuszcza twoje (prawdopodobnie oznaczone jako najlepszy wysiłek) pakiety.

Interesujące może być również sprawdzenie, jaką wydajność uzyskasz, jeśli przełączysz tunel VPN na port UDP klasy EF (powiedziałbym, że 5061 z powodu RTP, ale nie jestem pewien, czy wszystkie routery internetowe mają poprawnie skonfigurowaną QoS) lub Port TCP.

Dla mnie nie ma nic złego w twojej konfiguracji, a twoja diagnostyka nie pokazuje nic dziwnego. Wypróbuj też inną wersję OpenVPN lub innego oprogramowania VPN.

— 30gd4n
źródło

Zrobił to. Spójrz na aktualizację 3. Oczekiwanie na odblokowanie portu przez ovh w celu przeprowadzenia dalszych testów.

— Alexander Theißen

Niestety, nie widziałem tej ostatniej aktualizacji. Czekając na OVH, spróbuj zamontować VPN przez TCP; jakie są wyniki? Także o twojej drugiej edycji i retransmisji z * BSD na PI; czy grałeś z buforami serwera iperf? Domyślnie jest to 8kb, nie wiem jak stos jest tworzony na ARM i Linuksie, ale myślę, że zwiększenie go może pomóc.

— 30gd4n

Miałem na myśli, że dodałem go po tym, jak mi kazałeś :). Wyniki powyżej tcp są gorsze. Tcp 443 nie robi różnicy. Zabawne jest to, że kiedy używam tego github.com/sivel/speedtest-cli do testowania, raportuje 95 m w dół i 75 m w górę. Ufam iperf bardziej, ale tak naprawdę to zależy od rodzaju ruchu, więc wydaje się. Pobieranie gier lub poprawek przez tunel trwa dłużej. W domu zrobię tunel bezpośrednio między dwoma Rbps, które są w różnych lokalizacjach, ale używają tego samego ISP. Zrobiłem to wcześniej, a wyniki były prawie takie same. Ale próbuję zrobić dalsze testy.

— Alexander Theißen,