次の方法で共有

既存のオンプレミス プロキシ サーバーと連携する

  • [アーティクル]

送信プロキシ サーバーを使うように Microsoft Entra プライベート ネットワーク コネクタを構成します。 この記事は、ネットワーク環境にプロキシ サーバーが既にあることを前提にしています。

まず、次の主なデプロイ シナリオを見ていきます。

  • オンプレミスの送信プロキシをバイパスするようにコネクタを構成する。
  • 送信プロキシを使用して Microsoft Entra アプリケーション プロキシにアクセスにするようにコネクタを構成する。
  • コネクタとバックエンド アプリケーション間のプロキシを使用して構成する。

コネクタのしくみの詳細については、「Microsoft Entra プライベート ネットワーク コネクタについて」をご覧ください。

送信プロキシをバイパス

コネクタには、送信要求を行う基になる OS コンポーネントがあります。 これらのコンポーネントは、Web プロキシ自動発見 (WPAD) を使って自動的にネットワーク上のプロキシ サーバーの特定を試みます。

OS コンポーネントは、wpad.domainsuffix のドメイン ネーム システム (DNS) 参照を実行して、プロキシ サーバーの検出を試みます。 参照が DNS で解決すると、wpad.dat のインターネット プロトコル (IP) アドレスに対して HTTP 要求が行われます。 この要求が、環境におけるプロキシ構成スクリプトになります。 コネクタは、このスクリプトを使用して送信プロキシ サーバーを選択します。 ただし、プロキシでの構成設定がさらに必要なため、コネクタ トラフィックが失敗し続ける可能性があります。

オンプレミスのプロキシをバイパスして Microsoft Entra アプリケーション プロキシ サービスへの直接接続を使うように、コネクタを構成できます。 直接接続は必要な構成が少ないため、推奨されます。 ただし、一部のネットワーク ポリシーでは、ローカル プロキシ サーバーを経由するトラフィックが必要です。

コネクタによる送信プロキシの使用を無効にするには、C:\Program Files\Microsoft Entra private network connector\MicrosoftEntraPrivateNetworkConnectorService.exe.config ファイルを編集して、次のコード例で示されている system.net セクションを追加します。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.net>
    <defaultProxy enabled="false"></defaultProxy>
  </system.net>
  <runtime>
    <gcServer enabled="true"/>
  </runtime>
  <appSettings>
    <add key="TraceFilename" value="MicrosoftEntraPrivateNetworkConnector.log" />
  </appSettings>
</configuration>

Connector Updater サービスでもプロキシがバイパスされるようにするには、MicrosoftEntraPrivateNetworkConnectorUpdaterService.exe.config ファイルも同じように変更します。 このファイルは C:\Program Files\Microsoft Entra private network connector Updater に配置されます。

既定の .config ファイルに戻す必要がある場合に備えて、元のファイルのコピーを必ず作成してください。

送信プロキシ サーバーの使用

一部の環境では、すべての送信トラフィックが例外なく送信プロキシを経由する必要がある場合があります。 そのような場合は、プロキシをバイパスすることはできません。

次の図に示すように、コネクタのトラフィックが送信プロキシを経由するように構成できます。

コネクタ トラフィックが送信プロキシを経由して Microsoft Entra アプリケーション プロキシに到達するように構成する

送信トラフィックしかないため、ファイアウォール経由で受信アクセスを構成する必要はありません。

注意

アプリケーション プロキシは、他のプロキシに対する認証をサポートしていません。 コネクタ/アップデータのネットワーク サービス アカウントは、認証を求められることなく、プロキシに接続できる必要があります。

環境内で WPAD を有効にし、適切に構成している場合、コネクタは送信プロキシ サーバーを自動的に検出して使用を試みます。 一方で、送信プロキシを経由するようにコネクタを明示的に構成することができます。

そのためには、C:\Program Files\Microsoft Entra private network connector\MicrosoftEntraPrivateNetworkConnectorService.exe.config ファイルを編集して、次のコード例で示されている system.net セクションを追加します。 ローカル プロキシ サーバーの名前または IP アドレスとポートを反映するように、proxyserver:8080 を変更します。 IP アドレスを使っている場合でも、値にはプレフィックス http:// を付ける必要があります。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.net>  
    <defaultProxy>   
      <proxy proxyaddress="http://proxyserver:8080" bypassonlocal="True" usesystemdefault="True"/>   
    </defaultProxy>  
  </system.net>
  <runtime>
    <gcServer enabled="true"/>
  </runtime>
  <appSettings>
    <add key="TraceFilename" value="MicrosoftEntraPrivateNetworkConnector.log" />
  </appSettings>
</configuration>

次に、C:\Program Files\Microsoft Entra private network connector Updater\MicrosoftEntraPrivateNetworkConnectorUpdaterService.exe.config ファイルも同じように変更して、プロキシを使うように Connector Updater サービスを構成します。

