Поделиться через

Необходимые компоненты для Microsoft Tunnel в Intune

  • Статья

Перед установкой VPN-шлюза Microsoft Tunnel для Microsoft Intune ознакомьтесь с предварительными условиями и настройте их. Перечень необходимых компонентов включает сервер Linux, на котором работают контейнеры для размещения программного обеспечения сервера Tunnel. Кроме того, запланируйте настройку сети, брандмауэров и прокси-серверов для поддержки обмена данными для Microsoft Tunnel.

На высоком уровне Microsoft Tunnel требуется:

  • Подписка на Azure.

  • Подписка На Microsoft Intune (план 1 ).

  • Сервер Linux, на котором работают контейнеры. Сервер может быть локальным или облачным и поддерживает один из следующих типов контейнеров:

    • Podman для Red Hat Enterprise Linux (RHEL). См. требования к серверу Linux .
    • Docker для всех остальных дистрибутивов Linux.

  • Сертификат TLS для сервера Linux для защиты подключений устройств к серверу шлюза Microsoft Tunnel.

  • Устройства под управлением Android либо iOS или iPadOS.

После настройки предварительных требований рекомендуется запустить средство подготовки , чтобы убедиться, что среда настроена для успешной установки.

В следующих разделах подробно описаны необходимые компоненты для Microsoft Tunnel и даны рекомендации по использованию средства проверки готовности.

Примечание.

Туннель и глобальный безопасный доступ (GSA) нельзя использовать одновременно на одном устройстве.

Сервер Linux

Настройте виртуальную машину под управлением Linux или физический сервер, на котором будет установлен шлюз Microsoft Tunnel.

Примечание.

