Есть SERVER 2016, на нем поднят SQL и опубликованы WEB базы.Настроен RRAS.
На удаленном компьютере установлен тонкий клиент и подключается к WEB базе на сервере. Создано VPN соединение к серверу.
Если подключаться по внешнему IP сервера, то всё летает. Если же подключаться к базе через VPN соединение, то 1С работает раз в 5 медленнее (на глаз).
Пробовал настраивать VPN соединение на роутере (PPTP) и на компе (L2TP), разницы в скорости не увидел.
На сервере канал 1гбит, на клиенте 100мбит.
Куда копать?

(0) копать в сторону проверки пингов и скорости через VPN-канал. Желательно проверять пакетами большого размера. А дальше разбираться что не так - может, c MTU надо поиграться, может, оборудование с какой-то стороны не успевает расшифровывать/зашифровывать.

есть такая штука IPerf, она ставится с двух сторон как клиент-сервер и позволяет реальную скорость на канале померить...

(2) Спасибо, попробую

(2) Прогнал IPerf, скорость и по ВПН и по внешнему IP показывает около 20мбит/с. Маловато, но одинаково, значит не в этом дело

использую radminVPN 10Мб 5 клиентов БП 3.0 все отлично как в офисе разницы никто не замечает

(4) возможно, у вас при передаче через VPN пакеты сильно фрагментируются и из-за этого замедление. Посмотрите реальное значение МТU и попробуйте увеличить.

(6) Да, на клиенте 1500, на ВПН 1400

это реальная полезная нагрузка или установка? Поиграйтесь пингом с ключами -f -l <тут число от 1500 и ниже>. Если перестает ругаться при цифре сильно ниже 1400 - надо что-то делать.

(8) Перестало ругаться при 1372

Выставил MTU на клиенте 1372, никакого эффекта, 1С так же тормозит

Теперь что по ВПН, что по внешнему Ip пролазят одинаковые пакеты, но толку нет

да нет, 1370 это и само по себе прилично, значит дело не в этом.
А как работает тонкий клиент без веба?

(12) Без веба, это что имеете в виду? Указать подключение сразу к SQL? Пробовал, не подключается

Там вроде настройки скуля нужны чтобы из сети подключаться

имею в виду просто тонкий клиент 1С без публикации базы в вебе. Через VPN это в принципе все работать должно, т.е. вы должны видеть ваш сервер 1С, т.к. вы находитесь в той же сети. Если тонкий клиент по имени его не находит, попробуйте по IP или имя в хостс пропишите.

я вот только что тонким клиентом из дома подцепился к рабочей базе через VPN, хотя у меня база не опубликована в веб

Странно, выдает ошибку "Этот хост неизвестен", хотя прописывал IP

(17) когда ИБ регистрировали в консоли сервера 1С, прописывали IP или имя?
Если имя, то на клиенте в файл hosts попробуйте строку вписать, соответствие имени сервера его адресу. Потом пропинговать и то и другое, убедиться что все хорошо. И подсоединиться по имени.
Есть такая заморочка у 1С, да.

Поправил hosts и подключился. Работает, но дико тормозит

А RRAS крутится на том же серваке, где стоит SQL и сервер 1С?

(20) Да, всё стоит на одном сервере

Может IIS странно себя ведет?

(22) может быть, но вы же пробовали просто тонкий клиент без публикации, и говорите, все то же самое. Ну попробуйте остановить IIS и еще раз после этого тонким клиентом зайти, лучше будет или нет?

Я боюсь, что просто RRASу, точнее шифрованному туннелю, не хватает ресурсов процессора, когда одновременно работает скуль и сервер 1С на одной машине. Ему их надо не много, но обязательно в реальном времени, чтобы успевать зашифровывать/расшифровывать трафик. Я никогда так не делал, у меня VPN всегда был на отдельной железке (ZyWall, Mikrotik и т.д.). И сейчас тоже.

(23) Так тонкий клиент без публикации и должен медленнее веба вроде работать.

