Intune での Microsoft Tunnel の前提条件

Microsoft Intune 用の Microsoft Tunnel VPN ゲートウェイをインストールする前に、前提条件を確認して構成してください。 前提条件には、Tunnel サーバー ソフトウェアをホストするためにコンテナーを実行する Linux サーバーの使用が含まれます。 また、ネットワーク、ファイアウォール、およびプロキシを構成して、Microsoft トンネルの通信をサポートするようにすることも計画してください。

大まかに言うと、Microsoft トンネルには次のものが必要です。

  • Azure サブスクリプション。

  • Microsoft Intune プラン 1 サブスクリプション。

    注:

    この前提条件は Microsoft Tunnel 用であり、モバイル アプリケーション管理用の Microsoft Tunnel は含まれません。モバイル アプリケーション管理用の Microsoft Tunnel は、Microsoft Intune 以外の追加のライセンスを必要とする Microsoft Intune の高度な機能です。

  • Microsoft Tunnel のセットアップを完了するには、Tunnel ゲートウェイを Microsoft Intune に登録するために使用するアカウントと、Intune テナントに Intune 管理者の Microsoft Entra ID ロールが割り当てられ、Intune ライセンスが割り当てられている必要があります。

  • コンテナーを実行する Linux サーバー。 サーバーはオンプレミスまたはクラウドにでき、次のいずれかのコンテナーの種類をサポートします。

    • Red Hat Enterprise Linux (RHEL) 用 Podman。 Linuxサーバーの要件を参照してください。
    • 他のすべての Linux ディストリビューション用の Docker です。

  • デバイスから Tunnel Gateway サーバーへの接続をセキュリティで保護するための Linux サーバー用のトランスポート層セキュリティ (TLS) 証明書。

  • Android または iOS および iPadOS を実行するデバイス。

前提条件を構成した後、 準備ツール を実行して、インストールが成功するために環境が適切に構成されていることを検証することをお勧めします。

次のセクションでは、Microsoft Tunnel の前提条件について詳しく説明し、準備ツールの使用に関するガイダンスを提供します。

注:

トンネルとグローバル セキュア アクセス(GSA)を同じデバイスで同時に使用することはできません。

政府機関向けクラウド サポート

Microsoft Tunnel は、次のソブリン クラウド環境でサポートされています。

  • 米国政府機関コミュニティ クラウド (GCC) 高

Microsoft Tunnel は、21Vianet が運用する Microsoft Azure ではサポートされていません。

詳細については、「米国政府機関向け Microsoft Intune GCC サービスの説明」を参照してください。

Linux サーバー

Microsoft Tunnel ゲートウェイをインストールする Linux ベースの仮想マシンまたは物理サーバーを設定します。

注:

次の表にリストされているオペレーティング システムとコンテナ バージョンのみがサポートされています。 一覧にないバージョンはサポートされていません。 テストとサポートが検証された後にのみ、この一覧に新しいバージョンが追加されます。 また、セキュリティ更新プログラムを使用して OS を最新の状態に保ちます。

  • サポートされている Linux ディストリビューション - 次の表に、トンネル サーバーでサポートされている Linux のバージョンと、それらに必要なコンテナーの詳細を示します。

    配布バージョン コンテナー要件 考慮事項
    Red Hat (RHEL) 8.9 Podman 4.4.1 サポートは 2025 年 11 月に終了します。 このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。 このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。

    Podman v3 以前で作成されたコンテナ は、Podman v4.2 以降では使用できません。 コンテナーをアップグレードおよび変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールすることを計画してください。
    Red Hat (RHEL) 8.10 Podman 4.9.4-rhel (デフォルト) このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。 このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。

    Podman v3 以前で作成されたコンテナ は、Podman v4.2 以降では使用できません。 コンテナーをアップグレードおよび変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールすることを計画してください。
    Red Hat (RHEL) 9.3 ポッドマン 4.6.1. (既定) サポートは 2025 年 11 月に終了します。 このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。 このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。

    Podman v3 以前で作成されたコンテナ は、Podman v4.2 以降では使用できません。 コンテナーをアップグレードおよび変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールすることを計画してください。
    Red Hat (RHEL) 9.4 Podman 4.9.4-rhel (デフォルト) サポートは 2025 年 11 月に終了します。 このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。 このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。

    Podman v3 以前で作成されたコンテナ は、Podman v4.2 以降では使用できません。 コンテナーをアップグレードおよび変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールすることを計画してください。
    Red Hat (RHEL) 9.5 Podman 5.2.2 (デフォルト) このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。 このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。

    Podman v3 以前で作成されたコンテナ は、Podman v4.2 以降では使用できません。 コンテナーをアップグレードおよび変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールすることを計画してください。
    Red Hat (RHEL) 9.6 Podman 5.4.0 (デフォルト) このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。 このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。

    Podman v3 以前で作成されたコンテナ は、Podman v4.2 以降では使用できません。 コンテナーをアップグレードおよび変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールすることを計画してください。
    Red Hat (RHEL) 9.7 Podman 5.8.2 (デフォルト) このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。 このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。

    Podman v3 以前で作成されたコンテナ は、Podman v4.2 以降では使用できません。 コンテナーをアップグレードおよび変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールすることを計画してください。
    Red Hat (RHEL) 9.8 Podman 5.8.2+ (デフォルト) このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。 このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。

    Podman v3 以前で作成されたコンテナ は、Podman v4.2 以降では使用できません。 コンテナーをアップグレードおよび変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールすることを計画してください。
    Red Hat (RHEL) 10.0 Podman 5.4.0 (デフォルト) このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。 このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。

    Podman v3 以前で作成されたコンテナ は、Podman v4.2 以降では使用できません。 コンテナーをアップグレードおよび変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールすることを計画してください。
    Red Hat (RHEL) 10.1 Podman 5.8.2 (デフォルト) このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。 このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。

    Podman v3 以前で作成されたコンテナ は、Podman v4.2 以降では使用できません。 コンテナーをアップグレードおよび変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールすることを計画してください。
    Ubuntu 24.04 Docker CE
    Ubuntu 26.04 Docker CE

    重要

    2023 年 4 月に、Ubuntu は Ubuntu 18.04 のサポートを終了します。 Ubuntu によるサポートの終了に伴い、Intune は Microsoft Tunnel で使用するための Ubuntu 18.04 のサポートも終了します。 詳細については、https://wiki.ubuntu.com/Releasesを参照してください。

  • Linux サーバーのサイズ調整: 予想される使用量を満たすように、次のガイダンスを参考にしてください。

    デバイスの数 CPU の数 メモリ (GB) サーバーの数 サイトの数 ディスク領域 (GB)
    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 のコンカレント接続をサポートしますが、個々のデバイスは複数の接続を開くことができます。

  • CPU: 64 ビットの AMD または Intel プロセッサ。

  • Docker CE または Podman をインストールします。Tunnel サーバーで使用する Linux のバージョンに応じて、サーバーに次のいずれかをインストールします。

    • Docker バージョン 19.03 CE 以降。
    • RHEL のバージョンに応じて、Podman バージョン 3.0 または 4.0。

    Microsoft Tunnel には、コンテナーのサポートを提供するために、Linux サーバー上に Docker (または Podman) が必要です。 コンテナーにより、一貫した実行環境、稼働状況の監視とプロアクティブな修復、クリーンなアップグレード エクスペリエンスが提供されます。

    Docker または Podman のインストールと構成の詳細については、以下を参照してください。

    • CentOS または Red Hat Enterprise Linux 7 に Docker Engine をインストールします。

      注:

      上記のリンクを使用すると CentOS のダウンロードおよびインストール手順に移動します。 RHEL 7.4 の場合は、同じ手順を使用します。 既定で RHEL 7.4 にインストールされているバージョンは、Microsoft Tunnel Gateway をサポートするには古すぎます。

    • Ubuntu に Docker Engine をインストールします。

    • Red Hat Enterprise Linux 8.4 以降に Podman をインストールします (RHEL8 まで下にスクロールします)。

      これらのバージョンの RHEL は Docker をサポートしていません。 代わりに、これらのバージョンは Podman を使用し、podman は "container-tools" と呼ばれるモジュールの一部です。 このコンテキストでは、モジュールはコンポーネントを表す一連の RPM パッケージであり、通常は一緒にインストールされます。 一般的なモジュールには、アプリケーションを含むパッケージ、アプリケーション固有の依存関係ライブラリを含むパッケージ、アプリケーションのドキュメントを含むパッケージ、ヘルパー ユーティリティを含むパッケージが含まれます。 詳細については、Red Hat のドキュメントの「モジュールの概要」を参照してください。

      注:

      ルートレス Podman: Microsoft トンネルは、ルートレス Podman コンテナーの使用をサポートしています。

      rootless Podman を使用するには、この記事で詳しく説明されている前提条件に追加の前提 条件 が必要であり、トンネルインストールスクリプトを開始するときに変更されたコマンドラインを使用する必要があります。 追加の前提条件とインストール コマンド ラインについては、「Microsoft Tunnel for Intune の構成」の記事の「ルートレス Podman コンテナーの使用」を参照してください。

  • トランスポート層セキュリティ (TLS) 証明書: Linux サーバーには、デバイスと Tunnel Gateway サーバー間の接続をセキュリティで保護するために、信頼された TLS 証明書が必要です。 Tunnel ゲートウェイのインストール中に、TLS 証明書と完全に信頼された証明書チェーンをサーバーに追加します。

    • Tunnel Gateway エンドポイントをセキュリティで保護するために使用する TLS 証明書のサブジェクト代替名 (SAN) は、Tunnel Gateway サーバーの IP アドレスまたは FQDN と一致している必要があります。

    • iOS デバイスの場合、パブリック TLS 証明書はルート CA から発行される必要があり、有効期限は 398 日です。 ユーザーが追加した、または管理者が追加したルート CA によって発行された証明書の有効期限は、最長で 2 年 (730 日) です。 これらの TLS 証明書の要件の詳細については、「support.apple.com の 信頼できる証明書の今後の制限について 」を参照してください。

    • Android デバイスの場合、ルート CA から発行されたパブリック TLS 証明書の有効期限は最大で 398 日にすることをお勧めします。

    • ワイルドカードのサポートには制限があります。 たとえば、 *.contoso.com はサポートされますが、 cont*.com はサポートされません。

    • Tunnel Gateway サーバーのインストール中に、信頼された証明書チェーン全体を Linux サーバーにコピーする必要があります。 インストール スクリプトにより、証明書ファイルをコピーする場所が提供され、そのためのメッセージが表示されます。

    • 公的に信頼されていない TLS 証明書を使用する場合は、Intune の信頼できる証明書プロファイルを使用して、信頼チェーン全体をデバイスにプッシュする必要があります。

    • TLS 証明書は PEM または pfx 形式にすることができます。

    • TLS 証明書失効の正常性チェックをサポートするには、TLS 証明書によって定義されているオンライン証明書ステータス プロトコル (OCSP) または証明書失効リスト (CRL) アドレスにサーバーからアクセスできることを確認してください。

    • 2048 ビット以上のキーを使用してトンネル クライアント証明書を構成します。 さまざまな SSL/TLS ライブラリ ソリューションによって将来および進化する SSL/TLS 要件に対応して展開を行うには、より大きなキーをお勧めします。

      ヒント

      選択した SSL/TLS ライブラリの要件を定期的に確認して、インフラストラクチャと証明書が引き続きサポートされ、そのライブラリの最近の変更に準拠していることを確認し、ソリューションの進化する要件に合わせるために、必要に応じてトンネル クライアント証明書を再発行します。

  • TLS バージョン: 既定では、Microsoft Tunnel クライアントとサーバー間の接続では TLS 1.3 が使用されます。 TLS 1.3 を使用できない場合は、接続をフォールバックして TLS 1.2 を使用することができます。

