Проверка конфигурации HTTPS для подключенного кэша Майкрософт на Linux

В этой статье содержатся инструкции по проверке поддержки HTTPS на Подключенный кэш Майкрософт для предприятий и образовательных учреждений узлах, работающих на Linux.

Проверка загрузки содержимого HTTP и HTTPS

Перед тестированием необходимо определить, как клиенты подключаются к серверу подключенного кэша. Это тот же метод подключения, который вы настроили в альтернативном имени субъекта (SAN) сертификата во время создания CSR.

Важно.

Замените [mcc-connection] и [test-url] во всех приведенных ниже командах

Определение :[mcc-connection]

  • Если вы использовали -sanIp в CSR: используйте IP-адрес (например, 192.168.1.100).
  • Если вы использовали -sanDns в CSR: используйте имя узла (например, mcc-server.contoso.com).

[test-url]— это полный путь к тестовой Intune приложению Win32:ee344de8-d177-4720-86c1-a076581766f9/070a8fd4-79a7-42c8-b7c8-9883253bb01a/c7b1b825-88b2-4e66-9b15-ff5fe0374bc6.appxbundle.bin

Следующие команды curl проверяют получение содержимого HTTP и HTTPS:

  • Тест HTTPS:

    curl -v -o /dev/null "https://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"

    Ожидаемые успешные выходные данные:

    * Connected to [your-server] ([ip-address]) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: [your-certificate-subject]
