Red Hat RHUI の接続に関する問題のトラブルシューティング
適用対象: ✔️ Linux VM
ネットワーク層の構成が間違うと、Red Hat Update Infrastructure (RHUI) で一般的な問題が発生する可能性があります。 この記事は、これらの問題の一部を特定して解決するのに役立ちます。
概要
Microsoft Azure でホストされる RHUI へのアクセスは、Azure データセンターの IP アドレス範囲内の仮想マシン (VM) に限定されます。 詳細については、「Azure のオンデマンド Red Hat Enterprise Linux VM 用の Red Hat Update Infrastructure」を参照してください。
Red Hat は、Azure パブリック IP 範囲からのトラフィックのみを許可するように、これらの Azure でホストされる RHUI サーバーを構成しました。 この設定により、仮想プライベート ネットワーク (VPN) またはその他の方法を使用して Azure と Azure でホストされている RHUI サーバーの間のトラフィックを再ルーティングすると、Azure でホストされる RHUI サーバーによってそのトラフィックがブロックされます。
重要
RHUI は、従量課金制 (PAYG) イメージ のみを対象としています。 ゴールデン イメージ (Bring Your Own Subscription (BYOS) とも呼ばれます) では、システムが Red Hat Subscription Manager (RHSM) または Red Hat Satellite に接続されている場合にのみ、更新プログラムを受け取ることができます。 詳細については、RHEL システムを登録してサブスクライブする方法に関する記事を参照してください。
現象
RHUI が管理する yum リポジトリの一覧は、プロビジョニング中に Red Hat Enterprise Linux (RHEL) インスタンスで構成されます。 追加の構成を行う必要はありません。 RHEL VM に最新のアップデートを適用する準備ができたら、yum update
を実行するだけです。 ただし、 yum update
の操作中に接続が最終的にタイムアウトになり、次のいずれかのアウトプット文字列のようなエラー メッセージが表示されます。
出力 1
https://rhui-3.microsoft.com/pulp/repos/microsoft-azure-rhel7/repodata/repomd.xml: [Errno 12] https://rhui-3.microsoft.com/pulp/repos/microsoft-azure-rhel7/repodata/repomd.xml: のタイムアウト (28, '0 バイトのうち 0 が受信された状態で 3,0000 ミリ秒後に操作がタイムアウトしました')
出力 2
https://rhui4-1.microsoft.com/pulp/repos/content/dist/rhel8/rhui/8/x86_64/baseos/os/repodata/repomd.xml [OpenSSL SSL_connect: http://rhui4-1.microsoft.com:443 に関連するSSL_ERROR_SYSCALL]
出力 3
DEBUG error: Curl error (28): timeout was reached for https://rhui-1.microsoft.com/pulp/repos/content/dist/rhel8/rhui/8/x86_64/baseos/os/repodata/repomd.xml [Operation timeouted after 30000 milliseconds with 0 out of 0 bytes received] (https://rhui-1.microsoft.com/pulp/repos/content/dist/rhel8/rhui/8/x86_64/baseos/os/repodata/repomd.xml).
出力 4
https://rhui-3.microsoft.com/pulp/repos/microsoft-azure-rhel7/repodata/repomd.xml: [Errno 14] curl#56 - "Network error recv()" [Errno 12] timeout on https://rhui-3.microsoft.com/pulp/repos/microsoft-azure-rhel7/repodata/repomd.xml: (28, 'Operation timed out after 30000 milliseconds with 0 out of 0 bytes received')
トラブルシューティングのチェックリスト
トラブルシューティング手順 1: RHUI バージョン 4 の IP アドレスを更新する
ネットワーク構成(カスタム ファイアウォールまたは UDR 構成) を使用して、RHEL 従量課金制(PAYG)のVM から https
アクセスをさらに制限しますか? この場合、環境に応じて yum update
が動作するために正しい IP アドレスが許可されていることを確認します。 次のテーブルでは、Azure Global for RHUI バージョン 4 のさまざまなリージョンで使用される IP アドレスを示します。
リージョン | IP アドレス (IP address) |
---|---|
西ヨーロッパ | 52.136.197.163 |
米国中南部 | 20.225.226.182 |
米国東部 | 52.142.4.99 |
オーストラリア東部 | 20.248.180.252 |
東南アジア | 20.24.186.80 |
Note
2023 年 10 月 12 日の時点で、すべての PAYG クライアントは、今後 2 か月間の段階で RHUI 4 IP アドレスに転送されます。 この間、RHUI 3 IP アドレスは継続的な更新のために使用され続けますが、将来削除される予定です。 パッケージと更新プログラムへのアクセスを中断しない場合は、RHUI 3 IP アドレスへのアクセスを許可する既存のルートとルールを更新して、RHUI 4 IP アドレスも含める必要があります。 移行期間中も引き続き更新プログラムを受け取るには、RHUI 3 の IP アドレスを削除しないことをお勧めします。
すべての Azure Government PAYG インスタンスでは、以前に説明したのと同じ RHUI IP アドレスが使用されます。
トラブルシューティングの手順 2: 検証スクリプトを実行する
Azure では、GitHub で RHUI リポジトリ検証スクリプトを使用できます。 スクリプトの多くの機能の 1 つは、リポジトリ サーバーの接続を検証し、接続エラーが検出された場合の修正に関する推奨事項を提供することです。 この Python スクリプトには、次の機能があります。
yum clean all
コマンドとyum check-update
コマンドを実行しますからの出力とエラーをキャプチャします。
yum check-update
エラーが見つからない場合にリポジトリの接続が成功したことを報告します
定義された条件を使用して検出されたエラーを検証し、修正に関する推奨事項を提供します
スクリプトを取得するには、 RHUI_repo_validation_scriptsを参照してください。
サポート対象の OS イメージ
このバージョンの検証スクリプトでは、現在、Azure Marketplace イメージからデプロイされた次の Red Hat VM のみがサポートされています。
- RHEL 6.x
- RHEL 7.x
- RHEL 8.x PAYG VM
検証スクリプトを実行する方法
検証スクリプトを実行するには、Red Hat VM で次のシェル コマンドを入力します。
mkdir /tmp/rhui
cd /tmp/rhui
wget https://github.com/Azure/azure-support-scripts/archive/refs/heads/master.zip
unzip master.zip 'azure-support-scripts-master/Linux_scripts/RHUI_repo_validation_scripts/*'
rm -f master.zip
cd azure-support-scripts-master/Linux_scripts/RHUI_repo_validation_scripts
python repo_check.py # Use "python3" instead of "python" for Python version 3.
原因
次の一覧には、RHUI 接続エラーの根本的な原因が含まれています。
ユーザー定義ルート (UDR) は、インターネットへの次ホップ IP アドレスを持つよう構成されていません。
UDR ルールは、UDR ルールの RHUI バージョンにアクセスするように構成されていません。
ネットワーク インターフェイスに対して、ネットワーク セキュリティ グループ (NSG) が正しくないか見つからないかが構成されています。
NSG ルールは、RHUI バージョンにアクセスするように構成されていません。
次のセクションには、これらの基になる障害の原因が発生する可能性があるシナリオと、接続エラーを修正する解決策の概要が含まれています。
シナリオ 1: VM が内部ロード バランサーを使用するように構成されている
内部ロード バランサーは、ネットワーク インターフェイス用に構成されている場合、送信接続を提供しません。
解決策 1a: パブリック IP アドレスを追加する
VM のネットワーク インターフェイスにパブリック IP アドレスを追加します。 詳細については、「仮想マシンへのパブリック IP アドレスの関連付け」を参照してください。
ソリューション 1b: 外部ロード バランサーを使用する
内部 Azure Load Balancer ではなく、外部の Azure Load Balancer を使用します。 詳細については、「 クイックスタート: Azure ポータルを使用して、VM の負荷分散を行うパブリック ロード バランサーを作成する 」を参照してください。
解決策 1c: サブネットで NAT ゲートウェイを使用する
送信アクセスには、VM サブネット上のネットワーク アドレス変換 (NAT) ゲートウェイを使用します。 詳細については、「Azure NAT ゲートウェイ リソース」を参照してください。
ソリューション 1d: 内部の基本ロード バランサーを使用する
内部標準ロード バランサーではなく、内部の基本ロード バランサーを使用するようにダウングレードします。
Note
このソリューションは、ロード バランサーの基本バージョンが廃止予定であるため、一時的な修正にすぎません。 詳細については、Azure Basic Load Balancer が 2025 年 9 月 30 日に廃止される (Standard Load Balancer へのアップグレード) を参照してください。
解決策 1e: SNAT ルールを使用する
ソース ネットワーク アドレス変換 (SNAT) 規則を使用します。 詳細については、「 送信接続に SNAT を使用する」を参照してください。
シナリオ 2: RHUI サーバーが RHUI パブリック IP アドレスではなくオンプレミス ネットワークに接続する
Azure の Red Hat VM は、RHUI リポジトリを使用して更新を完了するために、RHUI サーバーに接続する必要があります。 接続では、要求を RHUI サーバーに送信する必要があります。 強制トンネリング シナリオ (高速ルート) または VPN では、サーバーが RHUI パブリック IP アドレスではなくオンプレミス ネットワークに接続するため、接続に失敗します。
解決策 2: UDR を作成する
トラフィックを RHUI サーバーにルーティングする UDR を作成します。 次のスクリーンショットは、Azure portal のルート テーブルで作成する必要がある UDR を示しています。 UDR は、「 トラブルシューティング手順 1: RHUI バージョン 4 の IP アドレスを更新する」に記載されている Azure グローバル リージョンと IP アドレスに基づいています。 詳細については、「 ルート テーブルの作成、変更、または削除を参照してください。
シナリオ 3: Azure ファイアウォールまたは仮想アプライアンスが仮想ネットワークとインターネットの間にある
Azure 仮想ネットワークとインターネット間の保護障壁として機能する Azure ファイアウォールまたは仮想アプライアンスが存在する場合があります。 このバリアは、セキュリティ ポリシーを適用し、すべてのトラフィックをファイアウォールに送信することで、トラフィックを効果的に制御および監視する機能を提供します。 この場合、ファイアウォールが RHUI サーバーへの通信をブロックしています。
解決策 3: RHUI IP アドレスにアクセスできることを確認する
次のアクションを実行して、RHUI IP アドレスに完全にアクセスできることを確認します。
ファイアウォール ポリシーで宛先 RHUI IP アドレスが許可されていることを確認します。
Secure Sockets Layer (SSL) 検査がアクティブな場合は、RHUI IP アドレスが許可されていることを確認します。
NSG が使用されている場合は、ネットワーク インターフェイス NSG またはサブネット NSG の送信規則の許可リストに RHUI IP アドレスが追加されていることを確認します。 優先度は
Block_Internet_Access_outbound
ルールよりも高くする必要があります。
シナリオ 4: チェックポイント ファイアウォールが SSL 検査を実行する
ネットワーク トラフィック ルートが SSL 検査を実行するチェックポイント ファイアウォール デバイスを通過する場合、このプロセスによって、RHUI 証明書が RHUI サーバーへの通信に影響する方法が変更される可能性があります。
解決策 4: 許可リストに RHUI の IP アドレスと URL を追加する
SSL 検査がアクティブな場合は、RHUI の IP アドレスと URL が許可リストに含まれていることを確認します。
シナリオ 5: 通信にプロキシを使用する
インターネット通信は、RHUI サーバーへの通信に影響を与える顧客プロキシを経由します。
解決策 5: プロキシ構成設定を修正する
RHEL VM と RHUI の間で Microsoft Azure でプロキシ サーバーが構成されている場合は、次のスニペットに示すように、 /etc/yum.conf または /etc/dnf.conf ファイルの正しいプロキシ構成設定を使用します。
重要
構成されたプロキシ サーバーにプライベート IP アドレスがある場合は、Azure パブリック アドレス空間内に接続されていることを確認します。
proxy=http://myproxy.mydomain.com:3128
proxy_username=proxy-user
proxy_password=password
重要
RHEL VM と RHUI の間にプロキシ サーバーが存在しない場合は、 /etc/yum.conf または /etc/dnf.conf ファイル内にあるプロキシ構成設定を検索して削除します。
サードパーティの情報に関する免責事項
この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。
サード パーティの連絡先に関する免責事項
Microsoft では、このトピックに関する追加情報を検索するのに役立つサード パーティの連絡先情報を提供しています。 この連絡先情報は、予告なしに変更される可能性があります。 Microsoft では、サード パーティの連絡先情報が正確であることを保証していません。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。