LINUX.ORG.RU
ФорумAdmin

Нетривиальная проблема OpenVPN debian 7 server + windows 7 client

 , , , ,


1

1

Здравствуйте Уважаемые!

Намедни углубился в вопрос изучения vpn сетей, и столкнулся с нетривиальной проблемой на windows 7 клиенте openvpn. Ставилась последняя версия из официального источника, версия 2.3.9-I601-x86_64 С установкой подключения и скоростью проблем нет, но заметил что сайты стали открываться с небольшой задержкой подключения, начал пинговать шлюз приватной сети из клиента (который работает на debian 7), и клиент со шлюза во время открытия сайтов и увидел, что в в этот момент пинг пропадает, вернее становится вместо нормального 10-15 - 1000, 2500 и более, что соответственно ведет к потери пакетов других сервисов (например запущенная онлайн-игрушка «подвисает»). Как только сайт открывается, пинг снова приходит в норму. Причем не важно есть ли шифрование или сжатие, игрался с настройками mtu, как описано в тонне статей, проштудировал весь man openvpn - все бесполезно. Гугление подобной проблемы так же ни к чему не привело. На нетбуке с ubuntu и дохлыми процессорами atom таких проблем на клиенте openvpn и деградации трафика нет, все работает в норме. Запускал клиент openvpn на тестовой виртуалке с windows 2008 R2 server в дата-центре (думал что проблема в домашнем интернете) - та же самая ерунда, причем шлюз и клиент находились в одной сети дата-центра. Хотел бы услышать ваши мнения по поводу стабильности openvpn клиента на windows, может кто уже сталкивался с подобным, и есть простое/сложное решение, все таки технология не новая, и последния версия клиента аж от 16 декабря, т.е. вышла пару дней назад. Добавлю: нагрузка на cpu минимальна, vpn сервер работает на дедике, прямая связь между клиентом и сервером - без нареканий, и там и там фаерволы отключены, антивирусов на клиенте нет. Логи сервера и клиента чистые, без каких-либо ошибок. На всякий случай прилагаю конфиги сервера и клиента:

Сервер: server.conf

mode server
daemon vpn-server
opt-verify
topology subnet
local AAA.AAA.AAA.AAA
port 1194
proto udp
dev tun

cipher BF-CBC
comp-lzo
fast-io
nice -19

tun-mtu 1500
fragment 1400
mssfix 1400

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

tls-server
tls-auth ta.key 0

client-config-dir ccd

server 10.8.0.0 255.255.255.0

client-to-client
keepalive 10 60
max-clients 100

user nobody
group nogroup

persist-key
persist-tun

status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log

verb 4

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

txqueuelen 1000

route 10.8.0.0 255.255.255.0

профиль клиента: ccd/node03

ifconfig-push 10.8.0.4 255.255.255.0

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

Клиент: client.ovpn

client
dev tun
proto udp
remote AAA.AAA.AAA.AAA 1194
resolv-retry infinite

cipher BF-CBC
comp-lzo

nobind
persist-key
persist-tun
verb 3

tun-mtu 1500
fragment 1400
mssfix 1400

ca "c:\\Program Files\\OpenVPN\\config\\keys\\ca.crt"
dh "c:\\Program Files\\OpenVPN\\config\\keys\\dh1024.pem"
cert "c:\\Program Files\\OpenVPN\\config\\keys\\node03.crt"
key "c:\\Program Files\\OpenVPN\\config\\keys\\node03.key"
script-security 2
tls-auth "c:\\Program Files\\OpenVPN\\config\\keys\\ta.key" 1
status "c:\\Program Files\\OpenVPN\\log\\openvpn-status.log"
log "c:\\Program Files\\OpenVPN\\log\\openvpn.log"

Над решением этой проблемы бьюсь уже 3-й день, пока безрезультатно. Буду рад любому совету.



Последнее исправление: ctapkom (всего исправлений: 5)

Ответ на: комментарий от svr4

А что вас смутило в этих параметрах? VPN Сервер так же служит для vpn клиентов на debian, это только у windows клиента драйвер ограничен 100 мбитами, а linux у меня выжимает более 200 мегабит без шифрования.

ctapkom
() автор топика
Ответ на: комментарий от svr4

