Intune での Microsoft Tunnel の前提条件

[アーティクル]
11/25/2024

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

大まかに言うと、Microsoft Tunnel には次のものが必要です。

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

注:

この前提条件は Microsoft Tunnel 用であり、Microsoft Intune プラン 2 サブスクリプションを必要とするIntune アドオンである Microsoft Tunnel for Mobile Application Management は含まれていません。
コンテナーを実行する Linux サーバー。サーバーはオンプレミスでもクラウドでもかまいません。次のいずれかのコンテナーの種類がサポートされています。
- Podman for Red Hat Enterprise Linux (RHEL)。 Linux サーバーの要件を参照してください。
- 他のすべての Linux ディストリビューション用の Docker。
デバイスから Tunnel Gateway サーバーへの接続をセキュリティで保護するための Linux サーバー用のトランスポート層セキュリティ (TLS) 証明書。
Android または iOS および iPadOS を実行するデバイス。

前提条件を構成した後、準備ツールを実行して、環境が正常にインストールされるように構成されていることを確認することをお勧めします。

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

注:

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

Linux サーバー

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

注:

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

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

配布バージョン	コンテナー要件	考慮事項
Red Hat (RHEL) 8.7	Podman 4.2 (既定値)	このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。 Podman v3 以前で作成されたコンテナーは、Podman v4.2 以降では使用できません。コンテナーをアップグレードして変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールする予定です。
Red Hat (RHEL) 8.8	Podman 4.4.1	このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。 Podman v3 以前で作成されたコンテナーは、Podman v4.2 以降では使用できません。コンテナーをアップグレードして変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールする予定です。
Red Hat (RHEL) 8.9	Podman 4.4.1	このバージョンの 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.2	Podman 4.4.1 (既定値)	このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。 Podman v3 以前で作成されたコンテナーは、Podman v4.2 以降では使用できません。コンテナーをアップグレードして変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールする予定です。
Red Hat (RHEL) 9.3	Podman 4.6.1。 (既定値)	このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。 Podman v3 以前で作成されたコンテナーは、Podman v4.2 以降では使用できません。コンテナーをアップグレードして変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールする予定です。
Red Hat (RHEL) 9.4	Podman 4.9.4-rhel (既定値)	このバージョンの RHEL は、ip_tables モジュールを Linux カーネルに自動的にロードしません。このバージョンを使用する場合は、トンネルをインストールする前に ip_tables を手動でロードすることを計画してください。 Podman v3 以前で作成されたコンテナーは、Podman v4.2 以降では使用できません。コンテナーをアップグレードして変更する場合は、新しいコンテナーを作成し、Microsoft Tunnel をアンインストールしてから再インストールする予定です。
Ubuntu 22.04	Docker CE
Ubuntu 24.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 以降。
- Podman バージョン 3.0 または 4.0 は、RHEL のバージョンに応じて異なります。
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 のドキュメントの「モジュールの概要」を参照してください。
  
  注:
  
  ルートレスポッドマン: Microsoft Tunnel では、ルートレス Podman コンテナーの使用がサポートされています。
  
  ルートレスポッドマンを使用するには、この記事で詳しく説明されている追加の 前提条件 と、Tunnel インストールスクリプトを起動するときに変更されたコマンドラインを使用する必要があります。追加の前提条件とインストールコマンドラインの詳細については、Intuneの Microsoft Tunnel の構成に関する記事の「ルートレス Podman コンテナーを使用する」を参照してください。
