Назад | Перейти на главную страницу

Огромное снижение производительности в канале gbit с переадресацией / маскарадом IP через чистый туннель VPN

У меня проблема с переадресацией IP между моим домашним компьютером и удаленным сервером (из online.net). Мое домашнее соединение - это FTTH 1 Гбит / с, а у удаленного сервера пропускная способность 2,5 Гбит / с.

Контекст

Я управляю Чисто OpenVPN-туннель между моим домашним компьютером и удаленным сервером в online.net. На данный момент я не использую шифрование, поэтому я не сталкиваюсь с потерей производительности из-за шифрования.

Серверная машина: Intel Atom C2750 / 2 ГБ ОЗУ / SSD
Клиентская машина: VMware размещала сервер Ubuntu 16.04 64 бит с 8 ГБ ОЗУ / SSD / Intel i5 (Mac mini 2013 позади)

сервер команда openvpn:

 # openvpn --dev tun --proto tcp-server --port 11000 --ifconfig 10.200.0.1 10.200.0.2 --cipher none --auth none --fragment 0 --mssfix 0 --tun-mtu 48000 --sndbuf 0 --rcvbuf 0

клиент команда openvpn:

 # openvpn --dev tun --proto tcp-client --port 11000 --ifconfig 10.200.0.2 10.200.0.1 --cipher none --auth none --remote dedibox --fragment 0 --mssfix 0 --tun-mtu 48000 --sndbuf 0 --rcvbuf 0

Я установил сервер vsftpd на удаленном сервере. Если я загружаю что-то с удаленного FTP-сервера через туннель OpenVPN, я на полной скорости.

lftp aixki@10.200.0.1:~> pget 1GB.dat
1073741824 bytes transferred in 11 seconds (95.68 MiB/s)

Эта проблема

Проблема в том, что я хочу получить доступ к Интернету от клиента через туннель OpenVPN.

Давайте добавим маршрут на клиентском компьютере для определенного веб-сайта, с которого я проверяю свою скорость загрузки с помощью wget / curl.

ip route add 62.34.91.0/24 via 10.200.0.1

Затем разрешите пересылку ipv4 на удаленном сервере:

> # sysctl -w net.ipv4.ip_forward=1

И, наконец, разрешите VPN-подключения к Интернету и обратно:

iptables -t nat -A POSTROUTING -s 10.200.0.0/24 -o eth0 -j MASQUERADE

И когда я тестирую свою скорость загрузки с клиента:

wget -O /dev/null http://3-ipv4.testdebit.info/fichiers/1000Mo.dat
...
2016-05-17 20:24:45 (17.7 MB/s) - ‘/dev/null’ saved [1000000000/1000000000]

Это почти в 5 раз меньше, чем при загрузке файла с удаленного сервера через VPN-туннель.

Что может быть причиной ?

Ссылка с удаленного сервера на сайт 3-ipv4.testdebit.info медленная? Нет, это не так, используя тот же wget напрямую с удаленного сервера, и я получаю 225 МБ / с
Удаленный сервер не может обрабатывать получение и отправку одного и того же количества данных одновременно со скоростью 1 Гбит / с? Да, оно может. Я сделал FTP-передачу файла с сервера и загрузил его на удаленный сервер с помощью wget, у меня было 100+ МБ / с при обеих передачах.
Накладные расходы процессора? Согласно top, я использую 15% мощности процессора, поэтому не думаю, что это связано с процессором.
iptables маскирует все пакеты? Думаю, да, но не уверен. Может кто-нибудь подтвердить / опровергнуть?

Любая помощь приветствуется, от нее уже два дня болит голова! Если вам нужны логи или дамп TCP, я могу вам их предоставить.

Редактировать 2016/05/22 в 14:09 GMT

Я сбросил TCP-пакеты с помощью tcpdump на сервере. Все дампы доступны здесь: http://163.172.210.224/dumps/

Вот подробности о каждом файле:

