アプリケーション・ゲートウェイ

アプリケーション・ゲートウェイの一般的な問題をトラブルシューティングする方法を学習します。

My Response Error Message Contains: 400 Bad Request: Invalid header value (応答エラーメッセージに含まれる内容: 400 Bad Request: 無効なヘッダー値)

レスポンス・エラー・メッセージに400 Bad Request: invalid header valueが含まれる場合の一般的な原因について学習します。

アプリケーション・ゲートウェイは、アップストリーム・アプリケーション・サーバーにプロキシ設定されたリクエストにヘッダーを追加します。これらのヘッダーの1つであるidcs_user_display_nameは、アイデンティティ・ドメイン・ユーザーの「名」および「姓」に設定された値に応じて、新しいRFCで定義されている無効な文字を持つ場合があります。この新しいRFCは、許可される文字を印刷可能なUS-ASCII文字(つまり、0x21 - 0x7Eとスペースおよび水平タブ文字)に制限します。RFC 7230 HTTP/1.1 Message Syntax and Routingを参照してください。

新しいRFCを強制するアプリケーション・サーバーは、次のレスポンスでリクエストを拒否します: 400 Bad Request: invalid header value。ノート: 正確なレスポンスは、使用されているアプリケーション・サーバーによって異なります。

印刷できない文字を削除してください。

アプリケーション・ゲートウェイ・サーバーが変更を反映しない

アプリケーション・ゲートウェイ・サーバーでIAMで行った変更が表示されない場合は、次を試してください。

アプリケーション・ゲートウェイは、エンタープライズ・アプリケーションのリソース、認証ポリシー、ヘッダー値などのアイデンティティ・ドメイン情報をキャッシュするため、アイデンティティ・ドメインのエンタープライズ・アプリケーションおよびアプリケーション・ゲートウェイ定義に加えた変更は、アプリケーション・ゲートウェイにすぐに反映されない場合があります。

アプリケーション・ゲートウェイは、エージェントを使用してIAMに接続し、ホストおよびポート情報を収集します。アプリケーション・ゲートウェイを起動すると、そのNGINXサーバーは、この情報で自動的に構成されます。IAMの変更は、エージェントによって定期的にポーリングされます。

デフォルトでは、ポリシーおよびヘッダーのリフレッシュ時間は、それぞれ3,600秒(1時間)です。これらの値を変更するには、アプリケーション・ゲートウェイ・サーバーにサインインし、/usr/local/nginx/conf/cloudgate.configファイルを編集します。次の例に従って、cachingセクションのpolicyおよびheadersのttl値を変更し、アプリケーション・ゲートウェイ・サーバーとエージェントの両方を再起動します。

"caching" : {
  "minimumTtl"            : 300,
  "headers"               : { "ttl": 3600 },
  "discovery"             : { "ttl": 3600 },
  "policy"                : { "ttl": 3600},
  "tenantKeys"            : { "ttl": 86400 }
}

エージェントのポーリング間隔を変更することもできます。デフォルトでは、IAMから新しいアプリケーション・ゲートウェイ構成を取得するためのエージェントのリフレッシュ時間は60秒で、これはサポートされる最小時間です。/usr/local/nginx/conf/cloudgate.configファイルで、agentConfigセクションのpollIntervalSecs値を例のように変更します:

"agentConfig": {
    "pollIntervalSecs"    : 60,
    "daemon"         : true,
    "logLevel"        : "warn",
    "logFolder"        : "" 
}

エンタープライズ・アプリケーション構成の変更をすぐに反映する場合は、アプリケーション・ゲートウェイ・サーバーを停止してからサーバーを起動します。

/scratch/oracle/cloudgate/home/bin/cg-stop
/scratch/oracle/cloudgate/home/bin/cg-start

アプリケーション・ゲートウェイ構成の変更をすぐに反映する場合は、エージェントを停止してからエージェントを起動します。

/scratch/oracle/cloudgate/home/bin/agent-stop
/scratch/oracle/cloudgate/home/bin/agent-start

Invalid_sessionメッセージ

アプリケーション・ゲートウェイがIAMと正しく通信できない場合、アプリケーション・ゲートウェイのエラー・ログ・ファイルにinvalid_sessionメッセージが見つかります。

次に、error.logファイル内のinvalid_sessionメッセージの例を示します:

www-authenticate: Bearer error="invalid_session", error_description="Authentication Failure

これは、アプリケーション・ゲートウェイが保護されたリソースに対するクライアント・リクエストを処理する方法が原因である可能性があります。アプリケーション・ゲートウェイでは、NGINXサブ・リクエストを使用してIAMにリクエストを行います。その後、アプリケーション・ゲートウェイでは、これらのサブ・リクエストが正しく機能するようにLinux NGINXリゾルバを適切に構成する必要があります。

ファイル/usr/local/nginx/conf/nginx-cg-sub.confのリゾルバ設定が正しいIPに設定されていることを確認します。
/usr/local/nginx/conf/cloudgate.configファイルのテナント名が正しく構成されていることを確認します。

GET 127.0.0.1:53コマンド・エラー

エラー・ログ・ファイルには、エラー番号500に応答するGET 127.0.0.1:53コマンドが含まれます。

アプリケーション・ゲートウェイは内部サーブレットにサブ・リクエストを行うため、アプリケーション・ゲートウェイでは、仮想マシンでポート53をリスニングする必要があります。

アプリケーション・ゲートウェイ・サーバーは、IPアドレス127.0.0.1およびポート53を介して自身と通信する必要があります。

仮想マシン・ソフトウェアでアプリケーション・ゲートウェイを実行している場合は、このポートで、ホストからゲストへのポート転送を構成します。ポート転送ルールの構成を参照してください。

アプリケーション・ゲートウェイ・サーバーがIAMと通信できません

A[[ Gateway ServerがIAMと通信できない場合は、次のステップに従って、PuTTYなどのSSHクライアントおよび次の資格証明を使用して、アプリケーション・ゲートウェイ・サーバーにサインインします。

sudo su -コマンドを実行してrootとしてサインインし、プロンプトが表示されたらoracleパスワードを指定します。
次のコマンドを実行してtelnetをインストールします:
```
yum install telnet
```
次のtelnetコマンドを実行し、アプリケーション・ゲートウェイ・サーバーからIAMインスタンスおよびアプリケーションへの接続を確立します。
```
telnet <idcs-tenant>.identity.oraclecloud.com 443
```
telnetでIAMに接続できない場合は、ネットワーク管理者に連絡して他のネットワーク構成を適用し、アプリケーション・ゲートウェイ・サーバーがIAMインスタンスとの接続を確立できるようにします。
exitコマンドを実行して、rootアカウントからログアウトします。