既定のブリッジ ネットワーク

Podman コンテナーと Docker コンテナーの両方がブリッジ ネットワークを使用して、Linux ホスト経由でトラフィックを転送します。 コンテナー ブリッジ ネットワークが企業ネットワークと競合する場合、Tunnel ゲートウェイはその企業ネットワークにトラフィックを正常にルーティングできません。

既定のブリッジ ネットワークは次のとおりです。

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

競合を回避するために、Podman と Docker の両方を再構成して、指定したブリッジ ネットワークを使用できます。

重要

ブリッジ ネットワーク構成を変更する前に、Tunnel Gateway サーバーをインストールする必要があります。

Docker が使用する既定のブリッジ ネットワークを変更する

Docker は、ファイル /etc/docker/daemon.json を使用して、新しい既定のブリッジ IP アドレスを構成します。 このファイルでは、ブリッジ IP アドレスを CIDR (クラスレス ドメイン間ルーティング) 表記で指定する必要があります。これは、IP アドレスを、関連するサブネット マスクおよびルーティング プレフィックスとともに表すコンパクトな方法です。

重要

次の手順で使用される IP アドレスは一例です。 使用する IP アドレスが企業ネットワークと競合しないことを確認してください。

  1. 次のコマンドを使用して、MS Tunnel Gateway コンテナーを停止します: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. 次に、次のコマンドを実行して、既存の Docker ブリッジ デバイスを削除します: sudo ip link del docker0

  3. ファイル /etc/docker/daemon.json がサーバーに存在する場合は、vi や nano などのファイル エディターを使用してファイルを変更します。 root または sudo のアクセス許可でファイル エディターを実行します。

    • "bip": エントリに IP アドレスが存在する場合は、CIDR 表記で新しい IP アドレスを追加して変更します。
    • "bip": エントリが存在しない場合は、値 "bip": と新しい IP アドレスの両方を CIDR 表記で追加する必要があります。

    次の例は、更新された "bip": エントリを持つ daemon.json ファイルの構造を示しています。このエントリは、変更された 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 Tunnel Gateway コンテナーを起動します: sudo mst-cli agent start ; sudo mst-cli server start