dump-server-direct-eth0.pcap Дамп eth0 прямой http-загрузки с сервера. Здесь не используются ни VPN, ни IP-переадресация. Используемая команда (я отфильтровываю свой IP-адрес, используемый для ssh-соединения): tcpdump -i eth0 '((not net XXX.XXX.XXX.XXX) and port 80)' -C 100 -vvv -w dump-server-direct-eth0.pcap
dump-server-forward-http-[tcp|udp]-eth0.pcap Дамп eth0, когда клиент загружает http-файл через туннель UDP / TCP OpenVPN, используя пересылку IP. Используемая команда (я отфильтровываю свой IP-адрес, используемый для ssh-соединения):
tcpdump -i eth0 '((not net XXX.XXX.XXX.XXX) and (port 80 or port 11000))' -C 100 -vvv -w dump-server-forward-http-[tcp|udp]-eth0.pcap
dump-server-forward-http-[tcp|udp]-tun0.pcap То же, что и выше, но на этот раз захват из интерфейса tun0. Используемая команда:
tcpdump -i tun0 -C 100 -vvv -w dump-server-forward-http-[tcp|udp]-tun0.pcap
dump-server-http-through-tcp-tunnel-eth0.pcap Дамп eth0, когда клиент загружает ftp файл через туннель UDP / TCP OpenVPN, без Переадресация IP. HTTP-сервер размещен на самом сервере OpenVPN, и я использую адрес сервера OpenVPN для подключения к серверу (10.200.0.1), поэтому переадресация IP отсутствует. Используемая команда (фильтрую по IP-адресу клиента):
tcpdump -i eth0 'net YYY.YYY.YYY.YYY' -C 100 -vvv -w dump-server-ftp-through-tcp-tunnel eth0.pcap
dump-server-http-through-tcp-tunnel-tun0.pcap То же, что и выше, но на этот раз захват из интерфейса tun0. Используемая команда:
tcpdump -i tun0 -C 100 -vvv -w dump-server-http-through-tcp-tunnel-tun0.pcap

Редактировать 2016/05/19 в 10:31 GMT

Комментарии и ответы, которые я получаю, говорят о том, что я использую протокол TCP с OpenVPN вместо udp. Как я сказал в своем сообщении выше, между моим сервером и моим домашним компьютером через туннель TCP VPN нет проблем со скоростью:

lftp aixki@10.200.0.1:~> pget 1GB.dat
1073741824 bytes transferred in 11 seconds (95.68 MiB/s)

Но чтобы угодить всем и прекратить комментарии о tcp и udp, вот тест с использованием udp:

сервер:

# openvpn --dev tun --proto udp --port 11000 --ifconfig 10.200.0.1 10.200.0.2 --cipher none --auth none --fragment 0 --mssfix 0 --tun-mtu 48000 --sndbuf 393216 --rcvbuf 393216

клиент:

# openvpn --dev tun --proto udp --port 11000 --ifconfig 10.200.0.2 10.200.0.1 --cipher none --auth none --fragment 0 --mssfix 0 --tun-mtu 48000 --sndbuf 393216 --rcvbuf 393216 --remote dedibox

Тест iperf3 от сервера к клиенту с использованием туннеля udp vpn:

#  iperf3 -c 10.200.0.2  -i 1 -p 5201 -f m -b 1G -u

Connecting to host 10.200.0.2, port 5201
[  4] local 10.200.0.1 port 55287 connected to 10.200.0.2 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec   111 MBytes   935 Mbits/sec  14265
[  4]   1.00-2.00   sec   119 MBytes  1000 Mbits/sec  15258
[  4]   2.00-3.00   sec   119 MBytes  1000 Mbits/sec  15258
[  4]   3.00-4.00   sec   119 MBytes  1000 Mbits/sec  15260
[  4]   4.00-5.00   sec   119 MBytes  1000 Mbits/sec  15259
[  4]   5.00-6.00   sec   119 MBytes  1000 Mbits/sec  15258
[  4]   6.00-7.00   sec   119 MBytes  1000 Mbits/sec  15253
[  4]   7.00-8.00   sec   119 MBytes  1000 Mbits/sec  15266
[  4]   8.00-9.00   sec   119 MBytes  1000 Mbits/sec  15255
[  4]   9.00-10.00  sec   119 MBytes  1000 Mbits/sec  15262
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.16 GBytes   993 Mbits/sec  0.763 ms  141473/150989 (94%)
[  4] Sent 150989 datagrams