Более того, в рамках приватной сети, для серверов linux, связанных между собой, tun-mtu можно задавать выше стандарта, и получать хорошую скорость. Это конечно бесполезно для выхода в инет, но в рамках сети бывает очень полезно. Прежде чем писать что-то бессвязное, изучите для начала матчасть: https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux

ctapkom
() автор топика

Уберите вот этот вот весь мусор из конфигов сервера и клиента:

sndbuf 393216
rcvbuf 393216
push «sndbuf 393216»
push «rcvbuf 393216»

txqueuelen 1000

tun-mtu 1500
fragment 1400
mssfix 1400

cipher BF-CBC
comp-lzo
fast-io
nice -19


Перезапустите сервисы, переподключитесь и перепроверьте еще раз. Результат с конфигами озвучьте тут, подумаем.

zgen ★★★★★
()
Последнее исправление: zgen (всего исправлений: 1)
Ответ на: комментарий от ctapkom

Прежде чем писать что-то бессвязное, изучите

Вы тут учить пришли, или совета спрашивать? Если у вас проблема и вы не знаете, как её решить, то делайте то, что вам говорят. Если не хотите - тогда очевидно, что лучше вам и дальше справляться самостоятельно.

zgen ★★★★★
()
Последнее исправление: zgen (всего исправлений: 1)

В настройках виртуального сетевого адаптера openvpn шиндошьс пробовал отключать ipv6, QoS и прочие плюшки?

afanasiy ★★★★
()
Ответ на: комментарий от zgen

Это не мусор, это попытки «сплясать с бубном», хуже от этого не будет, скорее наоборот, дает прирост скорости для линукс-клиентов (с каналом более 100 мбит). Уже пробовал, та же самая история. У меня подозрение, что дело в самой клиентской ОС, а точнее Windows 7, или Windows 2008 R2 Server. Сейчас хочу развернуть тестовую виртуалку на Win XP и проверить, подозреваю что на ней проблем не будет. Если это так - значит нужно что-то менять в ОС win 7

ctapkom
() автор топика
Ответ на: комментарий от afanasiy

ipv6 сразу же выключил после лога ошибок на сервере openvpn о «неверных адресах клиента», т.к. ни на клиенте, ни на сервере их пока использовать не планирую, все нестандартное выключил в первую очередь. Проверил сейчас с отключенным qos - та же история.

ctapkom
() автор топика
Ответ на: комментарий от zgen

Я сюда пришел именно за советом, а не сарказом. Все стандартные вещи уже перепробывал, вплоть то минимальных конфигов на клиенте и сервере.

ctapkom
() автор топика
Ответ на: комментарий от ctapkom

У меня подозрение, что дело в самой клиентской ОС, а точнее Windows 7

Вас не наводит на мысли, что ни у кого нет проблем, а у вас есть? Нет?

Да, возможно это баг конкретной версии openvpn или драйвера под Windows, но для того, чтобы это выяснить, раз уж вы пришли сюда сказав что потратили уже 3 дня и у вас больше нет идей, надо следовать советам и говорить о результатах.

Если вы не будете этого делать - будете вынуждены справляться собственными силами и «виноваты» в этом будете сами.

zgen ★★★★★
()
Ответ на: комментарий от ctapkom

Как я писал выше: уже пробовал, безрезультатно.

Вы не указали версию сервера.

Рекомендую попробовать откатиться на несколько версий (желательно мажорных) назад на клиенте и проверить (на чистом конфиге вытерев всё, что я указал выше) еще раз, изменилась ли ситуация.

zgen ★★★★★
()
Ответ на: комментарий от ctapkom

И, кстати, ставьте 32 битную версию на клиент она гораздо распространенней и есть шанс что её вылизали лучше.

У меня, к примеру 32 битная 2.2.1 несмотря на x64 ОС.

zgen ★★★★★
()
Ответ на: комментарий от ctapkom

То, что длинный txqueuelen - это не есть хорошо.

Крутить всякие буфера, не представляя себе, для чего это делается - тоже.

Mtu по логике вещей должен быть меньше 1500 (ethernet) минус длина заголовка IP, минус длина заголовка udp, минус длина служебной инфы ovpn.

svr4
()
Последнее исправление: svr4 (всего исправлений: 1)
Ответ на: комментарий от zgen

Почистил конфиги на сервере и клиенте убрав перечисленные выше параметры, поставил 32 битную версию, стало только хуже: http://prntscr.com/9fouo6

