Жила-была настроенная, проверенная, но не введенная в боевой режим ферма шлюзов удаленного доступа на базе Windows Server 2012R2, с настроенным NLB. Через неё пользователи изредка подключались к некоторым серверам RDSH внутри сети, всё было нормально, как вдруг начали из ниоткуда прилетать сообщения "Не работает!"
Пошли проверять. Два сервера, с адресами 10.х.х.6 и 10.х.х.7, настроенный кластер NLB с адресом 10.х.х.5, сами по себе работают, NLB тоже работает, поскольку активные соединения есть на обоих узлах. Проверяю с тестового узла, на котором 2012R2 — действительно, ошибка есть, причем появляется почти сразу после подключения. В логах роли RDG ошибка 210 от источника TerminalServices-Gateway "Http transport: IN channel could not find a corresponding OUT channel". Делаю вывод, что разъехался NLB. Чтение документации по NLB показывает, что настройки правильные:
Однако, раз ошибка прямо связана с NLB, значит, что-то здесь не так. Вначале делаю попытку перенастроить кластер в multicast — получаю полную недоступность фермы как целого, как следствие разрыв имеющихся соединений, благо к тому времени ни одного активного пользователя на ферме уже не было. Откатываю изменение. Потом включаю timeout на правилах NLB port rules, которого изначально не было — соединение устанавливается, но через таймаут падает снова, с той же самой ошибкой.
Ушел читать мануал по RDP-протоколу. Вычитал, что в случае использования RDP 8.1 клиент пытается использовать UDP помимо TCP для передачи данных, клиенты RDP 7.0 или старше используют протокол RPC over HTTP для работы со шлюзом. Старый протокол создавал одно соединение, а новый — уже три. Так, думаю, значит, проблема где-то в настройках affinity в NLB. Обходное решение, например, не принимать подключения по UDP, решил не применять — во-первых, нелогично, во-вторых, решение имеет ещё и клиентскую часть, а исправлять серверные проблемы за счет клиента в корне неправильно.
Ушел читать мануал по NLB. Описание старое, ещё под Windows 2000 Server, но основные принципы с тех пор не менялись, хотя детали могли и отличаться. В процессе чтения нахожу интересную фразу — "по умолчанию создается одно правило для балансировки всего трафика, приходящего на сервер". А что, если вместе с политикой работы NLA с сертификатами Микрософт поменяла и политику балансировки, сделав её различной по каждому правилу? Перенастроил правила NLB так, чтобы одно правило покрывало оба порта сразу. Проверка идет уже второй день, и ни единого разрыва (с).
Мораль — обновил фичу, обнови доки тестирование на совместимость надо проводить везде, особенно, если выполняется переход на новую операционную систему. Никогда не знаешь, где и что может сломаться.
Автор: Бог сервера