iperf Done.

И, наконец, тест скорости от клиента и тестовый сервер скорости, размещенный на testdebit.info, через мой туннель vpn:

# ip route add 62.34.91.3 via 10.200.0.1

# wget -O /dev/null http://3-ipv4.testdebit.info/fichiers/1000Mo.dat
/dev/null               100%[============================>] 953.67M  12.4MB/s    in 79s
2016-05-19 12:27:40 (12.1 MB/s) - ‘/dev/null’ saved [1000000000/1000000000]

Вывод: никакой разницы между UDP и TCP!

Как я уже сказал, проблема в iptables или ipv4.ip_forwarding, но не с OpenVPN / TCP / UDP

Я очень быстро просмотрел ваш последний файл захвата. Мы сразу можем видеть, что RTT в сквозном сеансе TCP составляет около 50 мс или хуже. Ваш клиент рекомендует окно размером около 3 МБ (а не 300 МБ, как я изначально набирал). Сложите их вместе, и у вас будет абсолютный максимум 480 Мбит / с при условии бесконечно быстрого оборудования на каждом конце TCP-соединения. По-видимому, ни один из концов не является бесконечно быстрым.
Так что на вашем месте я бы тоже:

примите полученную производительность (в зависимости от фактических требований)

или:

график RTT на протяжении всего сеанса, чтобы получить точность
используйте произведение задержки полосы пропускания, чтобы точно понять, какая пропускная способность является максимальной для одного потока TCP.
выяснить, откуда берутся компоненты задержки (например, установив ответвитель на туннельном сервере)

ОБНОВЛЕНИЕ: задержка вызвана туннельным сервером. Файлы захвата не делают этого очевидным, но сквозная задержка намного выше, чем я думал изначально. Файлы захвата на основе хоста скрывают продолжительность времени, в течение которого каждый пакет находится на сервере. В идеале вы должны сделать захват на клиенте, и я думаю, что это покажет гораздо более высокий RTT.

dump-server-forward-http-tcp-eth0 frame 17854 - тому пример. Он содержит данные от Интернет-хоста, которые (предположительно) передаются клиенту в 17856. Однако 17856 не подтверждается до 18614, примерно через 222 мсек. Учитывая RTT в 40 мс для клиента, включая некоторую обработку, сервер добавляет по крайней мере 180 мс к одностороннему переходу от приема от хоста Интернета до передачи его по проводам к клиенту. Учитывая, что фрейм 17854 явно не является физическим фреймом, но был повторно собран (возможно, ошибочно), также могут быть аналогичные задержки по отношению к Интернет-хосту.

Если RTT составляет 222 мс, а RWIN - 3 МБ, тогда TCP может передавать только 13,5 Мбит / с.

Мне кажется, что включена разгрузка сегментации TCP и что по какой-то причине TCP обрабатывается на туннельном сервере, когда вы действительно хотите, чтобы он только пересылался. Теперь вам нужно выяснить, почему это может быть так.

ОБНОВЛЕНИЕ: я также только что заметил, что вы говорите, что процессор составляет всего 15%. Если это относится к туннельному серверу, вы говорите, что это C2750 Atom, 8-ядерный. С многопоточным процессором любая устойчивая загрузка процессора на уровне 100% / количество ядер или немного выше (в вашем случае 12,5%) может быть одним основным потоком, насыщающим одно ядро.