Debian 7:

root@vpn:/etc/openvpn# uname -a
Linux vpn 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u6 x86_64 GNU/Linux

Версия сервера OpenVPN:

root@vpn:/etc/openvpn# openvpn --version
OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Dec  1 2014
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>

  $ ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --libexecdir=${prefix}/lib/openvpn --disable-maintainer-mode --disable-dependency-tracking CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security FFLAGS=-g -O2 LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now --enable-password-save --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --mandir=${prefix}/share/man --with-ifconfig-path=/sbin/ifconfig --with-route-path=/sbin/route

Compile time defines:  ENABLE_CLIENT_SERVER ENABLE_DEBUG ENABLE_EUREPHIA ENABLE_FRAGMENT ENABLE_HTTP_PROXY ENABLE_MANAGEMENT ENABLE_MULTIHOME ENABLE_PASSWORD_SAVE ENABLE_PORT_SHARE ENABLE_SOCKS USE_CRYPTO USE_LIBDL USE_LZO USE_PF_INET6 USE_PKCS11 USE_SSL

ctapkom
() автор топика
Ответ на: комментарий от svr4

txqueuelen менял для debian-клиентов с жирным каналом, при значении 1000 и использовании vpn как шлюз в инет, debian клиент загружает файлы из инета со скоростью 20-30 мб/c (с шифрованием), если убрать этот параметр, скорость падает не более 7 мб/c тоже самое касается буферов.

Если не указывать tun-mtu явно (например убрать его из конфига), vpn сервер поднимает его как раз 1500, пакетами уже занимается сам openvpm, конкретно для udp - fragment 1400 mssfix 1400 значения ниже, чем выдает mtu-test

ctapkom
() автор топика
Ответ на: комментарий от ctapkom

Спасибо!

Попробуйте сменить протокол передачи с udp на tcp. Станет медленнее (из-за накладных расходов), но возможно уменьшаться или исчезнут потери. Разумеется это для проверки.

Кстати, действительно простое открытие сайта к этому приводит или же с клиента уходить и другой трафик во время замера. Если есть другой трафик, то неплохо было бы понять, насколько он велик и внутри или снаружи от тунеля он идет.

zgen ★★★★★
()
Последнее исправление: zgen (всего исправлений: 1)
Ответ на: комментарий от zgen

Это вам спасибо за участие ;) Уже пробовал менять udp на tcp, в том числе пробовал менять topology на p2p и net30 - все равно начинается потеря пакетов до шлюза при загрузке данных Потери пакетов начинаются именно в момент открытии в браузере сайтов, пока сайт не загрузится, идут потери, как только загружается - потери прекращаются. Причем самое интересное - далее при серфе на открытом сайте, потерь пакетов уже не наблюдается. Такое ощущение, что проблема возникает в момент установки соединения, а не загрузки данных. Весь посторонний трафик выключен, ни торрентов, ни чего либо еще фоново не грузится.

ctapkom
() автор топика
Ответ на: комментарий от ctapkom

Кстати, сейчас создал vm в virtualbox на локальной машине (на которой проблемы, win 7), поставил win xp 32, подключил через мост, поставил клиент openvpn, там все гораздо лучше: пинг конечно подскакивает во время открытия сайтов, но не так очумело как в win7, а с учетом, что это виртуалка, и CPU не может использоваться на 100% как в хост-системе, могу предположить, что подобной проблемы на машине с win xp не будет, либо будет, но те так явно выражено. http://prntscr.com/9fp8fz

ctapkom
() автор топика
Ответ на: комментарий от ctapkom

Исправил проблему ;))) большое спасибо zgen за наводку ;) похоже все дело в версиях openvpn, на сервере стоит старая версия 2.2.1, ставилась из стандартных репозиториев wheezy,поставил себе клиент 2.2.2 - все тут же залетало. Буду сейчас обновлять версию сервера, чтобы с клиентам не было проблем. Еще раз Всем спасибо за участие, тему можно закрывать.

ctapkom
() автор топика
Ответ на: комментарий от ctapkom

Во оно как, раньше openvpn за такой фигней замечен небыл. Практически всегда у меня версия сервера сильно старее клиентов. Пока от пользователей вин. жалоб не поступало.

anc ★★★★★
()
29 сентября 2016 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.