トランスポート層セキュリティ (TLS) 証明書: Linux サーバーには、デバイスと Tunnel Gateway サーバー間の接続をセキュリティで保護するために、信頼された TLS 証明書が必要です。 Tunnel Gateway のインストール中に、TLS 証明書と完全な信頼された証明書チェーンをサーバーに追加します。
- Tunnel Gateway エンドポイントをセキュリティで保護するために使用する TLS 証明書のサブジェクト代替名 (SAN) は、Tunnel Gateway サーバーの IP アドレスまたは FQDN と一致している必要があります。
- iOS デバイスの場合、パブリック TLS 証明書はルート CA から発行され、最大有効期限は 398 日である必要があります。ユーザーが追加または管理者が追加したルート CA によって発行された証明書の有効期限は、最大 2 年 (730 日) です。これらの TLS 証明書の要件の詳細については、「support.apple.com での信頼された証明書の今後の制限について」を参照してください。
- Android デバイスの場合、ルート CA から発行されたパブリック TLS 証明書の有効期限は最大 398 日にすることをお勧めします。git a
- ワイルドカードのサポートは制限されています。たとえば、 *.contoso.com はサポートされていますが、 cont*.com はサポートされていません。
- Tunnel Gateway サーバーのインストール中に、信頼された証明書チェーン全体を Linux サーバーにコピーする必要があります。インストールスクリプトにより、証明書ファイルをコピーする場所が提供され、そのためのメッセージが表示されます。
- パブリックに信頼されていない TLS 証明書を使用する場合は、信頼された証明書プロファイルを使用して、信頼チェーン全体をデバイスにプッシュIntune必要があります。
- TLS 証明書は PEM または pfx 形式にすることができます。
- TLS 証明書失効正常性チェックをサポートするには、TLS 証明書によって定義されているオンライン証明書状態プロトコル (OCSP) または証明書失効リスト (CRL) アドレスにサーバーからアクセスできることを確認します。
- 2048 ビット以上のキーを使用して Tunnel クライアント証明書を構成します。さまざまな SSL/TLS ライブラリソリューションによる将来および進化する SSL/TLS 要件のサポートを維持するために、より大きなキーを使用することをお勧めします。
  
  ヒント
  
  選択した SSL/TLS ライブラリの要件を定期的に確認して、インフラストラクチャと証明書がサポートされ、そのライブラリの最近の変更に準拠していることを確認し、必要に応じて Tunnel クライアント証明書を再発行して、ソリューションの進化する要件を最新の状態に保ちます。
TLS バージョン: 既定では、Microsoft Tunnel クライアントとサーバー間の接続では TLS 1.3 が使用されます。 TLS 1.3 を使用できない場合、接続はフォールバックして TLS 1.2 を使用できます。

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

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

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

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 アドレスが企業ネットワークと競合しないことを確認してください。

次のコマンドを使用して、MS Tunnel Gateway コンテナーを停止します: sudo mst-cli server stop ; sudo mst-cli agent stop
次に、次のコマンドを実行して、既存の Docker ブリッジデバイスを削除します: sudo ip link del docker0
ファイル /etc/docker/daemon.json がサーバーに存在する場合は、vi や nano などのファイルエディターを使用してファイルを変更します。 root または sudo のアクセス許可でファイルエディターを実行します。
- "bip": エントリに IP アドレスが存在する場合は、CIDR 表記で新しい IP アドレスを追加して変更します。
- "bip": エントリが存在しない場合は、値 "bip": と CIDR 表記の新しい IP アドレスの両方を追加する必要があります。
次の例は、変更された IP アドレス "192.168.128.1/24" を使用するエントリが更新されたdaemon.json ファイルの構造を示しています。

daemon.json の例:
```
{
"bip": "192.168.128.1/24"
}
```
ファイル /etc/docker/daemon.jsonがサーバーに存在しない場合は、次の例のようなコマンドを実行してファイルを作成し、使用するブリッジ IP を定義します。

例: sudo echo '{ "bip":"192.168.128.1/24" }' > /etc/docker/daemon.json
次のコマンドを使用して、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 アドレスを構成します。

次のコマンドを使用して、MS Tunnel Gateway コンテナーを停止します: sudo mst-cli server stop ; sudo mst-cli agent stop
次に、次のコマンドを実行して、既存の Podman ブリッジデバイスを削除します: sudo ip link del cni-podman0
ルートアクセス許可と vi や nano などのファイルエディターを使用して、 /etc/cni/net.d を 87-podman-bridge.conflist に 変更し、Podman の既定値を目的のサブネットとゲートウェイアドレスに置き換えることで 、"subnet:" と "gateway:" の 既定値を更新します。 サブネット アドレスは CIDR 表記で指定する必要があります。

