PF и работа с OpenVpn



  • В карадце, ситуевина такая. Настроил я OpenVpn, все работает. Но столкнулся с проблемой при работе с базами данных.
    На одном из уделенных серверов, поднят openvpn client и на этом сервере стоит Postgress и базы 1с. Канал 20 Mb. При передачи файла скорость 20 Mb, а вот база работает крайне медленно. Есть предположение что это связано с большим количеством одновременных подключений. В настройках сервера отключил сжатие и поставил 1024 шифрование, в "Custom options" прописал:
    sndbuf 0
    rcvbuf 0
    push "sndbuf 393216"push "rcvbuf 393216"
    После чего полегчало, но не особо намного. При работе канал загружен в среднем на 2-3 Mb всего. Тут 100% идет какое то ограничение на пропускную способность самого OpenVpn.
    Кто сталкивался с такой бедой?
    В локалке все летает…



  • У меня так на сервере :

    sndbuf 100000;
    rcvbuf 100000;
    push "sndbuf 100000";
    push "rcvbuf 100000";



  • @werter:

    У меня так на сервере :

    sndbuf 100000;
    rcvbuf 100000;
    push "sndbuf 100000";
    push "rcvbuf 100000";

    Пробовал и с этими директивами и без них, разница в  моем случае оказалась в пределах погрешности измерений. Скорость ограничивается каналом интернета и производительностью CPU pfSense.
    По поводу 1С - пара удаленных клиентов работают не в терминале, локальный клиент 1С ->сервер 1С через OVPN, жалоб нет, правда используется MS SQL, не PostgreSQL.
    Разницы для удаленного клиента, по идее, быть не должно, ведь связка сервер 1С->SQL лежит уже за OVPN…



  • правда используется MS SQL,  не PostgreSQL

    Вот в этом может быть дело.

    P.s. Допиленный PostgreSQL брать отсюда - https://www.postgrespro.ru/products/1c_build



  • @werter:

    правда используется MS SQL,  не PostgreSQL

    Вот в этом может быть дело.

    P.s. Допиленный PostgreSQL брать отсюда - https://www.postgrespro.ru/products/1c_build

    Возможно, хотя все равно непонятно, ведь, повторюсь,  слой сервер 1С->SQL лежит уже за OVPN.

    Хотя ничто не мешает попробовать, MS SQLexpress вроде как бесплатен и в базовом функционале не отличается от коммерческой версии.



  • @werter:

    правда используется MS SQL,  не PostgreSQL

    Вот в этом может быть дело.

    P.s. Допиленный PostgreSQL брать отсюда - https://www.postgrespro.ru/products/1c_build

    Я пробовал и MS sql перед тем как написать сюда, тоже самое.
    Канал загружен на 10%. CPU и MEM на сервере и на клиенте вообще еле напрягаются.



  • @iliaxxx:

    @werter:

    правда используется MS SQL,  не PostgreSQL

    Вот в этом может быть дело.

    P.s. Допиленный PostgreSQL брать отсюда - https://www.postgrespro.ru/products/1c_build

    Я пробовал и MS sql перед тем как написать сюда, тоже самое.
    Канал загружен на 10%. CPU и MEM на сервере и на клиенте вообще еле напрягаются.

    Клиент толстый ? Или терминал ?

    P.s. Рекомендую SSD для 1с. Тот же samsung 850 evo оч. хорош.  Или вот таких можно пару взять в raid1 - https://market.yandex.ru/product–adata-premier-sp550-240gb/12879161 , https://market.yandex.ru/product--adata-premier-sp550-120gb/12879160  И бэкапы, само собой.



  • Канал 20 Mb

    Как организован канал? Было похожее с провайдерским L2TP. Сайты (некоторые) грузились не полностью, IPSEC поверх этого L2TP едва дышал.
    Вылечилось коррекцией MSS
    https://ru.wikipedia.org/wiki/Maximum_segment_size
    на клиентской стороне.



  • @pigbrother:

    Канал 20 Mb

    Как организован канал? Было похожее с провайдерским L2TP. Сайты (некоторые) грузились не полностью, IPSEC поверх этого L2TP едва дышал.
    Вылечилось коррекцией MSS
    https://ru.wikipedia.org/wiki/Maximum_segment_size
    на клиентской стороне.

    К сожалению
    У меня так на сервере :

    sndbuf 100000;
    rcvbuf 100000;
    push "sndbuf 100000";
    push "rcvbuf 100000";

    Не помогло
    Канал с обеих сторон хороший, все IP статические. Один сервер в датацэнтре, второй юр. лицо с прямым статический IP



  • Попробуйте ipsec, pptp, l2tp etc



  • День добрый. Если еще актуально, в похожей ситуации помог перевод openvpn с tcp на udp.



  • @gost370:

    День добрый. Если еще актуально, в похожей ситуации помог перевод openvpn с tcp на udp.

    Доброе.
    А где у ТС говорится , что у него tcp ?? Опенвпн по-дефолту исп. udp



  • Добавлю.
    Часть клиентов - UDP, site-to-site все TCP.
    Ощутимой разницы между UDP и TCP применительно именно к работе 1C в терминале не замечается.



  • @werter:

    @gost370:

    День добрый. Если еще актуально, в похожей ситуации помог перевод openvpn с tcp на udp.

    Доброе.
    А где у ТС говорится , что у него tcp ?? Опенвпн по-дефолту исп. udp

    А где говориться, что UDP? Про протокол автор не уточнял, поэтому поделился практическим опытом.

    @pigbrother:

    Добавлю.
    Часть клиентов - UDP, site-to-site все TCP.
    Ощутимой разницы между UDP и TCP применительно именно к работе 1C в терминале не замечается.

    У вас изначально не было проблем с производительностью. Не раз наблюдались лаги в работе приложений работающих по tcp через openvpn по tcp на медленных каналах с наличием потерь пакетов и\или высоком пинге. Перевод openvpn на udp значительно уменьшал лаги.



  • У нас была похожая проблема из-за высокого пинга. Канал висел через ростелеком (xDSL). Пинг иногда за 200мс вылетал. Жесть как лагало. Перешли на провайдера через оптику, пинг стал <1мс до удаленного офиса. Все начало работать в разы шустрее.



  • После перехода с DSL на Ethernet тема шейперов\лимитеров\приоритетов сразу потеряла актуальность.
    Причем особенно благоприятно переход на Ethernet (правильнее - FTTB)
    https://ru.wikipedia.org/wiki/Fiber_to_the_x#FTTB
    отразился на VPN (их почти полный набор - L2TP, OVPN, PPTP).



  • @gost370:

    День добрый. Если еще актуально, в похожей ситуации помог перевод openvpn с tcp на udp.

    https://habrahabr.ru/post/246953/



  • @derwin:

    @gost370:

    День добрый. Если еще актуально, в похожей ситуации помог перевод openvpn с tcp на udp.

    https://habrahabr.ru/post/246953/

    По приведенной ссылке в комментариях есть другая ссылка:
    http://www.speedguide.net/articles/windows-7-vista-2008-tweaks-2574

    В смешанной сети (2003, XP, 7, 8, 8.1, 10, 2012)
    Выполнение на всем, что старше 2003, XP
    этих команд (выполнять от администратора):

    netsh interface tcp set global autotuninglevel=disabled
    netsh interface tcp set global rss=disabled

    Существенно увеличивает скорость работы с сетью. Влияет ли эта (де)оптимизация на Open VPN? Допускаю, без нее ни одной машины нет.



  • @pigbrother:

    @derwin:

    @gost370:

    День добрый. Если еще актуально, в похожей ситуации помог перевод openvpn с tcp на udp.

    https://habrahabr.ru/post/246953/

    По приведенной ссылке в комментариях есть другая ссылка:
    http://www.speedguide.net/articles/windows-7-vista-2008-tweaks-2574

    В смешанной сети (2003, XP, 7, 8, 8.1, 10, 2012)
    Выполнение на всем, что старше 2003, XP
    этих команд (выполнять от администратора):

    netsh interface tcp set global autotuninglevel=disabled
    netsh interface tcp set global rss=disabled

    Существенно увеличивает скорость работы с сетью. Влияет ли эта (де)оптимизация на Open VPN? Допускаю, без нее ни одной машины нет.

    Доброе.
    В статье др. рекомендуют:

    TCP Auto-Tuning
    Our recommendation: normal  (unless you're experiencing problems).

    …...

    RSS - Receive-side Scaling
    Recommended: enabled (if you have 2 or more processor cores and a NIC that can handle RSS)



  • Статью прочитал, бегло .

    В моей конкретно сети помогли приведенные команды. Использую давно, еще со времен  Vistы.
    Возможно более внимательный тюнинг даст еще лучшие результаты, надо будет потестировать.



  • Тема вроде как устарела, но, вероятно, проблема так и осталась нерешенной.

    Наткнулся на описание похожей проблемы, приводится такое решение , но проверить не на чем:
    https://www.reddit.com/r/PFSENSE/comments/4wwnko/openvpn_rdp_is_unusably_slow/

    VPN > IPsec > Advanced Settings, enable MSS Clamping and set it to 1300 to start with. Even though the setting is in IPsec it affects OpenVPN as well.

    That will nudge the client to use smaller packets which should more easily traverse the VPN.

    If 1300 is OK you could increase it a bit until you find it breaks. You'd have to stop the connection and restart each time you change the value, however, as changes for that won't take effect until a new state table entry is created.



  • В настройках впн-сервера в Адвансед :

    sndbuf 100000;
    rcvbuf 100000;
    push "sndbuf 100000";
    push "rcvbuf 100000";

    Пробовали ?



  • @werter:

    В настройках впн-сервера в Адвансед :

    sndbuf 100000;
    rcvbuf 100000;
    push "sndbuf 100000";
    push "rcvbuf 100000";

    Пробовали ?

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

    Попутно - пришлось настроить IPSEC  site-to-site между pf 2.3.2 и б-гомерзким Kerio Control.  Не сделать ли отдельный пост с настройками?



  • 2 pigbrother
    Прирост скорости у меня есть с этими директивами.

    Попутно - пришлось настроить IPSEC  site-to-site между pf 2.3.2 и б-гомерзким Kerio Control.  Не сделать ли отдельный пост с настройками?

    Да-да! И с картинками )



  • Подниму тему, т.к вопрос скорости передачи через Open VPN регулярно всплывает.

    В статье описывается положительный результат применения директив sndbuf и rcvbuf применительно к линиям с большой латентностью (высоким пингом):

    Почему тормозит OpenVPN? Размер буферов приема и отправки:
    https://interface31.ru/tech_it/2017/04/pochemu-tormozit-openvpn-razmer-buferov-priema-i-otpravki.html

    В моем случае, как писал выше, применение этих директив практически не повлияло на скорости, (возможно, как раз потому, что каналы качественные) но, как говорят наши зарубежные друзья - YMMV.



  • Доброе.
    Спасибо за статью. Довольно подробно.

    P.s. Было же похожее на хабре 3 года назад - https://habrahabr.ru/post/246953  ;)