(25) мы просто пробуем разные варианты. И "медленнее" не значит "тормозит пипец как". У меня вот он сейчас крутится вполне приемлемо для моего старенького сервака, работать вполне можно.

(24) Процессор вполне могучий Xeon E2176G, по идее это для него вообще пыль

(27) Во всяком случае точно на порядки быстрее Микротика

(28) микротик специализированная железка на специализированной оси, которая занимается только одним и ничем больше. Это всегда лучше, чем система общего назначения.

(29) Согласен. Как выяснить что именно в этом дело?

я бы посмотрел, что происходит на сервере с производительностью при работе клиентом 1С по VPN, и заглянул бы в журналы событий. Похоже, что проблема там. Возможно, что-то можно подкрутить в настройках RRAS, но тут я не силен, последний раз ее еще на 2003 серваке настраивал и с тех пор никогда этого на винде не делал, не понравилось.

если есть возможность одновременно с 1Ской удаленный рабочий стол сервера открыть - то в общем-то все это можно провернуть. Еще интересная тема - запустить пинг с ключом /t на сервер и посмотреть, что будет происходить с задержками при попытках работы в 1С.

разница в пинге какая? возможно, одна или обе стороны туннеля не поддерживают (или не включено) аппаратное шифрование, по этому пакеты долго шифруются и расшифровываются.

https://www.nic.ru/help/winmtr-diagnostika-setevyh-soedinenij_6799.html

(31) В журнале событий вообще ничего криминального.

(32) Пинг с ключом запустил, при работе с 1С пинг особо не меняется, стабильно в районе 65мс со скачками до 80

(33) Пинг на ВПН и внешний IP абсолютно одинаковый

(34) По ВПН даже лучше проверку проходит)))
Потеря пакетов 0%

(37) а как себя ведет загрузка процессора на сервере и на клиенте и объем трафика вот этого VPN-соединения в процессе попыток работы с 1С? Параллельно всем этим попыткам еще работающие сеансы в 1С есть или один?

(34) Вот вывод.
А что это за точка в маршруте такая с адресом автонастройки?
|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                               10.77.4.1 -    0 |   81 |   81 |    1 |    3 |   40 |    2 |
|                            169.254.0.41 -    0 |   81 |   81 |   62 |   66 |   74 |   68 |
|                               10.99.0.1 -    0 |   81 |   81 |   62 |   66 |   86 |   67 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

(39) Загрузка процессора и на сервере и на клиенте никак не реагирует на работу 1С через ВПН, хотя ничего тяжелого не запускал, ибо просто открытие карточки номенклатуры происходит секунд 15.
Трафик на ВПН тоже не растет при работе 1С.
На сервере работает еще несколько сеансов через внешний IP

Кстати, на этом же сервере запущена 1 вирт. машина с Сервер 2008R2 внутри. Из нее подключается такой-же тонкий клиент по виртуальному адаптеру и никаких проблем не имеет

прям хз, попробуй глазьями трафик посмотреть впн и напрямки
https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview

(40) виртуальный шлюз, через который идут пакеты из 10.77.4.1 в 10.99.0.1. Скорее всего соответствующее правило в таблице маршрутов создается автоматически при установке соединения с VPN-сервером.
(42) рассмотрите подъем VPN на отдельной железке. Вполне может быть, что маршрутизатор в вашей организации это умеет делать, надо только настроить.

(44) Сервер в дата-центре, на отдельной железке не получится к сожалению

от бкзысходности, кипэлайв стоит на впнке? мб она поднимается каждый раз

(46) подключаемся Микротиками, там keep-alive по дефолту 60

ну как вариант проверь трассировку с сервера до клиента, и время получения на сервере IP клиента по его имени.

то есть
клиент -> сервер по имени на прямую
клиент -> сервер по имени через впн
клиент -> сервер по IP на прямую
клиент -> сервер по IP через впн

и самое главное все то-же в обратном направлении, 1с работает создает и прямые и обратные соединения, мне кажется, что у тебя проблеммы именно с обратным соединением или обратной зоной DNS