Podman の既定値は次のとおりです。
- サブネット: 10.88.0.0/16
- ゲートウェイ: 10.88.0.1
次のコマンドを使用して、MS Tunnel Gateway コンテナーを再起動します: sudo mst-cli agent start ; sudo mst-cli server start

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

Linux システム監査

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

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

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

通常、 監査された パッケージは、各 REHL バージョンの既定のリポジトリから使用できます。

RHEL でのシステム監査の使用の詳細については、Red Hat ブログの「 auditd を使用して Linux システム監査を構成する」を参照してください。
Ubuntu: Ubuntu でシステム監査を使用するには、 監査済み パッケージを手動でインストールする必要があります。これを行うには、Linux サーバーで次のコマンドラインを使用します。 sudo apt install auditd audispd-plugins

通常、 監査された パッケージは、各 Ubuntu バージョンの既定のリポジトリから使用できます。

Ubuntu でのシステム監査の使用方法の詳細については、「Ubuntu で監査をセットアップしてインストールする方法」を参照してください。これは、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 は省略可能です。
- NIC 1 - この NIC は、マネージドデバイスからのトラフィックを処理します。パブリック IP アドレスを持つパブリックネットワーク上にある必要があります。    この IP アドレスは、"サイト構成" で構成するアドレスです。このアドレスは、単一のサーバーまたはロードバランサーを表すことができます。
- NIC 2 - この NIC でオンプレミスのリソースへのトラフィックを処理します。ネットワークセグメント化を使用せずに、プライベート内部ネットワーク上に配置する必要があります。
クラウドベースの Linux VM がオンプレミスネットワークにアクセスできることを確認する: Linux をクラウド上の VM として実行する場合は、サーバーからオンプレミスネットワークにアクセスできることを確認してください。たとえば、Azure 内の VM の場合は、Azure ExpressRoute または同様のものを使用してアクセスを提供することができます。オンプレミスの VM でサーバーを実行する場合、Azure ExpressRoute は必要ありません。
Load Balancers(Optional): ロードバランサーを追加する場合は、ベンダーのドキュメントで構成の詳細を確認してください。 Intune と Microsoft Tunnel に固有のネットワークトラフィックとファイアウォールポートについて検討します。

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 にアクセスを提供します。

セキュリティトークンサービス: *.sts.windows.net
トンネルログ用の Azure Storage: *.blob.core.windows.net
その他のストレージエンドポイント URL: *.blob.storage.azure.net
Microsoft Intune:*.manage.microsoft.com
Microsoft 認証: login.microsoftonline.com
Microsoft Graph: graph.microsoft.com
「Microsoft アーティファクトレジストリ (MAR) クライアントファイアウォール規則の構成」で詳しく説明されている構成をサポートするようにファイアウォール規則を構成します。

プロキシ

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

注:

プロキシサーバーの構成は、バージョン 10 より前のバージョンの Android ではサポートされていません。詳細については、その Android 開発者向けドキュメントの「VpnService.Builder 」を参照してください。

注:

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

注:

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

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

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

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

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

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

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

http_proxy=[address]
https_proxy=[address]
認証済みのプロキシはサポートされていません。
プロキシは、Intuneに接続するときに Linux サーバーが 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 を使用するときに内部プロキシを構成するのに役立ちます。

認証済みのプロキシはサポートされていません。
プロキシは、Intuneに接続するときに Linux サーバーが 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 Gateway のセットアップが完了した後にプロキシを構成するには、次の操作を行います。
1. ファイル /etc/profile.d/http_proxy.sh を変更または作成し、前の行頭文字から 2 行を追加します。
2. /etc/mstunnel/env.sh を編集し、ファイルの末尾に次の 2 行を追加します。前の行と同様に、10.10.10.1:3128 の address:port 値の例を、プロキシ IP アドレス: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 を構成できます。

トンネルサーバーで、コマンドプロンプトを使用して次のコマンドを実行し、Microsoft Tunnel サービスのオーバーライドファイルのエディターを開きます。