Note

defaultProxy が MicrosoftEntraPrivateNetworkConnectorService.exe.config で構成されていない場合 (既定)、コネクタ サービスでは %SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config で使用されている defaultProxy 構成が評価されます。Connector Updater サービス (MicrosoftEntraPrivateNetworkConnectorUpdaterService.exe.config) にも同じことが当てはまります。

送信プロキシで考慮すべき点は次の 4 つです。

  • プロキシ送信規則
  • プロキシの認証
  • プロキシ ポート
  • トランスポート層セキュリティ (TLS) の検査

プロキシ送信規則

次の URL へのアクセスを許可します。

URL ポート 用途
*.msappproxy.net
*.servicebus.windows.net		 443/HTTPS コネクタとアプリケーション プロキシ クラウド サービスの間の通信
crl3.digicert.com
crl4.digicert.com
ocsp.digicert.com
crl.microsoft.com
oneocsp.microsoft.com
ocsp.msocsp.com
 80/HTTP コネクタでは、証明書の検証にこれらの URL が使用されます。
login.windows.net
secure.aadcdn.microsoftonline-p.com
*.microsoftonline.com
*.microsoftonline-p.com
*.msauth.net
*.msauthimages.net
*.msecnd.net
*.msftauth.net
*.msftauthimages.net
*.phonefactor.net
enterpriseregistration.windows.net
management.azure.com
policykeyservice.dc.ad.msft.net
ctldl.windowsupdate.com		 443/HTTPS コネクタでは、登録プロセスの間にこれらの URL が使用されます。
ctldl.windowsupdate.com
www.microsoft.com/pkiops		 80/HTTP コネクタでは、登録プロセスの間にこれらの URL が使用されます。

ファイアウォールまたはプロキシで DNS 許可リストを構成できる場合は、*.msappproxy.net と *.servicebus.windows.net への接続を許可できます。

完全修飾ドメイン名 (FQDN) で接続を許可することができず、代わりに IP 範囲を指定する必要がある場合は、次のオプションを使います。

  • すべてのアクセス先に対するコネクタの送信アクセスを許可する。
  • Azure データセンターの全 IP アドレス範囲に対するコネクタの送信アクセスを許可する。 Azure データセンターの IP 範囲の一覧を使う場合の課題は、それが毎週更新されることです。 アクセス規則が適宜更新されるようにプロセスを整備する必要があります。 IP アドレスのサブセットのみを使うと、構成が壊れます。 Azure データ センターの最新の IP 範囲は、https://download.microsoft.com からダウンロードできます。 Azure IP Ranges and Service Tags という検索語句を使います。 必ず関連するクラウドを選択してください。 たとえば、パブリック クラウドの IP 範囲は、Azure IP Ranges and Service Tags – Public Cloud で検索すると見つかります。 US Government クラウドは、Azure IP Ranges and Service Tags – US Government Cloud で検索すると見つかります。

プロキシの認証

プロキシ認証は現在サポートされていません。 現在はインターネット上のアクセス先に対して、コネクタの匿名アクセスを許可することをお勧めします。

プロキシ ポート

コネクタは、CONNECT メソッドを使用して TLS ベースの送信接続を確立します。 このメソッドにより、送信プロキシを経由するトンネルが設定されます。 プロキシ サーバーが、ポート 443 と 80 へのトンネリングを許可するように構成します。

注意

Service Bus を HTTPS 経由で実行する場合は、ポート 443 が使用されます。 ただし、既定では、Service Bus は伝送制御プロトコル (TCP) で直接接続を試み、直接接続が失敗した場合にのみ HTTPS にフォールバックします。

TLS インスペクション

コネクタのトラフィックに関する問題の原因になるため、コネクタのトラフィックには TLS 検査を使わないでください。 コネクタは証明書を使用してアプリケーション プロキシ サービスに対する認証を行いますが、その証明書が TLS インスペクションの間に失われることがあります。

コネクタとバックエンド アプリケーション間のプロキシを使用して構成する

一部の環境では、バックエンド アプリケーションに対する通信での転送プロキシの使用が、特別な要件になります。 転送プロキシを有効にするには、次の手順のようにします。

手順 1:必要なレジストリ値をサーバーに追加する

  1. 既定のプロキシを使用できるようにするには、HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Entra private network connector にあるコネクタ構成レジストリ キーに、レジストリ値 (DWORD)UseDefaultProxyForBackendRequests = 1 を追加します。

手順 2:netsh コマンドを使用してプロキシ サーバーを手動で構成する

  1. グループ ポリシー Make proxy settings per-machine を有効にします。 このグループ ポリシーは、Computer Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer にあります。 ユーザーごとにポリシーを設定するのではなく、グループ ポリシーを設定する必要があります。
  2. サーバーで gpupdate /force を実行します。 または、グループ ポリシーが更新されるようにするには、サーバーを再起動します。
  3. 管理者権限で管理者特権でのコマンド プロンプトを起動し、control inetcpl.cpl を入力します。
  4. 必要なプロキシ設定を構成します。

