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

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

Общие требования для Microsoft Tunnel:

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

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

  Примечание.

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

• Чтобы завершить настройку Microsoft Tunnel, учетной записи, которую вы будете использовать для регистрации шлюза туннеля в Microsoft Intune, и вашему клиенту Intune должна быть назначена роль Microsoft Entra ID администратора Intune и назначена лицензия Intune.

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

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

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

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

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

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

Поддержка облака для государственных организаций

Microsoft Tunnel поддерживается в следующих национальных облачных средах:

• Облако сообщества для государственных организаций США (GCC) High

Microsoft Tunnel не поддерживается в Microsoft Azure, предоставляемой 21Vianet.

Дополнительные сведения см. в описании службы Microsoft Intune для государственных организаций США в рамках GCC.

Сервер Linux

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

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

  Версия распределения	Требования к контейнеру	Рекомендации
  Red Hat (RHEL) 8,9	Подман 4.4.1	Поддержка заканчивается в ноябре 2025 г. Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel. Контейнеры, созданные в Podman v3 и более ранних версиях , не подходят для Podman v4.2 и более поздних версий. При обновлении и смене контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
  Red Hat (RHEL) 8.10	Podman 4.9.4-rhel (по умолчанию)	Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel. Контейнеры, созданные в Podman v3 и более ранних версиях , не подходят для Podman v4.2 и более поздних версий. При обновлении и смене контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
  Red Hat (RHEL) 9,3	Подман 4.6.1. (Значение по умолчанию.)	Поддержка заканчивается в ноябре 2025 г. Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel. Контейнеры, созданные в Podman v3 и более ранних версиях , не подходят для Podman v4.2 и более поздних версий. При обновлении и смене контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
  Red Hat (RHEL) 9,4	Podman 4.9.4-rhel (по умолчанию)	Поддержка заканчивается в ноябре 2025 г. Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel. Контейнеры, созданные в Podman v3 и более ранних версиях , не подходят для Podman v4.2 и более поздних версий. При обновлении и смене контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
  Red Hat (RHEL) 9,5	Podman 5.2.2 (по умолчанию)	Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel. Контейнеры, созданные в Podman v3 и более ранних версиях , не подходят для Podman v4.2 и более поздних версий. При обновлении и смене контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
  Red Hat (RHEL) 9,6	Podman 5.4.0 (по умолчанию)	Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel. Контейнеры, созданные в Podman v3 и более ранних версиях , не подходят для Podman v4.2 и более поздних версий. При обновлении и смене контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
  Red Hat (RHEL) 9,7	Podman 5.8.2 (по умолчанию)	Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel. Контейнеры, созданные в Podman v3 и более ранних версиях , не подходят для Podman v4.2 и более поздних версий. При обновлении и смене контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
  Red Hat (RHEL) 9,8	Podman 5.8.2+ (по умолчанию)	Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel. Контейнеры, созданные в Podman v3 и более ранних версиях , не подходят для Podman v4.2 и более поздних версий. При обновлении и смене контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
  Red Hat (RHEL) 10.0	Podman 5.4.0 (по умолчанию)	Эта версия RHEL не загружает автоматически модуль ip_tables в ядро Linux. При использовании этой версии запланируйте ручную загрузку ip_tables до установки Tunnel. Контейнеры, созданные в Podman v3 и более ранних версиях , не подходят для Podman v4.2 и более поздних версий. При обновлении и смене контейнеров запланируйте создание новых контейнеров, а также удаление, а затем переустановку Microsoft Tunnel.
  Ubuntu 24.04	Docker CE
  Ubuntu 26.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, которую вы используете для своего туннельного сервера, установите на сервере одно из следующих средств:

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

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

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

  • Установите модуль Docker Engine в 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 шлюза. Во время установки туннельного шлюза вы добавляете на сервер TLS-сертификат и полную цепочку доверенных сертификатов.

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

  • Для устройств с iOS открытые сертификаты TLS должны выдаваться корневым центром сертификации с максимальным сроком действия 398 дней. Максимальный срок действия сертификатов, выданных добавленным пользователем или администратором, может составлять до двух лет (730 дней). Дополнительные сведения об этих требованиях к сертификатам TLS см. в разделе "О предстоящих ограничениях для доверенных сертификатов " на сайте support.apple.com.

  • Для устройств с Android рекомендуется, чтобы максимальный срок действия общедоступных сертификатов TLS, выданных корневым центром сертификации, составлял 398 дней.

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

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

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

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

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

  • Настройте сертификат клиентов туннелей с помощью ключа размером 2048 бит или больше. Рекомендуется использовать более крупные ключи, чтобы обеспечить поддержку развертывания будущих и меняющихся требований SSL/TLS различными решениями библиотеки SSL/TLS.

    Совет

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