systemctl edit --force mstunnel_monitor
ファイルに次の 3 行を追加します。 [address] の各インスタンスをプロキシ DN またはアドレスに置き換え、ファイルを保存します。
```
[Service]
Environment="http_proxy=[address]"
Environment="https_proxy=[address]"
```
次に、コマンドプロンプトで次を実行します。

systemctl restart mstunnel_monitor
最後に、コマンドプロンプトで次を実行して、構成が成功したことを確認します。

systemctl show mstunnel_monitor | grep http_proxy

構成が成功した場合、結果は次の情報のようになります。
```
Environment="http_proxy=address:port"
Environment="https_proxy=address:port"
```

トンネルサーバーで使用中のプロキシサーバーを更新する

トンネルサーバーの Linux ホストで使用されているプロキシサーバー構成を変更するには、次の手順を使用します:

トンネルサーバーで、/etc/mstunnel/env.sh を編集し、新しいプロキシサーバーを指定します。
mst-cli install を実行します。

このコマンドは、新しいプロキシサーバーの詳細を使用してコンテナーを再構築します。このプロセスでは、 /etc/mstunnel/env.sh の内容を確認し、証明書がインストールされていることを確認するように求められます。証明書は、以前のプロキシサーバー構成から既に存在している必要があります。

両方を確認して構成を完了するには、「はい」と入力してください。

プラットフォーム

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

iOS/iPadOS
Android Enterprise:
- フルマネージド
- 会社所有の仕事用プロファイル
- 個人所有の仕事用プロファイル
注:

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

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

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

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

Android 10 以降
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 のバージョンのドキュメントを参照してください。

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

次のいずれかの方法を使用して、準備ツールの最新バージョンを入手します。
- 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 サーバーから実行できます。これにより、ネットワーク管理者はスクリプトを使用してネットワークの問題を個別にトラブルシューティングできます。
ネットワークと Linux の構成を検証するには、次のコマンドを使用してスクリプトを実行します。これらのコマンドは、スクリプトの実行アクセス許可を設定し、Tunnel が正しいエンドポイントに接続できることを検証してから、Tunnel で使用するユーティリティの存在をチェックします。
- sudo ./mst-readiness
- sudo ./mst-readiness network - このコマンドは、次のアクションを実行し、両方の成功またはエラーを報告します。
  - トンネルが使用する各 Microsoft エンドポイントへの接続の試み。
  - 必要なポートがファイアウォールで開かれていることの確認。
- sudo ./mst-readiness utils - このコマンドは、Docker や Podman などの Tunnel で使用されるユーティリティとip_tablesが使用可能であることを検証します。
Microsoft Tunnel のインストールに使用するアカウントに、登録を完了するために必要なロールとアクセス許可があることを検証するには、次のコマンドラインでスクリプトを実行します。 ./mst-readiness account

スクリプトでは、Web ブラウザーで別のコンピューターを使用するように求められます。これを使用して、Microsoft Entra IDとIntuneの認証に使用します。ツールは成功またはエラーを報告します。

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

ip_tables を手動でロードする

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

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

モジュールが存在しない場合、ツールは ip_tables モジュールチェックで停止します。このシナリオでは、次のコマンドを実行してモジュールを手動でロードできます。

ip_tables モジュールを手動でロードします。

sudo のコンテキストで、Linux サーバーで次のコマンドを実行します。

サーバー上の ip_tables の存在を検証します。lsmod |grep ip_tables
ip_tables が存在しない場合は、以下を実行して、再起動せずにモジュールをカーネルにすぐにロードします。/sbin/modprobe ip_tables
検証を再実行して、テーブルがロードされたことを確認します。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

tun が存在しない場合は、次を実行して、再起動せずにモジュールをカーネルにすぐに読み込みます。/sbin/modprobe tun
検証を再実行して、 tun モジュールが読み込まれたかどうかを確認します。 lsmod |grep tun

重要

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

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

起動時にチューニングを読み込むよう Linux を構成する

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

次の手順

Microsoft Tunnel を構成する

次の方法で共有

Intune での Microsoft Tunnel の前提条件