Поддерживаются только версии операционных систем и контейнеров, перечисленные в следующей таблице. Не указанные версии не поддерживаются. Новые версии добавляются в этот список только после тестирования и подтверждения возможности поддержки. Также обновляйте ОС с помощью обновлений для системы безопасности.

  • Поддерживаемые дистрибутивы Linux. В таблице ниже указано, какие версии Linux поддерживаются для сервера Tunnel, а также необходимый для них контейнер.

    Версия распределения Требования к контейнеру Рекомендации
    CentOS 7.4 и более поздних версий Docker CE Поддержка заканчивается в июне 2024 г. CentOS 8+ не поддерживается
    Red Hat (RHEL) 7.4 и более поздних версий Docker CE Поддержка заканчивается июня 2024 г.
    Red Hat (RHEL) 8.6 Поддержка Podman 4.0 (по умолчанию)
    заканчивается июня 2024 г.    		 Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel.

    Контейнеры, созданные Podman версии 3 и более ранних версий , недоступны для использования с Podman версии 4.0. При обновлении и изменении контейнеров с версии 3 до версии 4.0 запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
    Red Hat (RHEL) 8.7 Podman 4.2 (по умолчанию) Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel.

    Контейнеры, созданные Podman версии 3 и более ранних версий , не поддерживаются в Podman версии 4.2 и более поздних версий. При обновлении и изменении контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
    Red Hat (RHEL) 8.8 Podman 4.4.1 Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel.

    Контейнеры, созданные Podman версии 3 и более ранних версий , не поддерживаются в Podman версии 4.2 и более поздних версий. При обновлении и изменении контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
    Red Hat (RHEL) 8.9 Podman 4.4.1 Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel.

    Контейнеры, созданные Podman версии 3 и более ранних версий , не поддерживаются в Podman версии 4.2 и более поздних версий. При обновлении и изменении контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
    Red Hat (RHEL) 9.0 Поддержка Podman 4.4.1 (по умолчанию) заканчивается июня 2024 г. Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel.

    Контейнеры, созданные Podman версии 3 и более ранних версий , не поддерживаются в Podman версии 4.2 и более поздних версий. При обновлении и изменении контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.

    Поддержка заканчивается в феврале 2024 г.
    Red Hat (RHEL) 9.1 Podman 4.4.1 (по умолчанию) Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel.

    Контейнеры, созданные Podman версии 3 и более ранних версий , не поддерживаются в Podman версии 4.2 и более поздних версий. При обновлении и изменении контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
    Red Hat (RHEL) 9.2 Podman 4.4.1 (по умолчанию) Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel.

    Контейнеры, созданные Podman версии 3 и более ранних версий , не поддерживаются в Podman версии 4.2 и более поздних версий. При обновлении и изменении контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
    Red Hat (RHEL) 9.3 Podman 4.6.1. (по умолчанию) Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel.

    Контейнеры, созданные Podman версии 3 и более ранних версий , не поддерживаются в Podman версии 4.2 и более поздних версий. При обновлении и изменении контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
    Red Hat (RHEL) 9.4 Podman 4.9.4-rhel (по умолчанию) Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel.

    Контейнеры, созданные Podman версии 3 и более ранних версий , не поддерживаются в Podman версии 4.2 и более поздних версий. При обновлении и изменении контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
    Ubuntu 20.04 Docker CE
    Ubuntu 22.04 Docker CE

    Важно!

    В апреле 2023 года Ubuntu прекратит поддержку Ubuntu 18.04. С прекращением поддержки Ubuntu Intune также прекратит поддержку Ubuntu 18.04 для использования с Microsoft Tunnel. Дополнительные сведения см. в статье https://wiki.ubuntu.com/Releases.

  • Конфигурация сервера Linux: используйте приведенные ниже рекомендации, чтобы выбрать нужную вам конфигурацию.

    Количество устройств Количество ЦП Объем памяти (ГБ) Количество серверов Количество сайтов Дисковое пространство (ГБ)
    1 000 4 4 1 1 30
    2,000 4 4 1 1 30
    5,000 8 8 2 1 30
    10,000 8 8 3 1 30
    20,000 8 8 4 1 30
    40 000 8 8 8 1 30

    Поддержка масштабируется линейно. Каждый экземпляр Microsoft Tunnel поддерживает до 64 000 одновременных подключений, но при этом отдельные устройства могут создавать по несколько подключений.

  • ЦП: 64-разрядный процессор AMD или Intel.

  • Установите Docker CE или Podman. В зависимости от версии Linux, используемой для сервера Tunnel, установите на сервере одно из следующих компонентов:

    • Docker версии 19.03 CE или более поздней.
    • Podman версии 3.0 или 4.0 в зависимости от версии RHEL.

    Для работы Microsoft Tunnel требуется Docker или Podman на сервере Linux для поддержки контейнеров. Контейнеры обеспечивают целостную среду выполнения, мониторинг работоспособности и предупредительные меры, а также удобство обновления.

    Сведения об установке и настройке Docker или Podman см. в указанных ниже разделах.

    • Установите подсистему Docker в CentOS или Red Hat Enterprise Linux 7.

      Примечание.

      По приведенной выше ссылке можно перейти на страницу инструкций по установке и скачивания CentOS. Эти же инструкции можно использовать для RHEL 7.4. Версия, установленная в RHEL 7.4 по умолчанию, слишком стара для поддержки шлюза Microsoft Tunnel.

    • Установите подсистему Docker в Ubuntu.

    • Установите Podman в Red Hat Enterprise Linux 8.4 и более поздних версий (прокрутите вниз до RHEL8).

      Эти версии RHEL не поддерживают Docker. Вместо этого эти версии используют Podman, а podman является частью модуля под названием "container-tools". В этом контексте модуль — это набор RPM-пакетов, которые представляют компонент и обычно устанавливаются вместе. Типовой модуль содержит пакеты с приложением, пакеты с библиотеками зависимостей для приложения, пакеты с документацией для приложения и пакеты с дополнительными служебными программами. Дополнительные сведения см. в статье Общие сведения о модулях в документации по Red Hat.

      Примечание.

      Podman без корней. Microsoft Tunnel поддерживает использование контейнера Podman без корней.

      Для использования podman без корней требуются дополнительные предварительные требования , описанные в этой статье, а также использование измененной командной строки при запуске сценария установки Tunnel. Дополнительные сведения о дополнительных предварительных требованиях и командной строке установки см. в статье Использование контейнера Podman без корнейв статье Настройка Microsoft Tunnel для Intune .

  • Сертификат TLS: серверу Linux требуется надежный сертификат TLS для защиты подключения между устройствами и сервером Tunnel шлюза. Во время установки шлюза tunnel вы добавляете на сервер сертификат TLS и цепочку полных доверенных сертификатов.

    • Альтернативное имя субъекта (SAN) сертификата TLS, используемое для защиты конечной точки шлюза Microsoft Tunnel, должно соответствовать IP-адресу или полному доменному имени сервера шлюза Microsoft Tunnel.

    • Срок действия сертификата TLS не может превышать двух лет. Если дата превышает два года, она не принимается на устройствах iOS.

    • Поддержка подстановочных знаков ограничена. Например, поддерживается *.contoso.com , но cont*.com не поддерживается.

    • Во время установки сервера шлюза туннеля вы должны скопировать всю цепочку доверенных сертификатов на свой сервер Linux. Скрипт установки указывает место для копирования файлов сертификатов и предлагает вам это сделать.

    • Если вы используете сертификат TLS, который не является общедоступным доверенным, необходимо отправить всю цепочку доверия на устройства с помощью профиля доверенного сертификата Intune.

    • Сертификат TLS может быть в формате PEM или pfx.

    • Чтобы поддержать проверку работоспособности отзыва tls-сертификата , убедитесь, что с сервера доступен адрес протокола OCSP или списка отзыва сертификатов (CRL), определенный сертификатом TLS.

  • Версия TLS: по умолчанию для подключений между клиентами и серверами Microsoft Tunnel используется TLS 1.3. Если TLS 1.3 недоступен, подключение может вернуться к использованию TLS 1.2.