ps
возможно у тебя в параллель работают 2 маршрута и прямой и через впн, в этом случае возможны нюансы с выбором приоритетов, штатно это не настраивается, только через реестр

(48) Да, сейчас несколько пользователей подключены напрямую и я параллельно пытаюсь настроить через ВПН

(48) Имена вообще не используем, везде IP прописываем

(49) короче, 1с работает примерно так:

1. клиент создает конект к сервер и подключается к менеджеру кластера,

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

3. после авторизации (не обязательно виндовой) менеджер выбирает для тебя  рхосту, и именно рхост устанавливает с клиентом соединение. Вот именно тут и возникают проблеммы, РХОСТ всегда оперирует именем клиента а не его IP и именно по его имени он пытается установить это соединение, а тут еще веб сервер который собственно и является клиентом

4. веб сервер получив коннект от рхоста пытается определить какому именно клиенту это надо отправить и по какому маршруту, вероятно у него есть 2 маршрута и он пытается отправить по неправильному получает отказ и потом повторяет по правильному

(51) А как это победить?
P.S. АД не используем

(48) трассировка по IP бегает и туда и обратно свободно

(52) не надо побеждать, сначало надо проверить маршрут от рхоста до клиента...

тут нужен снифер для того что-бы расковырять заголовок пакета и дальше по этому заголовку уже тестировать и смотреть как и куда идет. короче это задача сетивика а не 1с ника

Так, господа, ситуация получила неожиданное направление.
Так как задача была сделать удаленные сети доступными друг для друга, то RRAS был настроен соответственно. Были созданы интерфейсы вызова по требованию, прописаны маршруты и т.д.
Попробовал подключиться учеткой не настроенной в RRAS и вуаля!!! 1С работает прекрасно.
1     2 ms     5 ms     2 ms  router.lan [10.77.4.1]
  2    71 ms    68 ms    66 ms  HOST [10.99.0.1]
Из маршрута пропал этот странный пункт со странным адресом.
Вот только клиент с этой учеткой невидим для других клиентов.
И шо делать?))

(55) Поставить между сервером и интернетом нормальную железку, которая будет этим заниматься.

(51) > РХОСТ всегда оперирует именем клиента а не его IP

Вот тут ты не прав. Кластер оперирует тем что ему указали при настройке. Если в кластере указан айпи, то возвращается айпи, если имя, то имя

(45) ну поднимите там роутерОС или пфСенс на виртуалке. Всяко лучше чем виндовый роутер.

(57) тут именно я и прав, имя клиента зашито в каждом пакете который идет на сервер 1с, это обязательное поле :) IP там просто нет... я проверял...

то есть без разницы чего ты прописываешь в подключении к базе имя сервера или его IP обратное соединение идет всегда по имени...

(59) и все таки я настаиваю, что подключение идёт по следующему алгоритму:
1. Клиент подключается к кластеру
2. Кластер решает к какому серверу подключить клиента. И, в зависимости от того как прописаны рабочие серверы в кластере, возвращает это значение клиенту уже для подключения к обслуживающему процессу.

От непонимания второго пункта и возникает у людей куча вопросов и проблем. Хотя так ведёт себя любая кластерная клиент серверная система.

(60) если бы так было, то все было-бы проще....

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

(59) > имя клиента зашито в каждом пакете который идет на сервер 1с

только что заметил.. а причем тут собственно имя клиента?

(62) мы похоже про разные вещи говорим.. ты утверждаешь, что сервер(рпхост) инициирует подключение к клиенту, а не наоборот?.. извини, но это бред

(56) Так и было, пока сервер стоял в офисе. Но невозможность обеспечить 24/7 заставила переехать в дата-центр и теперь нет возможности поставить железку

(58) Хорошая мысль. А как заставить весь трафик через нее идти? Простой проброс портов мне кажется тут не поможет

(65) Не претендую на истину, но вот вариант... На серваках редко бывает одна сетевая карта, обычно две и больше. Делаете на виртуалке под роутер два адаптера, один бриджем с одной железной картой на хосте, другой с другой. В первую включаете инет, а на второй на хосте настраиваете все что вам надо, включая шлюз по умолчанию. И вуаля, весь трафик пойдет через роутер.