詳細については、Docker ドキュメントの「ブリッジ ネットワークの使用」を参照してください。

Podman が使用する既定のブリッジ ネットワークを変更する

Podman は、ファイル /etc/cni/net.d as 87-podman-bridge.conflist を使用して、新しい既定のブリッジ IP アドレスを構成します。

  1. 次のコマンドを使用して、MS Tunnel Gateway コンテナーを停止します: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. 次に、次のコマンドを実行して、既存の Podman ブリッジ デバイスを削除します: sudo ip link del cni-podman0

  3. root 権限と vi や nano などのファイルエディタを使用して、 /etc/cni/net.d を 87-podman-bridge.conflist に変更 し、Podman のデフォルト値を目的のサブネットとゲートウェイのアドレスに置き換えて、「 subnet:」 と「 gateway:」 のデフォルトを更新します。 サブネット アドレスは CIDR 表記で指定する必要があります。

    Podman の既定値は次のとおりです。

    • サブネット: 10.88.0.0/16
    • ゲートウェイ: 10.88.0.1

  4. 次のコマンドを使用して、MS Tunnel Gateway コンテナーを再起動します: sudo mst-cli agent start ; sudo mst-cli server start

詳細については、Red Hat のドキュメントの「Podman を使用したコンテナー ネットワークの設定」を参照してください。

Linux システム監査

Linux システム監査は、Microsoft Tunnel をホストする Linux サーバー上のセキュリティ関連情報またはセキュリティ違反を特定するのに役立ちます。 Microsoft Tunnel には Linux システム監査が推奨されますが、必須ではありません。 システム監査を使用するには、Linux サーバーに auditd パッケージがインストールされている必要があります /etc/audit/auditd.conf。

mst 準備ツールを実行するたびに、auditd が見つからないことを示す警告がツールに表示される場合があります。 トンネル固有のディレクトリの監査を有効にするには、mstunnel-setup を実行する前に auditd パッケージをインストールしてください。

監査の実装方法の詳細は、使用する Linux プラットフォームによって異なります。

  • Red Hat: Red Had Enterprise Linux 7 以降のバージョンでは、デフォルトで auditd パッケージがインストールされます。 ただし、パッケージがインストールされていない場合は、Linux サーバーで次のコマンド ラインを使用してパッケージをインストールできます。sudo dnf install audit audispd-plugins

    通常、 auditd パッケージは、各 REHL バージョンのデフォルト リポジトリから入手できます。

    RHEL でのシステム監査の使用に関する詳細は、Red Hat ブログの auditd を使用した Linux システム監査の設定 を参照してください。

  • Ubuntu: Ubuntu でシステム監査を使用するには、 auditd パッケージを手動でインストールする必要があります。 これを行うには、Linux サーバーで次のコマンド ラインを使用します。sudo apt install auditd audispd-plugins

    通常、 auditd パッケージは、各 Ubuntu バージョンの既定のリポジトリから入手できます。

    Ubuntu でのシステム監査の使用の詳細については、「 Ubuntu に Auditd をセットアップしてインストールする方法」を参照してください。この記事は、元々 kubefront.com で公開された dev.to Web サイトで入手できます。