< HTTP/1.1 200 OK
< Content-Length: [file-size]

  • HTTP-тест:

    curl -v -o /dev/null "http://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"

    Ожидаемые успешные выходные данные:

    * Connected to [your-server] ([ip-address]) port 80 (#0)
< HTTP/1.1 200 OK
< Content-Length: [file-size]

Проверка на стороне службы

Выполните следующие тесты на хост-компьютере Linux:

  • Проверьте подключение с помощью wget:

    wget --server-response --spider --header="host: swda01-mscdn.manage.microsoft.com" "https://[mcc-connection]/[test-url]"

    Ожидаемый результат:HTTP/1.1 200 OK указывает на успешное подключение ПО HTTPS.

  • Проверка сведений о сертификате:

    echo | openssl s_client -connect [mcc-connection]:443 -servername [mcc-connection] 2>/dev/null | openssl x509 -text -noout

    Ожидаемый результат: Сведения о сертификате, включая тему, издателя и значения SAN, должны соответствовать вашей конфигурации.

  • Проверьте состояние контейнера и журналы:

    # Check if the Connected Cache container is running
sudo docker ps | grep mcc

# View recent container logs for HTTPS activity
sudo docker logs --tail 50 $(sudo docker ps -q --filter ancestor=mcr.microsoft.com/mcc/linux)

    Ожидаемый результат: Контейнер должен иметь состояние "Вверх", а журналы должны отображать действия TLS/SSL без ошибок.

  • Проверка подтверждения SSL/TLS.

    Проверьте подтверждение SSL/TLS без проверки сертификата:

        # Basic connection test
    openssl s_client -connect [mcc-server]:443

    # Test with SNI (Server Name Indication)
    openssl s_client -connect [mcc-server]:443 -servername [hostname]

    # View certificate details during connection
    echo | openssl s_client -connect [mcc-server]:443 2>/dev/null | openssl x509 -noout -text

Проверка на стороне клиента

Выполните следующие команды на клиентском устройстве (а не на хост-компьютере Linux).

Условием: Убедитесь, что узел предназначен с помощью политики. Обновите IP-адрес подключенного кэша (значение политики DOCacheHost) до любого, что относится к вашей среде:

$parentKeyPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization"
if (!(Test-Path $parentKeyPath))
  {
     New-Item -Path $parentKeyPath -ItemType RegistryKey -Force -ErrorAction Stop | Out-Null
  }
Set-ItemProperty -Path $parentKeyPath -Name "DOCacheHost" -Value "[mcc-connection]" -ErrorAction Stop

  • Запросите скачивание приложения Teams из подключенного кэша по протоколу HTTPS:

    Add-AppxPackage "https://installer.teams.static.microsoft/production-windows-x64/25177.2002.3761.5185/MSTeams-x64.msix"

    Ожидаемый результат: Скачивание завершается без ошибок и должно выполняться быстрее, чем обычные загрузки через Интернет.

  • Убедитесь, что содержимое на самом деле кэшируется (а не только возвращается к CDN):

    Get-DeliveryOptimizationStatus | Select-Object DownloadMode, TotalBytesDownloaded, BytesFromCacheServer

    Ожидаемый результат:BytesFromCacheServer значение должно быть больше 0, что указывает на успешное кэширование.

  • Если подключенный кэш Linux серверных клиентах Windows, протестируйте следующие данные на этих компьютерах:

    # Test TCP connection
Test-NetConnection -ComputerName [mcc-server] -Port 443

# Test HTTPS connection
Invoke-WebRequest -Uri "https://[mcc-server]/" -UseBasicParsing

# View certificate details
$cert = [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
Invoke-WebRequest -Uri "https://[mcc-server]/"

  • Проверьте, доступен ли порт 443:

        # Using telnet
    telnet [mcc-server-ip] 443

    # Using nc (netcat)
    nc -zv [mcc-server-ip] 443

    # Using nmap (if installed)
    nmap -p 443 [mcc-server-ip]

Поиск и устранение неисправностей

Если шаг проверки завершается неудачно, используйте следующие тесты, чтобы изолировать причину. Каждый тест обходит одну часть процесса подключения. Если тест выполнен успешно, вы знаете, что проблема связана с объеденной частью.

Важно.

Замените [mcc-connection] и [test-url] во всех приведенных ниже командах

Определение :[mcc-connection]

  • Если вы использовали -sanIp в CSR: используйте IP-адрес (например, 192.168.1.100).
  • Если вы использовали -sanDns в CSR: используйте имя узла (например, mcc-server.contoso.com).

[test-url]— это полный путь к тестовой Intune приложению Win32:ee344de8-d177-4720-86c1-a076581766f9/070a8fd4-79a7-42c8-b7c8-9883253bb01a/c7b1b825-88b2-4e66-9b15-ff5fe0374bc6.appxbundle.bin

Ошибки проверки сертификатов

Симптомы:SSL certificate problemcertificate subject name does not match

Диагностический тест: Следующая команда использует флаг для полного -k пропуска проверки сертификата. Это указывает curl на подключение без проверки сертификата сервера. Таким образом, вы можете определить, в чем проблема: сертификат или что-то еще.

curl -v -k -o /dev/null "https://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"

Если тест успешно выполнен, выполните следующие действия. Сервер и сеть работают правильно. Проблема связана с самим сертификатом. Убедитесь, что:

  • Конфигурация SAN соответствует методу подключения (IP-адрес или имя узла)
  • Корневой сертификат ЦС устанавливается в доверенном хранилище клиента

Если тест завершается сбоем: Проблема не связана с сертификатом. См. сведения об ошибках подключения ниже.

Ошибки отзыва сертификатов

Симптомы: Медленные ответы HTTPS или тайм-ауты

Диагностический тест: Следующая команда использует флаг для --ssl-no-revoke пропуска проверки списка отзыва сертификатов (CRL). Как правило, клиент обращается к точке распространения CRL ЦС, чтобы убедиться, что сертификат не был отозван. Если эта конечная точка недоступна, это приводит к задержке или истечению времени ожидания.

curl -v --ssl-no-revoke -o /dev/null "https://[mcc-connection]/[test-url]" --include -H "host:swda01-mscdn.manage.microsoft.com"

Если тест успешно выполнен, выполните следующие действия. Подключение работает, когда проверка отзыва пропущена, что подтверждает, что клиент не может связаться с точкой распространения CRL. Убедитесь, что брандмауэр разрешает доступ к URL-адресам отзыва сертификатов, перечисленным в сертификате.

Если тест завершается сбоем: Проблема не является проверкой отзыва. См. сведения об ошибках подключения ниже.

Ошибки подключения

Симптомы:Connection refusedCould not resolve host

Если не удается подключиться (в отличие от подключения, но возникают ошибки сертификата), проблема обычно связана с сетью или брандмауэром.

Для ошибок подключения HTTPS:

  • Проверка правильной настройки правил брандмауэра

  • Убедитесь, что ни один из других служб не использует порт 443:

    sudo ss -tulpn | grep :443

  • Убедитесь, что контейнер Подключенного кэша работает:

    sudo docker ps | grep mcc

Для ошибок http-подключения: Убедитесь, что служба подключенного кэша запущена и доступен порт 80.

sudo ss -tulpn | grep :80

Для устранения проблем с DNS: Проверка разрешения имен узлов и сетевого подключения

nslookup [mcc-connection]
# OR
dig [mcc-connection]

Вмешательство корпоративного прокси-сервера

Симптомы: Проверка сертификата завершается ошибкой, несмотря на правильную конфигурацию.

Решение: Убедитесь, что корпоративный прокси-сервер не перехватывает трафик HTTPS на сервер подключенного кэша. Рассмотрите возможность отключения проверки TLS для внутреннего трафика подключенного кэша.

Дополнительные ресурсы

  • Last updated on