(65) В интернете много мануалов. Сам как то пробовал для тестов, но было очень давно.

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

(63) >>>ты утверждаешь, что сервер(рпхост) инициирует подключение к клиенту
да это так, в сабже именно сервер инициирует подключение к WEB серверу, а тот уже пытается это соединение переложить в клиентскую сесию

(68) (66) https://wiki.mista.ru/doku.php?id=it:set_dual_net

таки решили или нет?

Значит так: вопрос с RRAS не решился. В нете есть несколько подобных тем на форумах, ни у одной нет решения.
Решили поступить иначе. Взгромоздили RouterOS на виртуалку, взяли еще один белый IP, присвоили его этому программному роутеру, настроил подключение пары клиентов к серверу через этот роутер. Потестировал, никакой разницы в скорости работы 1С между ВПН и прямым адресом не заметил. Теперь занимаюсь переключением всей инфраструктуры на этот программный роутер.

(71) У вас там, чай, виртуалки-то на Hyper-V подняты, а на хостовой системе 1С крутится? Если так, то красота: -40% скорости 1С. И ваш новенький Xeon Coffee Lake работает теперь как старый Sandy Bridge. Можете прогнать тест Гилева на файловой базе (на клиент-серверной падение аналогично), чтобы убедиться.

(72) На хостовой 1С и скуль.
2 виртуалки: с терминалом и роутером.
А почему должна скорость упасть? уже несколько лет виртуалки вместе с 1С крутим и никогда не жаловались

(73) Особенность работы Hyper-V. Скорость падает, даже если просто включить роль Hyper-V. Решение одно: не использовать Hyper-V на машине с 1С. Либо смириться с -40%.

(74) Хм... вроде бы я когда-то гонял 1С без роли гипер-в и разницы не было. Но надо проверить. Есть у нас резервный сервер, попробую вечером удалить роль гипер-в и посмотреть на тест Гилева

Кстати, когда всё работало через RRAS, то были проблемы с доступом к сетевым принтерам из других сетей, они постоянно отваливались.
Через RouterOS всё работает.
Вывод: RRAS непригоден для использования!

Как то мучался с этими VPN виндовыми, короче решил все через
https://www.softether.org
Поставил мост на сервер, выдал сертификаты клиентам, работали они как и через (L2TP) так и через клиентское приложение. Из разряда поставил и забыл.

(76) я это понял еще лет 12 назад. Похоже, что сейчас принципиально лучше не стало.
Плюсом нормального роутера еще является то, что вы можете настроить VPN индустриальных стандартов - IPSec или SSL, а не только этот древний PPTP, который вдобавок ненадежен.

Еще OpenVPN есть. Ставится на что угодно. Надежен.

(72) откуда такая инфа - что платформа 1С работает на гипер ви медленнее на 40 %?

з.ы. глядите сеть и че адинска делает, на крайняк запретить ей выход в инет и посмотреть че будет.
ну или если у вас не совсем обычная 1С :) поставить чуть другую или обычную :)

(72) Прогнал я тест Гилева на одном и том же компе с ролью Гипер-В и без нее.
С Гипер-В 29 баллов
Без Гипер-В 31 балл
Разница в пределах погрешности.
Так откуда дровишки про 40%?

(82) https://efsol.ru/articles/1s-mssql-postgresql.html
Разные проценты могут быть, в то числе и довольно заметные.
Была эта ссылка в одной из тем.
Другое дело, что разница между 1.7 и 2.4 секундами психологически незаметна(исключая самых дотошных). А скажем, разница в проведении чего-либо за 60 мин и за 75 мин. уже будет ощутима.
Можно еще посмотреть влияние виртуализации на многопоточную интенсивную нагрузку, http://fragster.ru/perfomanceTest/ , когда число потоков(сеансов) значительно превышает число ядер. Может, ничего страшного и нет.

(82) Была когда то статья от самих MS, там писалось о 10% просадки по их наблюдениям.