ネットワーク

  • IPv4 のパケット転送を有効にする: Tunnel サーバー ソフトウェアをホストする各 Linux サーバーでは、IPv4 の IP 転送が有効になっている必要があります。 IP 転送の状態を確認するには、サーバー上で、root または sudo として次のいずれかの汎用コマンドを実行します。 どちらのコマンドも、"無効" の場合は値 0 を、"有効" の場合は値 1 を返します。

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

    有効になっていない場合は、サーバー上で root または sudo として次のいずれかの汎用コマンドを実行して、IP 転送を一時的に有効にすることができます。 これらのコマンドを実行すると、サーバーが再起動するまで 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 サーバーごとに 2 つのネットワーク インターフェイス コントローラー (NIC) を使用することをお勧めしますが、2 つの使用は省略可能です。

    • NIC 1 - この NIC は、マネージド デバイスからのトラフィックを処理します。パブリック IP アドレスを持つパブリック ネットワーク上にある必要があります。  この IP アドレスは、"サイト構成" で構成するアドレスです。 このアドレスは、単一のサーバーまたはロード バランサーを表すことができます。

    • NIC 2 - この NIC でオンプレミスのリソースへのトラフィックを処理します。ネットワーク セグメント化を使用せずに、プライベート内部ネットワーク上に配置する必要があります。

  • クラウドベースの Linux VM がオンプレミス ネットワークにアクセスできることを確認する: Linux をクラウド上の VM として実行する場合は、サーバーからオンプレミス ネットワークにアクセスできることを確認してください。 たとえば、Azure 内の VM の場合は、Azure ExpressRoute または同様のものを使用してアクセスを提供することができます。 オンプレミスの VM でサーバーを実行する場合、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 Storage にアクセスするには、次の FQDN にアクセスを提供します。

プロキシ

Microsoft Tunnel でプロキシ サーバーを使用できます。

注:

Android LOB アプリケーションが MDM と MAM の両方について、ダイレクト プロキシまたはプロキシ自動構成 (PAC) をサポートしていることを確認します。

注:

既知の問題: プロキシの自動構成 (PAC) が構成されている場合、個人または企業のアカウントを使用して Edge にサインインしようとすると、問題が発生する可能性があります。 このシナリオでは、サインイン プロセスが失敗し、ユーザーが内部リソースにアクセスできなくなる可能性があります。

回避策: この問題を解決するために、Microsoft Tunnel はオプションとして分割トンネリングを提供します。 スプリット トンネリングを使用すると、ユーザーはプロキシを必要とするルートのみを含め、ログイン サーバーと認証パスをトンネル経由のルーティングから除外できます。 この回避策により、サインイン プロセスが PAC 構成の影響を受けないため、ユーザーは内部リソースにアクセスしてインターネットを参照できるようになります。

ダイレクト プロキシは、企業アカウントを使用して Edge でサインインするためのスプリット トンネリングなしのオプションでもあります。 これには、PAC URL の代わりに直接プロキシを使用するように Microsoft トンネルを構成する必要があります。

Edge でユーザー サインインが必要ない場合は、通常の閲覧と内部リソースへのアクセスで PAC がサポートされます。

次の考慮事項は、Linux サーバーと環境を適切に構成するのに役立ちます。

