PF и работа с OpenVpn

werter

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

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

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

pigbrother

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

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

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

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

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

iliaxxx

@werter:

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

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

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

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

werter

@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 И бэкапы, само собой.

pigbrother

Канал 20 Mb

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

iliaxxx

@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

werter

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

gost370

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

werter

@gost370:

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

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

pigbrother

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

gost370

@werter:

@gost370:

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

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

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

@pigbrother:

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

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

A Former User

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

pigbrother

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

derwin

@gost370:

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

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

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? Допускаю, без нее ни одной машины нет.

werter

@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)

pigbrother

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

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

pigbrother

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

Наткнулся на описание похожей проблемы, приводится такое решение , но проверить не на чем:
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.

werter

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

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

Пробовали ?

pigbrother

@werter:

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

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

Пробовали ?

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

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