Сеть моста по умолчанию

Контейнеры Podman и Docker используют сеть моста для перенаправления трафика через узел Linux. Если сеть моста контейнеров конфликтует с корпоративной сетью, шлюз туннеля не может успешно направить трафик в ту же корпоративную сеть.

Сети моста по умолчанию:

  • Docker: 172.17.0.0/16
  • Podman: 10.88.0.0/16

Чтобы избежать конфликтов, можно перенастроить Podman и Docker на использование сети моста, который вы указали.

Важно!

Перед изменением конфигурации сети моста необходимо установить сервер шлюза туннеля.

Изменение сети моста по умолчанию, используемой Docker

Docker использует файл /etc/docker/daemon.json для настройки нового IP-адреса моста по умолчанию. В файле IP-адрес моста должен быть указан в нотации CIDR (бесклассовая междоменная маршрутизация). Это компактный способ представления IP-адреса вместе со связанной маской подсети и префиксом маршрутизации.

Важно!

В качестве примера используется IP-адрес, используемый в следующих шагах. Убедитесь, что IP-адрес, который вы используете, не конфликтует с корпоративной сетью.

  1. Чтобы остановить контейнер шлюза туннеля MS, используйте следующую команду: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. Затем запустите следующую команду, чтобы удалить существующее устройство моста Docker: sudo ip link del docker0

  3. Если файл /etc/docker/daemon.json присутствует на сервере, используйте редактор файлов, например vi или nano для изменения файла. Запустите редактор файлов с разрешениями корня или sudo:

    • Если запись "bip": присутствует с IP-адресом, измените ее, добавив новый IP-адрес в нотации CIDR.
    • Если запись "bip": отсутствует, необходимо добавить значение "bip": и новый IP-адрес в нотации CIDR.

    В следующем примере показана структура файла daemon.json с обновленной записью "bip": с измененным IP-адресом "192.168.128.1/24".

    Пример daemon.json:

    {
"bip": "192.168.128.1/24"
}

  4. Если файл /etc/docker/daemon.json отсутствует на сервере, выполните команду, аналогичную приведенному в следующем примере, чтобы создать файл и определить IP-адрес моста, который вы хотите использовать.

    Пример: sudo echo '{ "bip":"192.168.128.1/24" }' > /etc/docker/daemon.json

  5. Чтобы запустить контейнер шлюза туннеля MS, используйте следующую команду: sudo mst-cli agent start ; sudo mst-cli server start

Дополнительные сведения см. в статье Использование сетей моста в документации Docker.

Изменение сети моста по умолчанию, используемой Podman

Для настройки нового IP-адреса моста по умолчанию Podman использует файл /etc/cni/net.d as 87-podman-bridge.conflist.

  1. Чтобы остановить контейнер шлюза туннеля MS, используйте следующую команду: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. Затем запустите следующую команду, чтобы удалить существующее устройство моста Podman: sudo ip link del cni-podman0

  3. С помощью корневых разрешений и редактора файлов, например vi или nano, измените /etc/cni/net.d как 87-podman-bridge.conflist , чтобы обновить значения по умолчанию для "subnet:" и "gateway:" , заменив значения podman по умолчанию нужными адресами подсети и шлюза. Адрес подсети должен быть указан в нотации CIDR.

    Стандартные значения в Podman:

    • subnet: 10.88.0.0/16
    • gateway: 10.88.0.1

  4. Чтобы снова запустить контейнер шлюза туннеля MS, используйте следующую команду: sudo mst-cli agent start ; sudo mst-cli server start

Дополнительные сведения см. в статье Настройка сетевых возможностей контейнеров с помощью Podman в документации Red Hat.

