Я использую «сервер», который представляет собой взломанный Apple TV первого поколения под управлением Linux.
У меня много проблем с тем, чтобы производительность OpenVPN была такой, какой я ожидал от моей новой настройки OpenVPN. Сеть выглядит так:
Домашняя LAN 172.16.1.0/24 VPN-клиенты (10.8.0.0/24) -> Airport Extreme (переадресация порта OpenVPN) -> OpenVPN Server (прослушивание порта OpenVPN 1294) -> Home iMac -> NAS Box
Я использую маршрутизацию со следующим файлом конфигурации. Маршрутизация настроена с использованием IP Masquerading на сервере OpenVPN, поскольку я не могу создавать статические маршруты на моем шлюзе, который является Airport Extreme). Обратите внимание, что загрузка ЦП на VPN-сервере минимальна во всех тестах ниже.
Конфигурация сервера:
port 1294
proto udp
dev tun
ca privnet/ca.crt
cert privnet/server.crt
key privnet/server.key
dh privnet/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
script-security 2
push "route 172.16.1.0 255.255.255.0"
topology subnet
route 192.168.163.0 255.255.255.0 10.8.0.2
tun-mtu 1500
fragment 1000
mssfix
В моих тестах используется только один VPN-клиент. Без строк фрагмента и mssfix в конфигурациях клиента и сервера производительность была настолько плохой, что я получал один кадр VNC или около того в секунду при подключении к VPN через два 35-мегабайтных соединения FiOS. Когда я добавил эти строки, производительность VPN улучшилась, но все еще остается очень медленной.
Однако мой более простой тестовый пример - это производительность SCP.
Может ли кто-нибудь подсказать, что делать, и почему я вижу эти сильно различающиеся скорости?
Что ж, это выстрел в темноте: вопреки Принято считать, У меня была ситуация с легко перегруженным соединением (ADSL 6 / 0,6 Мбит / с), которое работало лучше (я бы сказал только?), Если трафик OpenVPN инкапсулирован в поток TCP, а не в дейтаграммы UDP.
Проблема заключалась в том, что тайм-ауты внутреннего TCP-потока произошли из-за отброшенных UDP-пакетов зашифрованного потока (первичным источником была перегрузка). Каким-то образом масштабирование окна во внутреннем TCP-канале не помогло, как ожидалось (оно должно уменьшаться в основном до цикла отправки-ожидания).
Что касается диагностики: Установить WireShark и захватить трафик openvpn и трафик локальной сети и следить за чрезмерными повторными передачами TCP. Это признаки отброшенных пакетов. Также посмотрите, есть ли проблемы с маршрутизацией из-за того, что пакеты появляются на неправильном интерфейсе или с неправильным IP (как заметил JakeRobinson).
Также попробуйте уменьшить tun-mtu до чего-то невинного, например, 1300. Это повредит максимальной скорости, но не в регионе, в котором у вас возникли проблемы.
Удачи и дайте нам знать, если узнаете причину!
MTU обычно является проблемой для VPN. Фрагмент может помочь, но вы можете попробовать уменьшить MTU на тестовой машине и выполнить тестовый SCP.
Другая вещь, на которую вы можете обратить внимание, - это NAT. Сделайте TCPdump на внутренних интерфейсах (незашифрованный трафик) и убедитесь, что вы видите ожидаемые IP-адреса. Я видел несколько неправильно настроенных NAT и маршрутизации, которые полностью снижали производительность.
Кроме того, TCPdump сообщит вам размер пакета, что хорошо для устранения неполадок.
Разобрался: это была проблема, аппаратная или драйверная, с сетевой картой на сервере. «Сервер» - это взломанный Apple TV первого поколения под управлением Linux, и по какой-то причине встроенный Ethernet не очень хорошо работал при маскировке. Я подключил USB-адаптер Gigabit Ethernet, и все в порядке!
Если я хорошо понимаю вашу конфигурацию, я думаю, что у вас плохая строка в конфигурации сервера:
push "route 172.16.1.0 255.255.255.0"
Эта строка является директивой для сервера для отправки клиенту, этот маршрут в подсеть 172.16.1.0/24 проходит через VPN-сервер, что неправильно, не так ли?
И, во-вторых, я думаю, что вместо этой строки в настройках сервера должна быть эта строка:
push "route 192.168.163.0 255.255.255.0"
потому что это сеть за VPN-сервером ...
Вы можете проверить это, когда вы подключитесь к серверу VPN и составите список своих маршрутов ...