• Версия 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-адреса вместе со связанной маской подсети и префиксом маршрутизации.

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.

Аудит системы Linux

Аудит системы Linux помогает выявить информацию, относящуюся к безопасности, или нарушения безопасности на сервере Linux, на котором размещен Microsoft Tunnel. Аудит системы Linux рекомендуется проводить для Microsoft Tunnel, но это не является обязательным. Чтобы использовать аудит системы, на сервере Linux должен быть установлен /etc/audit/auditd.confпакет аудита.

При каждом запуске средства mst-readiness может отображаться предупреждение о том, что параметр auditd отсутствует. Чтобы включить аудит каталогов для конкретных туннелей, обязательно установите пакет с аудитом перед запуском mstunnel-setup.

Подробные сведения о том, как реализовать аудит, зависят от используемой платформы Linux:

• Red Hat: в версиях Red По умолчанию был установлен пакет Enterprise Linux 7 и более поздней версии. Если пакет не установлен, для его установки можно использовать следующую командную строку на сервере Linux:sudo dnf install audit audispd-plugins

  Как правило, пакет с аудитом доступен в репозитории по умолчанию для каждой версии REHL.

  Дополнительные сведения об использовании системного аудита в RHEL см. в статье "Настройка системного аудита Linux с помощью auditd" в блоге Red Hat.

• Ubuntu: чтобы использовать аудит системы в Ubuntu, необходимо вручную установить пакет с аудитом . Для этого используйте следующую командную строку на сервере Linux:sudo apt install auditd audispd-plugins

  Как правило, пакет с аудитом доступен из репозитория по умолчанию для каждой версии Ubuntu.

  Дополнительные сведения об использовании аудита системы в Ubuntu см. в статье «Как настроить и установить Auditd в Ubuntu», которая доступна на веб-сайте dev.to, первоначально опубликованном в kubefront.com.

Сеть

• Включить пересылку пакетов для 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:*.manage.microsoft.com
• Проверка подлинности Майкрософт: login.microsoftonline.com
• Microsoft Graph: graph.microsoft.com
• Настройте правила брандмауэра для поддержки конфигураций, описанных в разделе "Конфигурация правил брандмауэра клиента реестра артефактов Microsoft" (MAR).
• Конечная точка диагностики: powerlift-frontdesk.acompli.net

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

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

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

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

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

  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, скрипт автоматически настроит переменные среды прокси-сервера Tunnel Gateway в /etc/mstunnel/env.sh.

  Чтобы настроить прокси-сервер после завершения настройки шлюза туннелей (Майкрософт) выполните следующие действия:

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

  2. Измените файл /etc/mstunnel/env.sh и добавьте в его конец две указанные ниже строки. Как и в предыдущих строках, замените пример адреса порта, значение 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. Эта конфигурация важна для будущих обновлений. Так как он должен быть настроен после установки туннельного шлюза, мы упоминание его здесь, но добавили руководство по настройке Podman для использования прокси-сервера для загрузки обновлений изображений в статье Настройка Microsoft Tunnel в качестве задачи, которую необходимо выполнить после установки сервера шлюза Tunnel.

Платформы

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

• iOS/iPadOS

• Android Enterprise

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

  Примечание.

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

  Важно!

  Поддержка Android 10 в Microsoft Tunnel прекращена 31 марта 2026 г. Чтобы продолжить использовать Microsoft Tunnel, устройства под управлением Android 10 необходимо обновить до Android 11 или более поздней версии.

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

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

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

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

Разрешения

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

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

Группа разрешений шлюза 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, запустите сценарий с помощью следующих команд. Эти команды задают разрешения на запуск сценария, проверяют, может ли туннель подключаться к правильным конечным точкам, а затем проверка наличие утилит, используемых Tunnel:

   • sudo ./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.

Ручная установка с аудитом системы Linux

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

Auditd устанавливается по умолчанию в RHEL 7 и более поздних версиях, но может не устанавливаться по умолчанию в дистрибутивах Ubuntu. Если он отсутствует, его можно вручную установить на сервере Linux.

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

Сведения об установке, осуществляемой с аудитом после установки Microsoft Tunnel, см. в статье "Аудит установки системы Linux" после установки сервера Tunnel в статье "Настройка туннеля Micrfosoft".

Загрузка 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

Настройка 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 загружен: lsmod |grep tun

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

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

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

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