Есть две локации. Между ними поднят ipsec туннель между публичными адресами, используя каналы общего пользования (Интернет). В туннеле ходит разный траффик, преимущественно VoIP и RDP.
Проблема - RDP подключения до терминальных серверов (кластер с брокером) часто (несколько раз в день для пользователя) переподключаются. Сам туннель при этом остается целым. В логах терминальных серверов возникают Event ID 4779 и 4778, разница между событиями в среднем 5-6 секунд.
Какими настройками можно сделать RDP сессию "более цепкой"? Отключать компрессию (канал позволяет) пробовал, не помогло.
PS: проблема была в другом, выношу решение из комментария, который не очень заметен:
В итоге проблема оказалась совсем в другом месте. Давным давно, мои предшественники настроили на dhcp сервере время выдачи адресов в 10 минут (много вай-фай клиентов, маленьких пул адресов). Это годами работало и особых проблем не было. Но с моим приходом стали менять архитектуру, добавили dhcp relay и пошли проблемы с RDP реконнектами. Журналы на терминальных серверах показали, что реконнекты у особенно несчастных пользователей происходят каждые 10 минут, четко (но не всех).
Оказалось, добавление relay увеличило время в пути для пакетов и стали проявляться случаи, когда у хоста уже истек лиз, и новый он ещё не получил (точнее старый адрес, но заново). Именно в эти доли секунды и происходили реконнекты, где-то чаще, где-то редко.
Ещё один фактор, который изначально мешал диагностике - проблема проявлялась только на станциях с Win7, машины с Win XP на соседних портах коммутаторов проблем не испытывали совсем.
Сейчас время лиза установил в 8 дней, проблема устранена.
А может вообще отказаться от RDP а использовать какой нить другой протокол (Насколько я знаю используется TCP протокол, может перебратся на решение на UDP)?
Maksim: да, сейчас используется TCP вариант, для UDP надо кластер на 2012 переводить, а часть клиентов- тонкие клиенты на линуксах. От RDP отказаться нельзя, есть бизнес процессы, которые сейчас менять очень дорого. В пределах офиса все работает прекрасно, проблема обострилась в связи с переводом части компетенций в регионы и ростом числа пользователей, которые ходят через интернет (внутри туннеля).
Maksim: поменять что? Есть кластер виндовых терминалов, там работает бизнес софт (1С, Консультант и прочее) и как это заменить на опенсорсное? В целом мы уходим от темы вопроса, это не предмет обсуждения. Вопрос - как в существующих условиях усилить "цепкость" RDP сессии.
Maksim: Максим, спасибо за желание помочь, но у нас есть уже весьма развитая инфраструктура, которую менять дорого и на текущий момент не имеет смысла. Есть инженерная, весьма четко сформулированная задача, по сути ни одного совета по теме не было.
В итоге проблема оказалась совсем в другом месте. Давным давно, мои предшественники настроили на dhcp сервере время выдачи адресов в 10 минут (много вай-фай клиентов, маленьких пул адресов). Это годами работало и особых проблем не было. Но с моим приходом стали менять архитектуру, добавили dhcp relay и пошли проблемы с RDP реконнектами. Журналы на терминальных серверах показали, что реконнекты у особенно несчастных пользователей происходят каждые 10 минут, четко (но не всех).
Оказалось, добавление relay увеличило время в пути для пакетов и стали проявляться случаи, когда у хоста уже истек лиз, и новый он ещё не получил (точнее старый адрес, но заново). Именно в эти доли секунды и происходили реконнекты, где-то чаще, где-то редко.
Ещё один фактор, который изначально мешал диагностике - проблема проявлялась только на станциях с Win7, машины с Win XP на соседних портах коммутаторов проблем не испытывали совсем.
Сейчас время лиза установил в 8 дней, проблема устранена.
подкрутить правильным образом mtu внутри туннеля (не физически интерфейсы), рассчитать по статье cisco, у них имеется статья. также нужно знать, что у вас по оборудованию поднимающий туннель? нужно еще смотреть в сторону приоритизации (qos), пробовали?
Сайпутдин Омаров: спасибо, mtu покручу, почитаю, это направление не потрошил совсем в контексте проблемы. Туннель держит Mikrotik CCR с обеих сторон. L2TP c IPSec шифрованием, в перспективе на GRE переход, также с шифрованием IPSec. Приоритезация на примитивном уровне делается (шейпер по протоколам с приоритетами для категорий траффика, средствами pfSense), но влияние не фиксирую, что с ней, что без неё поведение идентичное
упс- вот оно че.... а у меня клиенты OpenVPN\PPTP на Микротике тоже жалуются на обрывы, не придавал значение, но в процессе сессия работают, то все ок. в ЦО уже настроен ваш перспективный вариант, но с использованием как и было сказано Wan оптимизатора, его работа видимо и заключается с умом (в соответствии с алгоритмом) выставить приоритезацию трафика, что вам придется сделать ручками.
Вы сказали в туннеле имеется много другого, и pfSense делает qos до туннеля с обеих сторон?
В туннеле ещё Asterisk VoIP траффик, там UDP и менне критично, если пара пакетов потерялось, разрывов в разговорах нет, но буквы иногда пропадают в словах при разговорах. pfSense держит ещё один туннель (чистый IPsec в тунельном режиме), там канал слабый, поэтому голос и RDP он отдает в CCR. Прямо сейчас настроил маршрут для RDP трафика мимо pfSense, чисто CCR-CCR, все равно есть реконнекты, но пока статистики мало, чтобы сказать хуже, лучше или также. Вообще не думаю, что pfSense в этом смысле влияет, думаю дело чисто в WAN специфике, для TCP сессии критично, если потерялось что-то по дороге. Сейчас после проверки CCR-CCR схемы буду потрошить mtu, ловить wiresharkом (т.к. пока не ясно, кто инициирует реконнект, клиент или сервер), а также хочу проверить влияение уровня шифрования непосредственно RDP сессии, т.к. трафик идет уже внутри защищенного туннеля, можно и ослабить.
Сайпутдин Омаров: qos с одной стороны, он по сути шейпит траффик по приоритетам, чтобы для критичного траффика была гарантированная полоса на выход, понимаю, что это не идеальная конфигурация в общем смысле, но и не делаем на это ставку, сделано чтобы качальщики не задавали голос и RDP и в этом смысле оно работает.
у меня выдача айпи ручную прописана для Secrets account's, и за сутки может быть более двух реконектов. клиенты без шифрования пптп. этот траффик минуя ревербеда. а DHCP уменя и для меня закрыт :(