この設定により、コネクタは Azure への通信とバックエンド アプリケーションへの通信に、同じ転送プロキシを使うようになります。 転送プロキシを変更するには、MicrosoftEntraPrivateNetworkConnectorService.exe.config ファイルを修正します。 転送プロキシの構成については、「送信プロキシをバイパス」と「送信プロキシ サーバーの使用」セクションで説明されています。

Note

オペレーティング システムでは、さまざまな方法でインターネット プロキシを構成できます。 NETSH WINHTTP によって構成されるプロキシ設定 (確認するには NETSH WINHTTP SHOW PROXY を実行します) は、手順 2 で構成したプロキシ設定をオーバーライドします。

Connector Updater サービスはコンピューター プロキシを使います。 この設定は、MicrosoftEntraPrivateNetworkConnectorUpdaterService.exe.config ファイルにあります。

コネクタのプロキシの問題とサービスの接続の問題のトラブルシューティング

これですべてのトラフィックがプロキシを経由します。 問題が生じた場合は、次のトラブルシューティング情報が役に立ちます。

コネクタの接続の問題を特定してトラブルシューティングを行う最善の方法は、コネクタ サービスの開始時にネットワーク キャプチャを実行することです。 ネットワーク トレースをキャプチャおよびフィルター処理する際に役立つヒントを簡単に紹介します。

任意の監視ツールを使用することができます。 ここでは、Microsoft Message Analyzer を使用しています。

注意

Microsoft Message Analyzer (MMA) は廃止され、2019 年 11 月 25 日に microsoft.com サイトからダウンロード パッケージが削除されました。 現時点では、開発における Microsoft Message Analyzer の Microsoft 代替製品はありません。 同様の機能については、Wireshark などのサード パーティ製のネットワーク プロトコル アナライザー ツールを使用することを検討してください。

以下に示すのは Message Analyzer の例ですが、原則はどの分析ツールでも同じです。

コネクタ トラフィックのキャプチャを実行する

最初のトラブルシューティングでは、次の手順を実行します。

  1. services.msc から、Microsoft Entra プライベート ネットワーク コネクタ サービスを停止します。

    services.msc 内の Microsoft Entra プライベート ネットワーク コネクタ サービス

  2. Message Analyzer を管理者として実行します。

  3. [Start Local Trace]\(ローカル トレースの開始\) を選択します。

  4. Microsoft Entra プライベート ネットワーク コネクタ サービスを開始します。

  5. ネットワーク キャプチャを停止します。

    [ネットワーク キャプチャの停止] ボタンを示すスクリーンショット

コネクタのトラフィックが送信プロキシをバイパスするかどうかを確認する

コネクタがアプリケーション プロキシ サービスに直接接続するよう構成している場合、ポート 443 での SynRetransmit 応答は、ネットワークまたはファイアウォールの問題が発生していることを示しています。

Message Analyzer フィルターを使用して、失敗した伝送制御プロトコル (TCP) 接続試行を特定します。 フィルターのボックスに property.TCPSynRetransmit と入力し、 [Apply]\(適用\) を選択します。

同期 (SYN) パケットは、TCP 接続を確立するために最初に送信されるパケットです。 このパケットにより応答が返されない場合は、SYN パケットの送信が再試行されます。 前に示したフィルターを使うと、再送信されたすべての SYN パケットを確認できます。 その後、これらの SYN パケットがいずれかのコネクタ関連トラフィックに対応するかどうかを調べることができます。

コネクタのトラフィックが送信プロキシを使用しているかどうかを確認する

プライベート ネットワーク コネクタのトラフィックがプロキシ サーバーを経由するよう構成している場合は、プロキシへの https 接続が失敗していないかを確認してください。

Message Analyzer フィルターを使用して、プロキシへの失敗した HTTPS 接続試行を特定します。 Message Analyzer フィルターに (https.Request or https.Response) and tcp.port==8080 を入力します。ここで、8080 を自分のプロキシ サービス ポートに置き換えます。 [Apply]\(適用\) を選択してフィルター結果を確認します。

前述のフィルターにより、プロキシ ポートとの間の HTTPS 要求と応答のみが表示されます。 プロキシ サーバーとの通信を示す CONNECT 要求を調べます。 成功すると、HTTP OK (200) の応答が表示されます。

他の応答コード (407 や 502 など) が表示される場合は、プロキシが認証を必要としているか、何らかの理由でトラフィックを許可しないことを示しています。 その場合は、プロキシ サーバー サポート チームのサポートを得てください。

次のステップ