Docker の送信プロキシを構成する

  • 内部プロキシを使用する場合は、環境変数を使用して、プロキシ サーバーを使用するように Linux ホストを構成することが必要になる場合があります。 変数を使用するには、Linux サーバー上の /etc/environment ファイルを編集し、各行のアドレスをプロキシ IP アドレスのアドレスに置き換えて、次の行を追加します。

    http_proxy=address
    https_proxy=address

  • 認証済みのプロキシはサポートされていません。

  • Linux サーバーは Intune に接続するときに TLS 相互認証を使用するため、プロキシは中断と検査を実行できません。

  • プロキシを使用してイメージをプルするように Docker を構成します。 これを行うには、Linux サーバー上の /etc/systemd/system/docker.service.d/http-proxy.conf ファイルを編集し、次の行を追加します。

    [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 サーバーは Intune に接続するときに TLS 相互認証を使用するため、プロキシは中断と検査を実行できません。

  • Podman は、/etc/profile.d/http_proxy.sh に格納されている HTTP プロキシ情報を読み取ります。このファイルがサーバーに存在しない場合は、作成します。 http_proxy.sh を編集して、次の 2 行を追加します。 次の行では、10.10.10.1:3128 が address:port エントリの例です。 これらの行を追加する場合は、10.10.10.1:3128 をプロキシ IP address:port の値に置き換える必要があります。

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

    Red Hat Customer Portal にアクセスできる場合は、このソリューションに関連付けられているナレッジ ベースの記事を表示できます。 「Podman の HTTP プロキシ変数の設定 - Red Hat Customer Portal」を参照してください。

  • mstunnel-setup を実行して Microsoft Tunnel Gateway をインストールする前に、これらの 2 行を http_proxy.sh に追加すると、スクリプトは /etc/mstunnel/env.sh に Tunnel Gateway プロキシ環境変数を自動的に構成します。

    Microsoft Tunnel ゲートウェイのセットアップが完了した後でプロキシを構成するには、次の操作を実行します。

    1. ファイル /etc/profile.d/http_proxy.sh を変更または作成し、前の行頭文字から 2 行を追加します。

    2. /etc/mstunnel/env.sh を編集し、ファイルの末尾に次の 2 行を追加します。 前の行と同様に、 address:port の例の値 10.10.10.1:3128 をプロキシ IP address:port の値に置き換えます。

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

    3. Tunnel Gateway サーバーを再起動する: mst-cli server restart を実行する

    RHEL は SELinux を使用することに注意してください。 http_port_t の SELinux ポートで実行されないプロキシは追加の構成が必要になる可能性があるため、http の SELinux 管理ポートの使用を確認してください。 構成を表示するには、次のコマンドを実行します。 sudo semanage port -l | grep "http_port_t"

    ポート チェック コマンドの結果の例。 この例では、プロキシは 3128 を使用し、一覧に表示されません。

    ポート チェックの結果を表示するスクリーン ショット。

    • プロキシが http_port_t の SELinux ポートの 1 つで実行されている場合は、Tunnel Gateway のインストール プロセスを続行できます。

    • 前の例のようにプロキシが SELinux ポートで http_port_t で実行されない場合は、追加の設定を行う必要があります。

      プロキシ ポートが http_port_tの一覧に表示されていない場合は、プロキシ ポートが別のサービスで使用されているかどうかチェックします。 semanage コマンドを使用して、最初にプロキシが使用するポートをチェックし、必要に応じて後で変更します。 プロキシが使用するポートを確認するには、次を実行します: sudo semanage port -l | grep "your proxy port"

      ポートを使用する可能性があるサービスを確認した結果の例:

      サービス チェックの結果を表示するスクリーン ショット。

      • この例では、予想されるポート (3128) は、OSS プロキシ サービスである squid によって使用されています。 Squid プロキシ SELinux ポリシーは、多くの一般的なディストリビューションの一部です。 squid はポート 3128 (この例のポート) を使用するため、http_port_t ポートを変更し、Tunnel で使用されるプロキシ用に SELinux 経由で許可されるようにポート 3128 を追加する必要があります。 ポートの使用を変更するには、次のコマンドを実行します: 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" コマンドを実行するときにプロキシ ポートが一覧表示されていない場合は、コマンドを実行してポートを再度変更しますが、-a を指定して semanage コマンドの -m を実行します: sudo semanage port -a -t http_port_t -p tcp "your proxy port"

プロキシを使用してイメージの更新をダウンロードするように Podman を構成する

プロキシを使用して Podman の更新されたイメージをダウンロード (プル) するように Podman を設定できます。 この構成は、将来のアップグレードにとって重要です。 Tunnel Gateway のインストール後に設定する必要があるため、ここではメンションしますが、Tunnel Gateway サーバーのインストール後に完了するタスクとして、「Microsoft Tunnel の設定」の記事の「プロキシを使用してイメージの更新をダウンロードするように Podman を構成する」に構成ガイダンスを追加しました。

プラットフォーム

Microsoft Tunnel でサポートされるためには、デバイスが Intune に登録されている必要があります。 次のデバイス プラットフォームのみがサポートされています。

  • iOS/iPadOS

  • Android Enterprise:

    • フル マネージド
    • 会社所有の仕事用プロファイル
    • 個人所有の仕事用プロファイル

    注:

    "Android Enterprise 専用" デバイスは、Microsoft Tunnel によってサポートされていません。

    重要

    Microsoft Tunnel での Android 10 のサポートは、2026 年 3 月 31 日に終了しました。 Android 10 を実行しているデバイスは、Microsoft Tunnel を使用し続けるために Android 11 以降にアップグレードする必要があります。

すべてのプラットフォームで次の機能がサポートされます。

  • ユーザー名とパスワードを使用したトンネルへの Microsoft Entra 認証。
  • ユーザー名とパスワードを使用した、トンネルへの Active Directory フェデレーション サービス (AD FS) 認証。
  • アプリごとのサポート。
  • ユーザーが VPN を起動して [接続] を選択する、手動による完全なデバイス トンネル。
  • 分割トンネリング。 ただし、VPN プロファイルで "アプリごとの VPN" を使用している場合、iOS の分割トンネリング規則は無視されます。

プロキシのサポートは、次のプラットフォームに限定されています。

  • Android 11 以降
  • iOS/iPadOS

アクセス許可

ユーザーが Microsoft Tunnel を管理するには、Intune の Microsoft Tunnel Gateway アクセス許可グループに含まれるアクセス許可が必要です。 既定では、Intune 管理者と Microsoft Entra 管理者にはこれらのアクセス許可があります。 また、Intune テナント用に作成したカスタム ロールにそれらを追加することもできます。

ロールの構成中に、[アクセス許可] ページで [Microsoft Tunnel Gateway] を展開してから、付与するアクセス許可を選択します。

Microsoft Intune 管理センターのトンネル ゲートウェイのアクセス許可のスクリーンショット。

Microsoft Tunnel Gateway アクセス許可グループにより、次のアクセス許可が付与されます。

  • 作成 - Microsoft Tunnel Gateway の "サーバー" と "サイト" を構成します。 サーバー構成には、IP アドレス範囲、DNS サーバー、ポート、および分割トンネリング規則の設定が含まれます。 サイトは、Microsoft Tunnel をサポートする複数のサーバーの論理グループです。

  • 更新 (変更) - Microsoft Tunnel Gateway サーバーの構成とサイトを更新します。 サーバー構成には、IP アドレス範囲、DNS サーバー、ポート、および分割トンネリング規則の設定が含まれます。 サイトは、Microsoft Tunnel をサポートする複数のサーバーの論理グループです。

  • 削除 -Microsoft Tunnel Gateway サーバーの構成とサイトを削除します。 サーバー構成には、IP アドレス範囲、DNS サーバー、ポート、および分割トンネリング規則の設定が含まれます。 サイトは、Microsoft Tunnel をサポートする複数のサーバーの論理グループです。

  • 読み取り - Microsoft Tunnel Gateway サーバーの構成とサイトを表示します。 サーバー構成には、IP アドレス範囲、DNS サーバー、ポート、および分割トンネリング規則の設定が含まれます。 サイトは、Microsoft Tunnel をサポートする複数のサーバーの論理グループです。

準備ツールの実行

サーバーのインストールを開始する前に、最新バージョンの mst-readiness ツールをダウンロードして実行することをお勧めします。 このツールは、Linux サーバー上で実行されるスクリプトで、次の操作を行います。

  • Microsoft Tunnel のインストールに使用する Microsoft Entra アカウントに、登録を完了するために必要なロールがあることを検証します。

  • ネットワーク構成によって、Microsoft Tunnel から必要な Microsoft エンドポイントへのアクセスが許可されていることを確認します。

  • Linux サーバー上の ip_tables モジュールの存在を確認します。 このチェックは、RHEL 8.5 のサポートが追加された、2022 年 2 月 11 日にスクリプトに追加されました。 RHEL 8.5 以降では、既定では ip_tables モジュールは読み込まれません。 Linux サーバーのインストール後にそれらが欠落している場合は、ip_tables モジュールを手動でロードする必要があります。

重要

準備ツールによって受信ポートが検証されることはありません。これは、一般的な構成の誤りです。 準備ツールを実行した後で、ファイアウォールの前提条件を確認し、ファイアウォールが受信トラフィックを渡すことを手動で検証します。

mst-readiness ツールは、コマンドライン JSON プロセッサである jq に依存しています。 この準備ツールを実行する前に、確実にjq をインストールしてください。 jq を取得してインストールする方法の詳細については、使用している Linux のバージョンのドキュメントを参照してください。

準備ツールを使用するには:

  1. 次のいずれかの方法を使用して、準備ツールの最新バージョンを入手します。

    • Web ブラウザーを使用して、ツールを直接ダウンロードします。 https://aka.ms/microsofttunnelready にアクセスして、mst-readiness という名前のファイルをダウンロードします。

    • Microsoft Intune管理センター>テナント管理>Microsoft Tunnel Gateway にサインインし、[サーバー] タブを選択し、[作成] を選択して [サーバーの作成] ウィンドウを開き、[準備ツールのダウンロード] を選択します。

    • Linux コマンドを使用して、準備ツールを直接取得します。 たとえば、wget または curl を使用して、リンク https://aka.ms/microsofttunnelready を開くことができます。

      たとえば、ダウンロード中に wget を使用して詳細を mst-readiness に記録するには、wget --output-document=mst-readiness https://aka.ms/microsofttunnelready を実行します

    このスクリプトは、インストールする予定のサーバーと同じネットワーク上にある任意の Linux サーバーから実行できます。これにより、ネットワーク管理者はスクリプトを使用して、ネットワークの問題を個別にトラブルシューティングできます。

  2. ネットワークと Linux の構成を検証するには、次のコマンドを使用してスクリプトを実行します。 次のコマンドは、スクリプトの実行アクセス許可を設定し、トンネルが正しいエンドポイントに接続できることを検証してから、トンネルが使用するユーティリティの存在をチェックします。

    • sudo ./mst-readiness

    • sudo ./mst-readiness network - このコマンドは、以下のアクションを実行し、両方の成功またはエラーを報告します。

      • トンネルが使用する各 Microsoft エンドポイントへの接続の試み。
      • 必要なポートがファイアウォールで開かれていることの確認。

    • sudo ./mst-readiness utils - このコマンドは、Docker や Podman および ip_tables などの Tunnel によって使用されるユーティリティーが使用可能であることを検証します。

  3. Microsoft Tunnel のインストールに使用するアカウントに、登録を完了するために必要なロールとアクセス許可があることを確認するには、次のコマンド ラインでスクリプトを実行します。 ./mst-readiness account

    このスクリプトは、Microsoft Entra ID および Intune への認証に使用する Web ブラウザーで別のマシンを使用するように求めるメッセージを表示します。 ツールは成功またはエラーを報告します。

このツールの詳細については、Microsoft Tunnel のリファレンス記事にある mst-cli のリファレンスを参照してください。

Linux システム監査用に監査されたプログラムを手動でインストールする

準備ツールは、Linux システム監査用の auditd パッケージが存在するかどうかをチェックします。 auditd はオプションであり必須ではないため、このパッケージが検出されない場合、準備スクリプトは警告を返します。

Auditd は、RHEL 7 以降のバージョンでは既定でインストールされますが、Ubuntu ディストリビューションでは既定でインストールされない場合があります。 存在しない場合は、Linux サーバーに手動でインストールできます。

Tunnel サーバーをインストールする前にこれを手動でインストールする方法については、この記事の「Linux システム監査」を参照してください。

Microsoft Tunnel のインストール後に auditd をインストールするには、「Micrfosoft トンネルの構成」の「Tunnel サーバーのインストール後に Linux システム監査をインストールする」を参照してください。

ip_tables を手動でロードする

ほとんどの Linux ディストリビューションはip_tables モジュールを自動的にロードしますが、一部のディストリビューションはロードしない場合があります。 たとえば、RHEL 8.5 は既定でip_tablesを読み込みません。

このモジュールの存在を確認するには、Linux サーバーで最新バージョンの mst-readiness ツールを実行します。 ip_tables のチェックは、2022 年 2 月 11 日に準備ツール スクリプトに追加されました。

モジュールが存在しない場合、ツールは 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

重要

Tunnel サーバーを更新するときに、手動で読み込まれた ip_tables モジュールが保持されない可能性があります。 これにより、更新が完了した後にモジュールを再読み込みする必要があります。 サーバーの更新が完了したら、ip_tables モジュールが存在するサーバーを確認します。

テーブルが存在しない場合は、前の手順を使用してモジュールを再読み込みし、モジュールの読み込み後にサーバーを再起動する追加の手順を使用します。

起動時に ip_tables をロードするように Linux を構成します。

sudo のコンテキストで、Linux サーバーで次のコマンドを実行して、起動時にip_tablesをカーネルに読み込む構成ファイルを作成します。echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf

タンモジュールを手動でロードする

Microsoft Tunnel には tun モジュールが必要ですが、一部の Linux ディストリビューションでは既定で tun モジュールが読み込まれません。

サーバー上に tun モジュールが存在することを検証するには、次を実行します。 lsmod |grep tun

  1. tun が存在しない場合は、次を実行して、再起動せずにモジュールをカーネルに直ちに読み込みます。/sbin/modprobe tun

  2. 検証を再実行して、 tun モジュールが読み込まれたことを確認します。 lsmod |grep tun

重要

Tunnel サーバーを更新するときに、手動で読み込まれた tun モジュールが保持されないことがあります。 このため、更新の完了後にモジュールを再読み込みすることが必要になる場合があります。 サーバーの更新が完了したら、 サーバーに tun モジュールがあるかどうか確認します。

存在しない場合は、上記の手順を使用してモジュールをリロードし、モジュールがロードされた後にサーバーを再起動する追加の手順を使用します。

起動時に tun を読み込むように Linux を構成する

sudo のコンテキストで、Linux サーバーで次のコマンドを実行して、起動時に tun をカーネルにロードする構成ファイルを作成します。echo tun > /etc/modules-load.d/mstunnel_tun.conf

次の手順

Microsoft Tunnel を構成する

  • Last updated on