Доступ к веб-сайту с классической виртуальной машины Azure по сравнению с новой виртуальной машиной
У нас возникла проблема на нашей классической виртуальной машине 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 для сравнения выбора шифра между двумя машинами и достаточно прав, сопоставление выбора устранило проблему. Я также заметил, что Multi-Protocol Unified Hello не был выбран ни для серверного, ни для клиентского протоколов (см. Снимок экрана ниже). Было ли это частью проблемы, остается до дальнейшего тестирования и расследования.
Не совсем уверен, как это произошло, но один из коллег предположил, что изменение сертификата на стороне LinkedIn могло вызвать эту проблему.
ОБНОВЛЕНИЕ 16.07.2020 :
После некоторого дополнительного поиска, проведенного моим коллегой GW , он нашел точный шифр, который отсутствовал и требовался для успешных звонков в LinkedIn с использованием специального инструмента TLS. для отображения TLS-соединения.
Инструмент TLS можно найти здесь , а результат, показывающий шифр, использованный в вызове LinkedIn ниже ( Diffie-Hellman Ephemeral Aes256 Sha384 - TLS_DHE_RSA_WITH_GAES_25 )
Виртуальные машины (ВМ) Windows, которые вы создаете в Azure с помощью классической модели развертывания, могут автоматически обмениваться данными по каналу частной сети с другими ВМ в той же облачной службе или виртуальной сети. Однако компьютерам в Интернете или других виртуальных сетях требуются конечные точки для направления входящего сетевого трафика на виртуальную машину.
Вам необходимо будет проверить конечные точки и списки управления доступом. Некоторые документы по этому поводу представлены ниже.
Имейте в виду, что существуют технические требования к авторитетным серверам имен . Здесь также упоминается текущая проблема конфигурации, которая мешает вашей службе имен работать:
Согласованность между связующими и авторитетными данными
Для серверов имен, IP-адреса которых указаны как связующие, IP адреса должны соответствовать авторитетным записям A и AAAA для этого хост.
Вы добавили необходимые связующие записи в родительскую зону через своего регистратора, но у вас не было соответствующих записей A в самой зоне, т. е. ваша зона была Отсутствует:
ns1.example.com. IN A 51.222.30.103
ns2.example.com. IN A 51.222.30.103
Теперь есть еще одна проблема: оба указывают на один и тот же сервер. Это не нормально:
Минимальное количество серверов имен
В делегировании должно быть как минимум две записи NS, и хосты не должны разрешаться в один и тот же IP-адрес.
Разнесение сети
Серверы имен должны находиться как минимум в двух топологически разных сети. Сеть определяется как автономная система происхождения в Таблица маршрутизации BGP. Требование оценивается путем проверки представления таблицы маршрутизации BGP.
И ваш регистратор, и провайдер VPS могут предоставлять вторичные серверы имен в качестве услуги. Эту проблему следовало решить до создания собственных служб имен, но поскольку ваш регистратор уже разрешил вам использовать один и тот же IP-адрес для обоих серверов имен, у вас еще есть время исправить это впоследствии. Некоторые регистраторы проводят тесты перед тем, как разрешить изменение серверов имен. (В старые добрые времена, например, .fi органы власти были очень строги с этим, и неправильно настроенные серверы имен могли даже привести к полной отмене домена.)
Наконец, ваш SOA ] запись тоже имеет проблему. Он должен иметь действительное полное доменное имя вашего основного полномочного сервера имен ( MNAME ) и рабочий адрес электронной почты администратора, ответственного за эту зону ( RNAME ), например with (hidden)
Основная проблема здесь в том, что борьба с подделкой электронной почты - это работа и отправителя, и получателя. Если получатель принимает почту с несуществующих имен хостов, скорее всего, он также не будет проверять SPF, DKIM или DMARC. Кроме того, путь добавления этих записей был бы бесконечным, если бы они были необходимы.
DMARC
Вы утверждаете, что у вас есть полный DMARC , но p = none или даже p = quarantine не полностью обеспечивает соблюдение политик DMARC. Если вы не можете применить строгую политику для своего домена, но можете сделать это для подсистем, вам может помочь тег sp ( RFC 7489, 6.3 ).
sp: запрошенная политика получателя почты для всех поддоменов (простой текст; НЕОБЯЗАТЕЛЬНЫЙ). Указывает политику, которая должна быть применена Получателем на запрос Владельца домена. Это касается только поддоменов запрашиваемый домен, а не сам домен.Его синтаксис идентичен к тегуp, определенному выше. Если отсутствует, указанная политика тегомpДОЛЖЕН применяться для поддоменов. Обратите внимание, чтоspбудет игнорируется для записей DMARC, опубликованных на поддоменах организационной Домены из-за эффекта механизма обнаружения политик DMARC описано в Раздел 6.6.3 .
Как вы сказали, у вас есть DKIM для всех субдоменов, отправляющих почту, ваша политика может быть, например,
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; sp=reject;"
Если у вас есть несколько субдоменов, которые вы используете для отправки почты, но нельзя использовать reject , вы можете переопределить sp = reject с помощью явной менее строгой политики для субдомена:
_dmarc.no-dkim.example.com. IN TXT "v=DMARC1; p=quarantine;"
SPF
Предположим, получатель не будет принимать электронную почту от несуществующих имен хостов, как и должно быть. Поскольку SPF не наследуется, как DMARC, вам потребуется соответствующая запись SPF TXT для каждой существующей записи A . Если вы вообще не собираетесь отправлять почту с sub.example.com , это будет:
sub.example.com. IN TXT "v=spf1 -all"
Или, если бы сам хост мог отправлять почту с (скрытых)
виртуальных машин Windows (Виртуальные машины), которые вы создаете в Azure с помощью классической модели развертывания, могут автоматически обмениваться данными по каналу частной сети с другими виртуальными машинами в той же облачной службе или виртуальной сети. Однако компьютерам в Интернете или других виртуальных сетях требуются конечные точки для направления входящего сетевого трафика на виртуальную машину.
Вам необходимо будет проверить конечные точки и списки управления доступом. Некоторые документы по этому поводу представлены ниже.