Хорошо, у меня есть работа с нашими сетевыми инженерами, и кажется, что никто не может понять эту проблему, поэтому у меня нет вариантов, поскольку я безуспешно пытался исследовать эту проблему в Google. Итак, с учетом сказанного, вот проблема и все устранение неисправностей, которые были выполнены. (ПРИМЕЧАНИЕ. Все коммуникации осуществляются через соединение с веб-сайтом с использованием https на порту 443. Кроме того, все эти соединения поступают через внешний стирающийся URL-адрес, а затем попадают в балансировщик нагрузки Citrix, который перенаправляет соединение на соответствующий сервер. где размещается служба веб-сайта. Сервер работает под управлением Windows Server 2012 R2 вместе с IIs 8.5. Да, все привязки установлены. Кроме того, я сделал Sur ego явным образом включил TLS 1.0, 1.1 и 1.2 через реестр, чтобы убедиться, что все работало правильно.)
У меня есть соединение с сайтом другой компании, где до недавнего времени у нас не возникало никаких проблем. Изменение, которое произошло недавно, заключалось в том, что мы отключили TLS 1.0 и TLS 1.1 и включили только TLS 1.2. Как только мы это сделали, связь оборвалась. Теперь вы можете подумать, что проблема заключалась в том, что другая компания использовала более слабое соединение TLS для подключения к нам, но это оказалось неверным. Итак, первым шагом, который я сделал, было то, что моя сетевая команда снова включила обе эти версии TLS, и при запуске Wireshark Trace я смог зафиксировать успешное соединение с нашим сервером. Что странно, так это то, что соединение все время говорило и общалось по TLS 1.2. Так что это была первая часть, которая меня смутила.
Итак, следующим шагом, который мы сделали, было отключение TLS 1.1 и оставление TLS 1.0 и 1.2 включенными. После запуска еще одного Wireshark Trace мы подтвердили, что соединение все еще может быть установлено и что все коммуникации по-прежнему поддерживаются через TLS 1.2.
Следующим шагом, который мы выполнили, было отключение TLS 1.0 и повторное включение TLS 1.1, так как мы знали, что включение TLS 1.2 изначально разрывает соединение. После внесения этих изменений и запуска другого Wireshark Trace соединение не удалось.
Получив все эти журналы, я просмотрел каждый из них, чтобы посмотреть, в чем разница между всеми тремя из них. После того, как я сам много копался в них, я считаю, что, возможно, нашел проблему, но мне нужна помощь в ее подтверждении. Одна вещь, которую я заметил, никогда не происходило во время неудачных подключений, - это то, что никогда не было попыток рукопожатия на уровне сервера. Однако, когда были успешные соединения и все рукопожатия были выполнены должным образом на уровне сервера. Это привело меня к мысли, что проблема связана с рукопожатием и что оно прерывается балансировщиком нагрузки.
Я передал эту информацию своей группе инженеров сети и поговорил с ними, и они не уверены, почему включение TLS 1.0 и 1.2 и дополнительного 1.1 разрешит соединение, когда оно показывает через журналы Wireshark, что все передается через TLS 1.2. Это привело меня к просмотру некоторых комплектов шифров, которые использовались поставщиком, и комплектов шифров, утвержденных для подключений балансировщика нагрузки к моему серверу.
Покопавшись в них, я обнаружил, что набор шифров, который согласовывался каждый раз, не был одним из одобренных наборов шифров, которые были в списках балансировщиков нагрузки. Так что, честно говоря, самая большая запутывающая часть всей этой ситуации заключается в том, как можно было разрешить соединение от этой другой компании, когда TLS 1.0 включен, но все же все наборы шифров, которые они предлагают, которые они поддерживают, отсутствуют в наших утвержденных списках. Однако, когда включен только TLS 1.2, соединение с сервером никогда не устанавливается, поскольку кажется, что оно прерывается на балансировщике нагрузки.
Итак, с учетом сказанного, может ли кто-нибудь объяснить, почему включение TLS 1.0 и все же комплекты шифров не входят в список утвержденных балансировщиков нагрузки, перечисляющих wpuld, но его выключение не будет? А также, что было бы лучше всего выполнить при попытке разрешить соединение. Должны ли мы добавить только один из самых популярных наборов шифров, поддерживаемых другой компанией, в наш одобренный список и посмотреть, что будет дальше? Или есть другие вещи, на которые мы должны обратить внимание на 2 устранения неполадок и попытаться найти решение?
Спасибо всем и каждому за помощь и советы.