» зависает RDP и отваливается весь сервер

Обратил внимание, что зависанию предшествует жор ресурсов ядром system32.

Из сетевых тонкостей: подключаются пользователи через туннель VPN over IPSEC (реализован на Cisco)

Saan23
мой батник из поста выше можно запускать на любой машине, доступной через тот же впн или в терминалке, запущенной в виртуалке на том же сервере.
ProdumAnsky
Так это не "ни в каком", а в самом что ни на есть явном.=)
Значит проблема таки с большой вероятностью с MTU или чем-то подобным, которая вылезает в момент "определения качества подключения", а не с конкретной реализацией впн-а.

Пропинговал сервер на MTU, показывает 1500 (1472). Это вроде стандарт. Где еще можно посмотреть?

Может быть с сетью и впн связана разгадка следующейго бага. При попытке сохранить на примонтированный жесткий диск клиентского компьютера (редирект) из под 1С последняя зависает.

В настройках сетевого оборудования: crypto ipsec df-bit clear, ip tcp adjust-mss 1390, интерфейсы - 1500.

Все же вымирание терминалки связано с проблемами на калане связи.
На канале увеличились потери пакетов. Через какое-то время умер терминальный сервер.

Что можно попробовать изменить на настройках сети сервера?

Первоначально такая же проблема, которая в итоге переходит в маты на сервер лицензирования....
Сервер проверил не один раз, так в итоге и не понятно в чем дело....
Недавно поставил Крипто-ПРО ... началось через неделю после установки .. больше ничего не ставилось, даже обновы виндовые не ставились ..

После последнего зависания отключил политиками использование RDP-UDP.
С тех пор пока не зависало, несмотря на неоднократные проблемы у провайдеров (и на сервере инет пропадал, и со стороны клиентов на 4G модем пересаживаться пару раз приходилось). Полторы недели, конечно, не срок, но очень похоже на то, что косячит именно UDP - часть.

Так же неделю назад отключил UDP. Отключил проверку качества связи. RemAPP сбрасываются после отключения сразу.
При проблемах на канале - все равно валится. Во всяком случае один раз висло.

Снес крипто-про, полет нормальный.
В итоге не понятно в чем причина я так понимаю ... и это плохо ...

Про полет нормальный с уверенностью можно говорить только через месяцок-другой аптайма.
У меня и по 3 недели между зависаниями бывало.

Присоединяюсь с аналогичной проблемой. Выделенный сервер у Hetzner, W2012R2 (standalone, RDSH и лицензирование). Есть CryptoPro CSP v.3.9.8003. Не могу сказать были ли проблемы до его установки, т.к. его установка совпала с запуском реальных пользователей на сервер, а до этого два месяца заходили только админы. Вот ссылка на обсуждение такой же проблемы http://social.technet.microsoft.com/Forums/ru-RU/0ac0ac7c-16ce-4a07-8a15-0b0192829450/terminal-server?forum=WS8ru . Совершенно уверенно могу сказать, что в 100% случаев (и никогда вне ситуаций зависания TS) в журнале событий появляется предупреждение: Код события 20497, Лицензирование удаленных рабочих столов затратило слишком много времени на обработку клиентской лицензии. Источник TerminalServices-RemoteConnectionManager. Появляется оно спустя около 10ти минут после первой жалобы пользователей, в общем-то в тот момент, когда повыкидывало и тех, кто был подключен.

abgluck - у меня каждое утро была такая беда. Сейчас с момента сноса крипто-про все ровно, так что это уже полет нормальный... Конечно еще посмотрю, но результат пока на лицо ...
ПС: помимо крипто-про снес еще компоненты контуровские. (контур-экстерн)

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

Я сменил протокол в openvpn с tcp на udp, заодно сменил mtu с 1500 на 1400
Проблема всё-равно возникает.
К тому же добавилось несколько новых "тараканов".
Клиентские компы не могут подключиться к серверу, помогает перезагрузка роутеров.
В общем, глобального решения не получилось.

MikeSh2
Видимо где-то накосячил при перенастройке опенвпна, там MTU если менять, то одним конфигом дело не ограничится - надо менять конфиги с обеих сторон + в св-вах интерфейса.
Вообще понижение MTU дает только шанс того, что будет меньше проблем с прохождением пакета из-за кривой настройки промежуточных маршрутизаторов, но если потери не зависят от размера пакета - то от изменения MTU толку 0.

abgluck
Ну я не только крипто-про снес, стояли еще компоненты от СКБ Контур, для работы с диадоком . Среди которых был компонент ComConn с комментарием что это для сетевого взаимодействия с сервером .. может быть у меня в нем дело было ...
Но пока, по прежнему ничего не упало, работает ... Так что, будем надеяться что все будет ровно ...

abgluck
Я поменял с обеих сторон, про то, что что-то нужно менять в интерфейсе - не слышал, да и не должно бы так быть, если всё в конфиге.

MikeSh2

Цитата:

The other caveat concerns MTU. On most platforms, OpenVPN programatically sets the MTU of the "tun" or "tap" interface. Currently on Windows, the only way to change the TAP-Windows MTU is to go to the adapter advanced properties and do it manually.

Рекомендую заглянуть в логи и увидеть там ругань типа
Цитата:

read from TUN/TAP [State=AT?c....More data is available.

которая говорит о том, что винда посылает на интерфейс пакеты больше чем установлено MTU тоннеля и оно их дропает.

Коллеги, появляется ли у вас такая запись в журнале TerminalServices-LocalSessionManager в момент зависания TS: Event ID 36 с одним из следующих описаний:
Произошла ошибка при переходе из DisconnectedLoggedOn в ответ на EvConnected. (Код ошибки: 0x80004005)
Произошла ошибка при переходе из CsrConnected в ответ на EvCsrInitialized. (Код ошибки: 0x80004005)

Тут якобы нашли решение проблемы в клиенте http://community.spiceworks.com/topic/558846-server-2012-r2-rds-collection-black-screen-upon-connect

abgluck - ну вот, если до удаления криптопро и компонентов контур каждый день был косяк, то сейчас - неделя, полет нормальный... Надо хотя бы месяца дождаться конечно, но что-то мне подсказывает что все будет нормально ... И если так - то вопрос очень большой к криптопро и контуру ... Придется им писать ... потому как эти системы на сервере нужны ..

ienzain
Ну вот у меня после отключения UDP-RDP тоже 2 недели полет нормальный без удаления криптопро. + выше по теме есть сообщения что и с криптопро оно полгода нормально работало пока впн не появился.
killlaw
Там другое, там 100% повторяемость проблемы, попробовал подключиться с конкретного клиента - повесил сервер (и решать ее должны явно на стороне сервера патчем а не заменой тонкого клиента), хотя корни проблемы вполне могут быть близки нашим. По логам сейчас не могу посмотреть, т.к. больше 2-х недель не храню, и старые затерлись уже, но что-то такое там было. Не факт, что это причина проблемы (получили ошибку - повисли) а не следствие (служба висит - получите ошибку).

abgluck


Цитата:

Рекомендую заглянуть в логи и увидеть там ругань типа

read from TUN/TAP  [State=AT?c....More data is available.
которая говорит о том, что винда посылает на интерфейс пакеты больше чем установлено MTU тоннеля и оно их дропает.

У меня есть только такое в файле openvpn-status.log
TAP-WIN32 driver status,"State=AT?c Err=[(null)/0] #O=2 Tx=[24682,0] Rx=[19904,0] IrpQ=[1,1,16] PktQ=[0,6,64] InjQ=[0,1,16]"
При этом линк поднят, пинги ходят.

Проблема возникает часто, сегодня 3 раза за день.

Попробую вернуть mtu обратно на 1500

abgluck
Можешь скинуть конфиги клиента и сервера?

Вчера удалил крипто про нафиг, ибо задолбало. Будем посмотреть.

Месяц аптайма без проблемы. Не знаю уж, что помогло, отключение RDP-UDP, или провайдер сеть починил. Через месяцок попробую для теста включить его обратно, посмотреть, будет отваливаться или нет.

MikeSh2
Из того, что может влиять на проблему - только
port 1194
proto udp
mssfix 1300
fragment 1360

В конфигах впн-а с момента последнего зависания ничего не менялось, т.е. эти параметры не панацея (а судя по тому, что проблема встречается и с похожими настройками ipsec vpn от cisco - она связана просто с проблемами на канале связи).

Крипто-Про не сносил. Полет нормальный, хотя лаги на канале до сих пор случаются. Делаю ставку на отключение RDP-UDP.
Также, отключил в политиках терминалки "Проверку качества соединения". Оно вряд ли повлияло, но зато пользователи быстрее к сессии подключаются.
Изменил параметр отключения RemAPP сессий. В том числе, по требованию 1С-ника. Теперь сессии RemAPP закрываются при выходе из приложения.

abgluck, ProdumAnsky

Как именно нужно отключать RDP-UDP?
Не смог найти в интернетах.

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

gpedit.msc - конфиг.комп - админ.шаблоны - компоненты windows - службы удалённых раб.столов - клиент подключения к удал. раб. столу - Отключение UDP на клиенте - Включить

Видимо оно.

Есть нюанс, у этого параметра примечание
Требование к версии : Не ниже Windows Server 8 или Windows RT

Это означает, что
1) на 7 и ниже этот параметр не подействует?
2) 7 и ниже просто не умеют RDP-UDP?
3) ничего не означает, всё нормально будет?

У меня есть клиенты и 8, и 7, и XP. Как у остальных?

7 умеет RDP-UDP если стоит соответствующий апдейт, который понимает и этот параметр. хр - не умеет в принципе. Вообще по идее достаточно на сервере отключить а клиенты и не трогать даже.

Увы и ах. Проблема проявилась через полчаса после перезагрузки сервера...