Сеть

  • Включить пересылку пакетов для IPv4: на каждом сервере Linux, на котором размещено программное обеспечение сервера Tunnel, должна быть включена IP-пересылка для IPv4. Чтобы проверить состояние IP-пересылки, на сервере выполните одну из следующих универсальных команд, таких как root или sudo. Обе команды возвращают значение 0 для невключенной и значение 1 для включенной:

    • sysctl net.ipv4.ip_forward
    • cat /proc/sys/net/ipv4/ip_forward

    Если IP-пересылка не включена, можно временно включить IP-пересылку, выполнив одну из следующих универсальных команд таких как root или sudo на сервере. Эти команды могут изменить конфигурацию IP-пересылки, пока сервер не будет перезагружен. После перезагрузки сервер возвращает поведение IP-пересылки в предыдущее состояние. Для обеих команд используйте значение 1, чтобы включить пересылку. Значение 0 отключает пересылку. В следующих примерах команд для включения пересылки используется значение 1.

    • sysctl -w net.ipv4.ip_forward=1
    • echo 1 > /proc/sys/net/ipv4/ip_forward

    Чтобы обеспечить постоянную IP-пересылку, на каждом сервере Linux измените файл /etc/sysctl.conf и удалите начальный хэштег (#) из #net.ipv4.ip_forward=1, чтобы включить пересылку пакетов. После внесения изменений запись должна выглядеть следующим образом:

    # Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

    Чтобы это изменение вступило в силу, необходимо перезапустить сервер или выполнить команду sysctl -p.

    Если ожидаемая запись отсутствует в файле sysctl.conf, обратитесь к документации по распространению, используемому для включения IP-пересылки. Как правило, можно изменить sysctl.conf, чтобы добавить недостающую строку в конец файла для включения постоянной IP-пересылки.

  • Настройка нескольких сетевых адаптеров на сервер(необязательно). Мы рекомендуем использовать два контроллера сетевого интерфейса (NIC) на сервер Linux, чтобы повысить производительность, хотя два из них являются необязательными.

    • NIC 1 — эта сетевая карта обрабатывает трафик с ваших управляемых устройств. Она должна находиться в общедоступной сети и иметь общедоступный IP-адрес.  Этот IP-адрес нужно настроить в разделе Конфигурация сайта. Этот адрес может представлять отдельный сервер или подсистему балансировки нагрузки.

    • NIC 2 — эта сетевая карта обрабатывает трафик к вашим локальным ресурсам и должна находиться в вашей частной внутренней сети без сетевой сегментации.

  • Убедиться, что облачные виртуальные машины Linux имеют доступ к локальной сети. Если в качестве сервера Linux вы используете виртуальную машину в облаке, убедитесь, что сервер имеет доступ к вашей локальной сети. Например, если виртуальная машина работает в Azure, вы можете предоставлять доступ с помощью Azure ExpressRoute или другого подобного решения. Если ваш сервер работает на локальной виртуальной машине, Azure ExpressRoute не требуется.

  • Подсистемы балансировки нагрузки(необязательно).Если вы решили добавить подсистему балансировки нагрузки, обратитесь к документации по поставщикам для получения сведений о конфигурации. Обратите внимание на сетевой трафик и порты брандмауэра, относящиеся к Intune и Microsoft Tunnel.

    Сервер туннеля отвечает на запросы GET статической страницей. Ответ используется в качестве пробы подсистемой балансировки нагрузки для проверки активности сервера Tunnel. Ответ является статическим и не содержит конфиденциальной информации.

  • Поддержка VPN-подключений и доменов верхнего уровня для каждого приложения . Использование vpn для каждого приложения с внутренним использованием локальных доменов верхнего уровня не поддерживается Microsoft Tunnel.

Брандмауэр

По умолчанию Microsoft Tunnel и сервер используют следующие порты.

Входящие порты:

  • TCP 443 — требуется для Microsoft Tunnel;
  • UDP 443 — требуется для Microsoft Tunnel;
  • TCP 22 — дополнительный, используется для взаимодействия с сервером Linux по протоколу SSH/SCP.

Исходящие порты:

  • TCP 443 — требуется для доступа к службам Intune. Необходим, чтобы Docker или Podman могли получать образы.

При создании конфигурации сервера для туннеля вместо порта 443 по умолчанию можно указать другой порт. Если вы укажете другой порт, настройте брандмауэры в соответствии с используемой вами конфигурацией.

Дополнительные требования:

  • Чтобы получить доступ к службе маркеров безопасности и службе хранилища Azure для журналов, предоставьте доступ к следующим FQDN:

    • Служба маркеров безопасности: *.sts.windows.net
    • Служба хранилища Azure для журналов туннеля: *.blob.core.windows.net
    • Другие URL-адреса конечных точек хранилища: *.blob.storage.azure.net

  • Туннель использует те же требования, что и сетевые конечные точки для Microsoft Intune, с добавлением порта TCP 22 и graph.microsoft.com.

  • Настройте правила брандмауэра для поддержки конфигураций, описанных в разделе Настройка правил брандмауэра клиента Microsoft Artifact Registry (MAR).

Прокси-сервер

Вы можете использовать прокси-сервер совместно с Microsoft Tunnel.

Примечание.

Конфигурации прокси-сервера не поддерживаются в версиях Android до версии 10. Дополнительные сведения см. в статье VpnService.Builder в документации для разработчиков Android.

Примечание.

Убедитесь, что бизнес-приложения Android поддерживают прямую настройку прокси-сервера или прокси-сервера (PAC) для MDM и MAM.

Примечание.

Известная проблема. Пользователи, которые пытаются войти в Edge с помощью личных или корпоративных учетных записей, могут столкнуться с проблемами при настройке автоматической настройки прокси-сервера (PAC). В этом сценарии процесс входа может завершиться ошибкой, что не позволит пользователю получить доступ к внутренним ресурсам.

Обходные решения. Чтобы устранить эту проблему, Microsoft Tunnel предлагает раздельное туннелирование в качестве варианта. Разделение туннелирования позволяет пользователям включать только маршруты, для которых требуется прокси-сервер, при этом исключается серверы входа и пути проверки подлинности из маршрутизации через туннель. Это решение гарантирует, что на процесс входа не влияет конфигурация PAC, что позволяет пользователю получать доступ к внутренним ресурсам и просматривать Интернет.

Прямой прокси-сервер также является вариантом без раздельного туннелирования для входа в Edge с помощью корпоративных учетных записей. Это включает настройку Microsoft Tunnel для использования прямого прокси-сервера вместо URL-адреса PAC.

Если вход пользователя в Edge не требуется, то PAC поддерживает обычный просмотр и доступ к внутренним ресурсам.

Используя приведенные ниже рекомендации, вы сможете настроить сервер Linux и свою среду.

Настройка исходящего прокси-сервера для Docker

  • Если вы применяете внутренний прокси-сервер, может потребоваться настроить узел Linux для использования вашего прокси-сервера с помощью переменных среды. Чтобы использовать эти переменные, отредактируйте файл /etc/environment на сервере Linux, добавив в него следующие строки:

    http_proxy=[address]
    https_proxy=[address]

  • Прокси-серверы, прошедшие проверку подлинности, не поддерживаются.

  • Прокси-сервер не может выполнить прерывание и проверку, так как сервер Linux использует взаимную проверку подлинности TLS при подключении к Intune.

  • Настройте Docker таким образом, чтобы он использовал прокси-сервер при получении образов. Для этого отредактируйте файл /etc/systemd/system/docker.service.d/http-proxy.conf на сервере Linux, добавив в него следующие строки:

    [Service]
Environment="HTTP_PROXY=http://your.proxy:8080/"
Environment="HTTPS_PROXY=https://your.proxy:8080/"
Environment="NO_PROXY=127.0.0.1,localhost"

    Примечание.

    Microsoft Tunnel не поддерживает прокси приложения Microsoft Entra или аналогичные прокси-решения.

Настройка исходящего прокси-сервера для Podman

Следующие сведения помогут настроить внутренний прокси-сервер при использовании Podman:

  • Прокси-серверы, прошедшие проверку подлинности, не поддерживаются.

  • Прокси-сервер не может выполнить прерывание и проверку, так как сервер Linux использует взаимную проверку подлинности TLS при подключении к Intune.

  • Podman считывает сведения прокси-сервера HTTP, хранящиеся в файле /etc/profile.d/http_proxy.sh. Если этого файла нет на вашем сервере, создайте его. Измените файл http_proxy.sh и добавьте в него две указанные ниже строки. В приведенных ниже строках адрес 10.10.10.1:3128 — пример записи "адрес:порт". Добавляя эти строки, замените выражение 10.10.10.1:3128 значением адрес:порт для IP-адреса вашего сервера:

    export HTTP_PROXY=http://10.10.10.1:3128
    export HTTPS_PROXY=http://10.10.10.1:3128

    Если у вас есть доступ к порталу Red Hat для клиентов, прочитайте статью базы знаний, связанную с этим решением. См. статью Настройка переменных прокси-сервера HTTP для Podman — портал Red Hat для клиентов.

  • При добавлении этих двух строк в http_proxy.sh перед установкой шлюза Microsoft Tunnel Gateway путем выполнения mstunnel-setup скрипт автоматически настраивает переменные среды прокси-сервера шлюза Туннеля в /etc/mstunnel/env.sh.

    Чтобы настроить прокси-сервер после завершения настройки шлюза Microsoft Tunnel, выполните следующие действия.

    1. Измените или создайте файл /etc/profile.d/http_proxy.sh и добавьте в него две строки из предыдущего пункта списка.

    2. Измените файл /etc/mstunnel/env.sh и добавьте в его конец две указанные ниже строки. Как и в предыдущих строках, замените пример address:portзначением 10.10.10.1:3128 значениями ip-адреса прокси:port:

      HTTP_PROXY=http://10.10.10.1:3128
      HTTPS_PROXY=http://10.10.10.1:3128

    3. Перезапустите шлюз Tunnel: выполните команду mst-cli server restart

    Помните, что в RHEL используется SELinux. Поскольку прокси-сервер, который не работает на порту SELinux для http_port_t, может потребовать дополнительной настройки, проверьте использование управляемых портов SELinux для http. Чтобы просмотреть конфигурации, выполните следующую команду: sudo semanage port -l | grep "http_port_t"

    Пример результатов команды проверки портов. В этом примере прокси-сервер использует порт 3128, которого нет в списке:

    Снимок экрана, на котором показаны результаты проверки порта.

    • Если ваш прокси работает на одном из портов SELinux для http_port_t, вы можете продолжить процесс установки Tunnel Gateway.

    • Если прокси-сервер не работает на порту SELinux для http_port_t , как показано в предыдущем примере, необходимо выполнить дополнительные настройки.

      Если прокси-порт не указан дляhttp_port_t, проверьте, используется ли прокси-порт другой службой. Используйте команду semanage , чтобы сначала проверить порт, используемый прокси-сервером, а затем при необходимости изменить его. Чтобы проверить порт, используемый вашим прокси-сервером, выполните следующую команду: sudo semanage port -l | grep "your proxy port"

      Пример результатов проверки службы, которая может использовать порт:

      Снимок экрана, на котором показаны результаты проверки службы.

      • В этом примере нужный нам порт (3128) используется службой squid, которая представляет собой службу прокси-сервера OSS. Политики SELinux для прокси-сервера Squid входят в состав многих распространенных дистрибутивов. Так как служба squid использует порт 3128 (порт, используемый в нашем примере), необходимо изменить порты http_port_t и добавить порт 3128, который необходимо разрешить с помощью SELinux, для прокси-сервера, используемого Tunnel. Чтобы изменить порядок использования порта, выполните следующую команду: sudo semanage port -m -t http_port_t -p tcp "your proxy port"

        Пример команды изменения порта:

        Снимок экрана: пример команды изменения порта.

        После выполнения команды изменения порта выполните следующую команду, чтобы проверить, используется ли порт другой службой: sudo semanage port -l | grep "your proxy port"

        Пример команды проверки порта после изменения порта:

        Снимок экрана с процессом проверки порта после внесения изменений.

        В этом примере порт 3128 теперь связан и с http_port-t, и с squid_port_t. Это ожидаемый результат. Если порта вашего прокси-сервера нет в списке при выполнении команды sudo semanage port -l | grep "your_proxy_port", еще раз выполните команду изменения порта, но в этот раз замените параметр -m в команде semanage на параметр -a: sudo semanage port -a -t http_port_t -p tcp "your proxy port"

Настройка Podman для загрузки обновлений образа с помощью прокси-сервера

Вы можете настроить Podman, чтобы использовать прокси-сервер для скачивания (вытягивания) обновленных образов для Podman:

  1. На сервере туннеля используйте командную строку, чтобы запустить следующую команду, чтобы открыть редактор для файла переопределения для службы Microsoft Tunnel:

    systemctl edit --force mstunnel_monitor

  2. Добавьте в файл следующие четыре строки. Замените каждый экземпляр [address] адресом или адресом прокси-сервера, а затем сохраните файл:

    [Service]
Environment="http_proxy=[address]"
Environment="https_proxy=[address]"

  3. Затем выполните в командной строке следующую команду:

    systemctl restart mstunnel_monitor

  4. Наконец, выполните в командной строке следующую команду, чтобы убедиться, что конфигурация выполнена успешно:

    systemctl show mstunnel_monitor | grep http_proxy

    Если настройка выполнена успешно, результаты будут выглядеть следующим образом:

    Environment="http_proxy=address:port"
Environment="https_proxy=address:port"

Обновить прокси-сервер, используемый сервером туннеля

Чтобы изменить конфигурацию прокси-сервера, используемого узлом Linux сервера туннеля, используйте следующую процедуру:

  1. На сервере туннеля измените /etc/mstunnel/env.sh и укажите новый прокси-сервер.

  2. Запустите mst-cli install.

    Эта команда пересобирает контейнеры с новыми сведениями прокси-сервера. В ходе этого процесса вам будет предложено проверить содержимое /etc/mstunnel/env.sh и убедиться, что сертификат установлен. Сертификат уже должен присутствовать в предыдущей конфигурации прокси-сервера.

    Чтобы подтвердить и завершить настройку, введите да.

Платформы

Microsoft Tunnel поддерживает только устройства, зарегистрированные в Intune. Поддерживаются следующие платформы устройств:

  • iOS/iPadOS

  • Android Enterprise

    • Полностью управляемая платформа
    • Корпоративный рабочий профиль
    • Личный рабочий профиль

    Примечание.

    Выделенные устройства Android Enterprise не поддерживается в Microsoft Tunnel.

Все платформы поддерживают следующие функции:

  • Проверка подлинности Microsoft Entra в туннеле с использованием имени пользователя и пароля.
  • Проверка подлинности служб федерации Active Directory (AD FS) в туннеле с использованием имени пользователя и пароля.
  • поддержка на уровне приложения;
  • ручное туннелирование для всего устройства через приложение Tunnel, когда пользователь запускает VPN и нажимает Подключить;
  • раздельное туннелирование. Но необходимо учитывать, что в iOS правила раздельного туннелирования игнорируются, если ваш профиль VPN использует VPN для каждого приложения.

Прокси-сервер поддерживается только следующими платформами:

  • Android 10 и более поздних версий
  • iOS/iPadOS

Разрешения

Для управления Microsoft Tunnel пользователи должны иметь разрешения, которые входят в группу разрешений шлюза Microsoft Tunnel в Intune. По умолчанию администраторы Intune и администраторы Microsoft Entra имеют эти разрешения. Их также можно добавлять в пользовательские роли, создаваемые для вашего клиента Intune.

При настройке роли на странице Разрешения разверните узел Шлюз Microsoft Tunnel и выберите разрешения, которые вы хотите предоставить.

Снимок экрана: разрешения шлюза туннеля в Центре администрирования Microsoft Intune.

Группа разрешений шлюза Microsoft Tunnel предоставляет следующие разрешения:

  • Создание — настройка серверов и сайтов шлюзов Microsoft Tunnel. Конфигурации сервера включают параметры для диапазонов IP-адресов, DNS-серверов, портов и правил раздельного туннелирования. Сайты — это логические объединения нескольких серверов, поддерживающих Microsoft Tunnel.

  • Обновление (изменение) — обновление конфигураций и сайтов серверов шлюзов Microsoft Tunnel. Перечень конфигураций серверов включает параметры для диапазонов IP-адресов, DNS-серверов, портов и правил раздельного туннелирования. Сайты — это логические группы нескольких серверов, поддерживающих Microsoft Tunnel.

  • Удаление — удаление конфигураций и сайтов серверов шлюзов Microsoft Tunnel. Конфигурации сервера включают параметры для диапазонов IP-адресов, DNS-серверов, портов и правил раздельного туннелирования. Сайты — это логические объединения нескольких серверов, поддерживающих Microsoft Tunnel.

  • Чтение — просмотр конфигураций и сайтов серверов шлюзов Microsoft Tunnel. Перечень конфигураций серверов включает параметры для диапазонов IP-адресов, DNS-серверов, портов и правил раздельного туннелирования. Сайты — это логические группы нескольких серверов, поддерживающих Microsoft Tunnel.

Запуск средства проверки готовности

Перед началом установки сервера рекомендуется скачать и запустить последнюю версию средства mst-readiness. Это скрипт, который запускается на вашем сервере Linux и выполняет следующие действия:

  • Проверяет, что учетная запись Microsoft Entra, используемая для установки Microsoft Tunnel, имеет необходимые роли для завершения регистрации.

  • подтверждает, что ваша сетевая конфигурация позволяет Microsoft Tunnel получать доступ к требуемым конечным точкам Microsoft;

  • проверяет наличие модуля ip_tables на сервере Linux. Эта проверка была добавлена в сценарий 11 февраля 2022 г., когда была добавлена поддержка RHEL 8.5. RHEL 8.5 более поздних версий по умолчанию не загружает модуль ip_tables. Если они отсутствуют после установки сервера Linux, вы должны вручную загрузить модуль ip_tables.

Важно!

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

Для средства mst-readiness требуется обработчик JSON командной строки jq. Перед запуском средства проверки готовности убедитесь, что jq установлен. Сведения о том, как получить и установить jq, см. в документации к используемой вами версии Linux.

Для запуска средства проверки готовности выполните следующие действия.

  1. Получите последнюю версию средства проверки готовности одним из следующих способов.

    • Загрузите средство напрямую с помощью веб-браузера. Перейдите по адресу https://aka.ms/microsofttunnelready и скачайте файл с именем mst-readiness.

    • Войдите в Центр >администрирования Microsoft IntuneАдминистрирование> клиентаШлюз Microsoft Tunnel, перейдите на вкладку Серверы, нажмите кнопку Создать, чтобы открыть панель Создание сервера, а затем выберите Скачать средство готовности.

    • Получите средство проверки готовности напрямую с помощью команды Linux. Например, вы можете использовать команду wget или curl, чтобы открыть ссылку https://aka.ms/microsofttunnelready.

      Например, чтобы использовать wget и данные журнала для выполнения mst-readiness во время скачивания, выполните wget --output-document=mst-readiness https://aka.ms/microsofttunnelready.

    Скрипт можно запустить с любого сервера Linux, который находится в той же сети, что и сервер, который вы планируете установить, что позволяет сетевым администраторам использовать скрипт для устранения неполадок сети независимо друг от друга.

  2. Чтобы проверить конфигурацию сети и Linux, выполните сценарий со следующими командами. Эти команды задают разрешения на выполнение для скрипта, проверяют, что туннель может подключаться к правильным конечным точкам, а затем проверяет наличие служебных программ, которые туннелирует:

    • sudo chmod +x ./mst-readiness

    • sudo ./mst-readiness network — Эта команда выполняет следующие действия, а затем сообщает об успешном выполнении или ошибке для обоих:

      • Пытается подключиться к каждой конечной точке Microsoft, которую будет использовать туннель.
      • Проверяет, открыты ли необходимые порты в вашем брандмауэре.

    • sudo ./mst-readiness utils — Эта команда проверяет доступность служебных программ, используемых Tunnel, таких как Docker или Podman, и ip_tables.

  3. Чтобы убедиться, что учетная запись, используемая для установки Microsoft Tunnel, имеет необходимые роли и разрешения для завершения регистрации, выполните сценарий с помощью следующей командной строки: ./mst-readiness account

    Сценарий предлагает использовать другой компьютер с веб-браузером, который используется для проверки подлинности в Microsoft Entra ID и Intune. Средство сообщает об успешном выполнении или ошибке.

Дополнительные сведения об этом средстве см. в разделе Справочник по mst-cli справочной статьи для Microsoft Tunnel.

Загрузка ip_tables вручную

Хотя большинство дистрибутивов Linux автоматически загружают модуль ip_tables, некоторые дистрибутивы могут не делать этого. Например, RHEL 8.5 не загружает ip_tables по умолчанию.

Чтобы проверить наличие этого модуля, запустите последнюю версию средства mst-readiness на сервере Linux. Проверка на наличие ip_tables была добавлена в сценарий средств проверки готовности 11 февраля 2022 г.

Если модуль отсутствует, средство останавливается при проверке модуля ip_tables. В этом сценарии можно выполнить следующие команды, чтобы вручную загрузить модуль.

Загрузка модуль ip_tables вручную

В контексте sudo запустите следующие команды на сервере Linux.

  1. Проверка наличия ip_tables на сервере: lsmod |grep ip_tables

  2. Если ip_tables нет, запустите следующую команду, чтобы загрузить модуль в ядро немедленно (без перезапуска): /sbin/modprobe ip_tables

  3. Повторная проверка для подтверждения загрузки таблиц: lsmod |grep ip_tables

Важно!

При обновлении туннельного сервера загруженный вручную модуль ip_tables может не сохраниться. Это может потребовать перезагрузки модуля после завершения обновления. После завершения обновления сервера проверьте сервер на наличие модуля ip_tables.

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

Настройка Linux для загрузки ip_tables при загрузке

В контексте sudo выполните следующую команду на сервере Linux, чтобы создать файл конфигурации, который загружает ip_tables в ядро во время загрузки: echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf

Загрузка модуля tun вручную

Microsoft Tunnel требует модуль tun , однако некоторые дистрибутивы Linux не загружают модуль tun по умолчанию.

Чтобы проверить наличие модуля tun на сервере, выполните следующую команду: lsmod |grep tun

  1. Если tun отсутствует, выполните следующую команду, чтобы немедленно загрузить модуль в ядро без перезапуска: /sbin/modprobe tun

  2. Повторно запустите проверку, чтобы убедиться, что модуль tun now загружен: lsmod |grep tun

Важно!

При обновлении сервера Tunnel загруженный вручную модуль tun может не сохраняться. Для этого может потребоваться перезагрузить модуль после завершения обновления. После завершения обновления сервера проверьте наличие модуля tun на сервере.

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

Настройка Linux для загрузки tun при загрузке

В контексте sudo выполните следующую команду на сервере Linux, чтобы создать файл конфигурации, который загружает tun в ядро во время загрузки: echo tun > /etc/modules-load.d/mstunnel_tun.conf

Дальнейшие действия

Настройка функций Microsoft Tunnel