Доступ к веб-сайту с виртуальной машины Azure Classic по сравнению с новой виртуальной машиной
У нас возникла проблема с нашим классический Виртуальная машина Azure под управлением Windows Server 2012 R2 при доступе www.linked.com.
У нас есть некоторые приложения, работающие на IIS и общающиеся с LinkedIn OAuth API, и именно здесь мы заметили проблему. Но просто пытаясь получить доступ www.linkedin.com в IE получаем следующее:
В приложении .NET возникает следующая ошибка:
Мы просмотрели множество интернет-ресурсов, связанных с изменением ключей реестра, применением обновлений и т. Д., Но безуспешно. Мы обнаружили, что доступ к тому же сайту на Новый тип виртуальной машины Azure, размещенной в том же регионе, совсем не проблема. Те же настройки реестра, те же настройки безопасности IE, но классическая виртуальная машина по-прежнему отказывается открывать сайт.
Похоже, что компонент, расположенный над классической виртуальной машиной, неправильно обрабатывает сетевые запросы. Это началось только в последние несколько дней, так как раньше это работало абсолютно нормально.
Другие веб-сайты с поддержкой TLS 1.2, такие как Google или Office365, открываются без проблем на любой из виртуальных машин.
Любые предложения, идеи - очень признательны.
Что была предпринята для устранения проблемы:
- Следуйте инструкциям в окне ошибки IE.
- Используемый IISCrypto для подтверждения настроек TLS.
- Предлагаются обновленные / проверенные параметры реестра Windows Вот и Вот (а также другие сайты, предлагающие похожие вещи).
- В основном пытался найти разницу между классическими и новыми виртуальными машинами типа Azure при отправке сетевого запроса с помощью WireShark и некоторых других инструментов.
Вот вывод Wireshark запроса, сделанного из нового типа виртуальной машины (где IE не имеет проблем с открытием linkedin.com) (снимок экрана включает содержимое TLS ClientHello).
А вот такой же запрос в классической ВМ
Не на 100% уверен, что это мне говорит, но, возможно, кому-то поможет, когда они поделятся своими мыслями.
Во-первых, следуйте инструкциям по включению TLS 1.2. Веб-сайт LinkedIn теперь требует TLS 1.2 и не принимает более старую версию TLS или SSL.
Покопавшись еще в двух захватах Wireshark (один с рабочего сервера и один, на котором возникает проблема), я обнаружил, что на этапе запроса Client Hello было отправлено другое количество шифров, см. Снимок экрана Вот (левая классическая ВМ, правая новая ВМ). я использовал IISCrypto инструмент для сравнения выбора шифра между двумя машинами и достаточно правильного сопоставления выбора устранил проблему. Я также заметил, что Многопротокольный унифицированный привет не был выбран ни для серверного, ни для клиентского протоколов (см. снимок экрана ниже). Было ли это частью проблемы, остается до дальнейшего тестирования и расследования.
Не совсем уверен, как это произошло, но один из коллег предположил, что изменение сертификата на стороне LinkedIn могло вызвать эту проблему.
ОБНОВЛЕНИЕ 16.07.2020:
После некоторых дополнительных копаний моим коллегой ГВт, он нашел точный шифр, который отсутствовал и требовался для успешных звонков в LinkedIn с использованием специального инструмента TLS для отображения TLS-соединения.
Инструмент TLS можно найти Вот и результат, показывающий шифр, использованный при вызове LinkedIn ниже (Эфемерный Aes256 Sha384 Диффи-Хеллмана - TLS_DHE_RSA_WITH_AES_256_GCM_SHA384)
Виртуальные машины Windows (ВМ), которые вы создаете в Azure с помощью классической модели развертывания, могут автоматически обмениваться данными по каналу частной сети с другими ВМ в той же облачной службе или виртуальной сети. Однако компьютерам в Интернете или других виртуальных сетях требуются конечные точки для направления входящего сетевого трафика на виртуальную машину.
Вам нужно будет проверить конечные точки и ACL. Некоторые документы по этому поводу белво.
Насколько мне известно, исходящий сетевой трафик работает одинаково для классических виртуальных машин и виртуальных машин ARM: трафик просто преобразуется через NAT, нет прокси или чего-либо еще, проверяющего его (если вы специально не развернете такое решение).
Ошибка, похоже, связана с TLS, что подтверждает, что ваша виртуальная машина действительно может подключиться к LinkedIn на сетевом уровне: она просто не может успешно согласовать с ней сеанс TLS.
Я бы еще раз проверил настройки TLS на затронутой виртуальной машине, а также дважды проверил, может ли она успешно получить доступ к другим веб-сайтам, требующим TLS 1.2 (например, к службам Office 365 или Azure).
Также обратите внимание, что если вы развернете новый Виртуальная машина Windows Server 2012 R2 в Azure (ARM) будет использовать более свежий образ ОС, который уже будет включать поддержку TLS 1.2; это может быть не так для старой виртуальной машины, которая некоторое время работала в Azure Classic.