既知の問題

このトピックでは、ゲートウェイのバージョン 10.0 の既知の問題と、利用可能な回避方法がある場合にはそれらについて説明します。
gateway10
このトピックでは、
Layer7 API Gateway
のバージョン 10.0 の既知の問題と、利用可能な回避方法がある場合にはそれらについて説明します。
2
ハードウェア アプライアンスの再イメージ化によって「Error to Copy」エラーがスローされる
問題
: ユーザが Gateway ハードウェア アプライアンスを再イメージ化しようとすると、エラーが発生する可能性があります(DE507949)。
回避方法
: ありません - このエラーは Gateway または Gateway イメージの操作には影響しません。ただし、この問題は Gateway バージョン 10.1 以降で解決されています。
廃止された JSON スキーマ v2 が Policy Manager に引き続き表示される
問題
: サードパーティ ライブラリの重大な CVE により、Gateway バージョン 10.0 CR1 での JSON スキーマ v2 のサポートは廃止され、削除されました。しかし、Policy Manager では、廃止されたにもかかわらず、ユーザが引き続きスキーマ バージョンとして v2 を選択できます。(DE515093)
回避方法
: ユーザは、Gateway 10.0 CR1 以降のバージョンにアップグレードする前に、影響を受ける Gateway ポリシー アサーション(例: Validate JSON Schema アサーション(セキュリティ脅威保護))内の既存の JSON スキーマを v2 から v4 にアップグレードすることをお勧めします。
TLS 1.3 ポストハンドシェイク認証がサポートされない
問題
: ドキュメントに記載されている JDK の制限事項によって、Gateway は、受信トラフィックと送信トラフィックの両方について、TLS 1.3 ポストハンドシェイク認証をサポートしていません。
回避方法
: JDK がポストハンドシェイク認証をサポートする予定はないため、Gateway ユーザは、クライアント/バックエンド側からのポストハンドシェイク認証を無効化するか、代わりに Gateway メッセージ ルーティングに TLS 1.2 を使用することをお勧めします。(DE504887)
TLS 1.3 のみを有効化した場合にリスン ポートの設定が保存できない
問題
: リスン ポートで TLS 1.3 のみを有効化すると、サーバの秘密鍵が RSA 暗号を使用する場合、またはデフォルトの秘密鍵のタイプが EC (Elliptic Curve、楕円曲線)の場合、ユーザは設定を保存できません。このような場合、エラーが表示されます。(DE496977)
回避方法
: サーバの秘密鍵が RSA 暗号を使用する場合、少なくとも 1 つの RSA 暗号スイートを TLS 1.3 暗号スイートと共に有効化し、リスン ポートの設定を保存します。EC 秘密鍵を使用する場合、少なくとも 1 つの EC 暗号スイートを有効化し、設定を保存します。
Liquibase データベース例外によってデータベース スキーマのアップグレードが失敗する
問題
: Gateway のアップグレードの一環として MySQL データベース スキーマをアップグレードしようとする場合、一部のユーザから以下のエラーが報告されています(DE490936)。
Migration failed for change set upgrade_x.y.z.xml::create_published_service_properties::gateway: Reason: liquibase.exception.DatabaseException: Error executing SQL CREATE TABLE ssg_testUpgrade.published_service_property (published_service_goid BINARY(16) NOT NULL, name VARCHAR(128) NOT NULL, value MEDIUMTEXT NOT NULL): Table 'published_service_property' already exists
回避方法
: 回避方法はいくつかの手順で構成されます。DATABASECHANGELOG エントリを同じバージョンの別のベースライン Gateway に属するエントリと比較します。比較用のベースラインとして機能する別の既存の Gateway データベースが存在しない場合、この目的のために別のサーバ(実稼働サーバとは別のサーバ)に新しい Gateway をインストールする必要があります。たとえば、Gateway をバージョン 9.4 から 10.0 にアップグレードする場合、別のサーバに Gateway バージョン 9.4 を新規インストールします。次に、新しくインストールした SSG Gateway バージョン 9.4 データベースの DATABASECHANGELOG テーブルを、アップグレードの問題が発生した Gateway のものと比較します。
両方の Gateway MySQL データベースで以下を実行します。
# use ssg; # select count(*) from DATABASECHANGELOG;
2 つのデータベースで返された数が異なる場合、問題が発生している/実稼働環境の Gateway の DATABASECHANGELOG が破損している可能性があります。
ベースライン Gateway または新しくインストールした Gateway のデータベースから変更ログ エントリをコピーし、問題のある Gateway のデータベースのログ エントリを置き換えることで、これを修正できます。
  1. アップグレードする Gateway スキーマを含む実稼働データベースのバックアップを行います。
  2. 同じバージョンの Gateway のベースラインまたは新規インストールで、以下のコマンドを実行します。
    # mysqldump ssg DATABASECHANGELOG > /home/ssgconfig/dbchangelog_rows.sql
  3. dbchangelog_rows.sql
    を開き、以下の行を探します。
    INSERT INTO 'DATABASECHANGELOG' VALUES (...);
  4. (...)内のコンテンツを含む行全体をコピーします。
  5. データベースに変更を加える前に、実稼働 Gateway を停止します。
    # service ssg stop
  6. MySQL クライアントから、以下を実行します。
    # use ssg; # delete * from DATABASECHANGELOG;
  7. 実行するコマンド ラインに
    INSERT INTO ‘DATABASECHANGELOG’ VALUES (...) ;
    行を貼り付けます。
  8. 以下のコマンドを実行して、アップグレードする実稼働データベースへの変更を保存します。
    # commit;
  9. 以下のコマンドを使用して、実稼働 Gateway を再起動します。
    # service ssg start
  10. SSG 設定メニューを使用して、以前と同様に実稼働データベース スキーマのアップグレードを続行します。
LDAP 認証情報を使用した Gateway へのシェル アクセスが機能しない
問題
: Gateway への SSH アクセスの認証方法として LDAP 認証情報を設定しても、ユーザが Gateway へのシェル アクセスを行うことができません。試行が失敗し、「user unknown」エラーが表示されます。(DE495542)
回避方法
: 「オプション 4 - Configure Authentication Method」に記載されているように、ガイド メニューを使用して LDAP 認証情報を設定する際、「
Which object in the LDAP will be used to find the password for users
」の部分に一時的な値を入力します。メニューの選択が完了したら、
/etc/nslcd.conf
を編集し、ユーザ パスワードの LDAP オブジェクトの場所を識別する目的の値(「ou=users」など)を入力します。これによって、設定メニューで入力した一時的な値がオーバーライドされます。値の入力後、nslcd デーモンを再起動します。
TLS 1.2 に関する AdoptOpenJDK 8u275 による JDK の回帰的問題
問題
JDK-8253368 の問題により、バックエンドへのルーティング時に、より頻繁に完全な TLS ハンドシェイクが発生します。
回避方法
  1. 接続がアクティブなまま、より長い時間有効な状態を維持できるように、アイドル状態の接続タイムアウトを増加させます。
  2. クラスタ全体のプロパティ
    io.httpsJDK8253368WorkaroundForPartialShutdown
    を設定し、これを
    true
    に設定します(デフォルト値は
    false
    です)。
キーストアの管理 - 暗号化操作に SafeNet HSM を使用するように設定できない
問題
: Gateway バージョン 10.0 CR 3 を実行しているマシンに Luna クライアント バージョン 10.2 をインストールしている Luna SafeNet HSM のお客様に影響があります。Policy Manager のキーストアの管理機能を使用して SafeNet HSM を有効化または SafeNet HSM に接続する場合、オプションとして[Prefer to use this device for all cryptographic operations]チェック ボックスをオンにすることができません。このオプションを選択する目的は、すべての暗号化操作が Luna HSM アプライアンス自体で実行されるようにすることです。
回避方法:
ありません。
プロキシ接続のタイムアウト ルーティング エラー
問題
: Gateway バージョン 10.0 CR2 のユーザに影響があります。プロキシによるルーティングのパフォーマンスが低い場合、クライアントがメッセージ ルーティングを介してプロキシに接続しようとすると、「Timeout connection waiting from pool (プールからの接続待機がタイムアウトしました)」というルーティング エラーが発生します。(DE493332)
回避方法
: 修正のため、ユーザは Gateway バージョン 10.0 CR3 以降にアップグレードするよう要求されます。
nShield HSM - レベル 3 (Strict) FIPS モードが有効な場合 Policy Manager にアクセスできない
問題
: HSM を FIPS 140-2 レベル 3 モードで動作させる必要がある nShield HSM のユーザ(nShield クライアント バージョン 12.60.x 以降を実行していて、Gateway バージョン 10.0 CR3 以降がインストールされている)に影響があります。既知の Java の問題によって発生する SSLHandshakeException エラーにより、ユーザが Policy Manager にログインできません。(DE498599)
回避方法
: nShield HSM を FIPS 140-2 レベル 3 で実行する必要があるユーザは、通知があるまで Gateway バージョンを 10.0 CR3 以降にアップグレードしないでください。
システムの再起動の問題
問題:
Gateway ノードでパッチを適用した後の起動に時間がかかる場合があります。
回避方法:
システム再起動時間を改善するには、各 Gateway ノードで以下の手順を実行します。
  1. VM のスナップショットを取得します。
  2. 以下と同じ順序で以下のコマンドを実行します。
    # cd /etc/rc.d/init.d
    # ./layer7-run-once-on-boot
    このコマンドの実行には数分かかる場合があります。
    # reboot -n
Gateway ノードがより短時間で起動します。クラスタ内のすべてのノードに対してこのタスクを繰り返します。
Gateway が SunJSSE TLS プロバイダを使用する: 認証バインド操作での時間の増加
問題:
LDAP 認証を実行する Gateway フォーム ファクタに影響します。Gateway バージョン 9.2 以降、SunJSSE はプライマリ TLS プロバイダになりました。これは、Gateway が安全なネットワークを介して LDAP プロバイダと通信するときに、LDAP ユーザ認証によって使用されます。以前の TLS プロバイダ(廃止された FIPS/BSAFEJSSE)とは異なり、SunJSSE によって実行される LDAP バインドでは、各 LDAP ユーザに対して完全な TLS ハンドシェイクが必要です。このプロセスでは、Gateway バージョン 9.1 の同じプロセスと比較して
、各ユーザの LDAP 認証バインドに約 100 ミリ
秒追加されます。(DE474013)
回避方法:
Gateway では、以前に完了または成功したバインドの許可キャッシュが提供されます。同じユーザに対する繰り返しバインドの完全 TLS ハンドシェイクのパフォーマンスへの影響を軽減するために、許可キャッシュ サイズおよび成功バインドのストレージが増加する可能性があります。
  • authCache.successCacheSize (デフォルトは 2000)
  • authCache.maxSuccessTime (デフォルトは 60000 ms)
両方のプロパティを Gateway クラスタ全体のプロパティとして設定できます。詳細については、「認証情報のキャッシュのクラスタ プロパティ」を参照してください。
キャッシュの最適なサイズは、LDAP ユーザ ベースのサイズによって異なります。成功がキャッシュされている間、成功キャッシュではユーザによるパスワードの変更や、LDAP サーバ上で無効化されることは考慮されていません。
ソフトウェア Gateway: AdoptOpenJDK 1.8.0_252 以降および Gateway バージョン 10.0
問題:
AdoptOpenJDK 1.8.0_252 以降は、ソフトウェア フォーム ファクタの Gateway バージョン 10.0 と互換性がありません。
回避方法:
AdoptOpenJDK 1.8.0_252 以降をインストールしようとしているソフトウェア Gateway ユーザは、Gateway をバージョン 10.0 CR1 以降にアップグレードする必要があります。
アウトバウンド WebSocket への接続アサーションでの接続エラー
問題:
エンドツーエンド接続のアップグレード プロセス中、および送信接続が成功した直後、Gateway にバックエンドからの以下のエラー メッセージ(アウトバウンド)が表示されます(DE467783)
com.l7tech.external.assertions.websocket.server.WebSocketOutboundHandler: インバウンドへのメッセージの送信に失敗しました: メッセージを配信できませんでした。接続が利用できなくなりました。
回避方法:
エンドツーエンド接続のアップグレードが完了すると、この問題が発生します。
MySQL 8.0 の 9.4 から 10.0 へのアップグレード
問題:
MySQL 8.0 では、NO_AUTO_CREATE_USER SQL モードが削除されました(MySQL の問題)。MySQL 5.7 のバックアップをとって MySQL 8.0 にアップグレードすると、「sql_mode」を「NO_AUTO_CREATE_USER」の値に設定できないという問題が発生します。
回避方法:
以下のコマンドを使用して、ダンプ ファイル内の「NO_AUTO_CREATE_USER」を単純なスペースで削除します。
sed -i "s/NO_AUTO_CREATE_USER//g" mysql_dump.sql
CentOS 7 の問題
Gateway バージョン 10.0 では、CentOS 7 プラットフォームがサポートされています。以下に、CentOS 7 プラットフォームに関連する既知の Gateway の問題を示します。
systemd スクリプト内の循環依存関係によって Gateway を起動できない
問題:
主に、ベース 10.0 バージョンの Gateway を実行している仮想アプライアンス(OVA) Gateway のユーザに影響があります。一部のユーザから、OVA Gateway を新しくインストールした仮想マシンにアクセスできないという問題が報告されています。これは、Gateway のネットワーク デバイスの名前変更スクリプトが、VM のプライマリ ネットワーク インターフェース「ens160」の名前を、Gateway が使用している名前「ssg_eth0」に変更できなかったことが原因である可能性があります。このエラーは、systemd サービス マネージャによって解決されるスタートアップ サービス間の循環依存関係が原因です。その解決によって、デバイスの名前変更サービスが妨げられる可能性があります(DE485529)。
回避方法:
保留中の永続的な修正が今後スケジュールされています。循環依存関係の問題による VM への接続の問題が解決されない場合、「ネットワーク展開ガイド」に記載されているネットワーク デバイスの名前変更およびセットアップ手順を実行することをお勧めします。
mysqld によるエラー ログ生成の問題を修正するために my.cnf ファイルを更新する
問題:
Layer7 API Gateway 10.0 OVA インストールでは、
my.cnf
ファイルで定義されているように、mysql エラー ログが
/var/log/mysqld.log
ではなく
/var/log/messages
に生成されます。
原因:
CentOS 7 では、systemd が MySQL サーバの起動とシャットダウンを管理します。
[mysqld_safe]
は、必要でないため、インストールされていません。ログ ファイル パスや pid ファイルなど、一部のパラメータは
my.cnf
ファイルの
[mysqld_safe]
セクションに定義されています。そのため、mysqld がエラー ログを生成していないように見える場合があります。
回避方法:
my.cnf
ファイルを編集し、
[mysqld_safe]
セクションのすべての内容を
[mysqld]
セクションに移動します。MySQL サーバを再起動します。
pid ファイル
のパラメータ行が上書きされていることを確認してください。パラメータの
[mysqld]
セクションに複数のエントリがある場合は、最後の行のみが優先され、それより前のエントリは無視されます。
AMI ゲートウェイ: ネットワーク サービスのステータスが「failed」になる
問題:
AMI Gateway (バージョン 10.0)でネットワーク デバイスのサマリと接続ステータスを表示したときに、ネットワーク サービスのステータスが「failed」と報告される場合があります。
Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: Bringing up interface eth0: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device eth0 does not seem to be present, delaying initialization. Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: [FAILED] Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: Bringing up interface ssg_eth0: [ OK ]
回避方法:
必要ありません。CentOS 7 で導入された予測ネットワーク インターフェース ネーミング スキームにより、AMI ネットワーク サービスは「ssg_eth0」(Gateway によって付けられた新しい名前)を探すときに、まず「eth0」を探します。ステータスが「OK」である「ssg_eth0」の存在をサービスが確認できる限り、「eth0」に初期ステータス「FAILED」が関連付けられていても、実際にシステム障害が発生することはありません。(DE441402)
OVA のクローン作成には手動によるパッチ適用が必要
問題:
Gateway OVA (バージョン 10.0)のクローンを作成した後、Gateway 管理者がそのクローンに SSH を実行できません。新しくクローンを展開すると、そのクローンのネットワーク アダプタ ハードウェア アドレスが変更されるため、VM は予測デバイス ネーミング スキームを使用して一意のネットワーク インターフェース名を作成します。元の OVA とクローンの名前が競合しているため、iptables のファイアウォール ルールにより、ユーザは SSH を介して OVA クローンにアクセスできなくなります。これは、CentOS 7 で Gateway OVA を実行した場合の既知の問題です。(DE441413)
回避方法:
Gateway OVA のクローンを作成する場合は、以下の操作を行ってください。
  • クローンを作成する前に iptables/ip6tables サービスを無効にします。
  • OVA のクローンを作成した後、ネットワーク設定ファイル(ifcg ファイル)で識別されているインターフェースが iptables/ip6tables に記載されているインターフェース名と一致していることを確認します。再設定の一環として
    nmcli
    コマンドを使用することもできます。例として以下の手順を参照してください。
クローンの OVA 上でデバイス名を ens160 から ssg_eth0 に変更する方法
  1. コンソールでクローンの OVA に root ユーザとしてログインします。
  2. 以下のコマンドを使用して、Gateway への利用可能な接続を一覧表示します。
    nmcli connection show
    2 つの接続が表示されるはずです。
    • 1 つの接続は、NAME が「ssg_eth0」で、DEVICE が割り当てられていません。
    • もう 1 つの接続は、NAME が「Wired connection 1」で、DEVICE 「ens160」が割り当てられています。マシン/セットアップによって、使用されている DEVICE 名が異なる可能性があります。
  3. 以下のコマンドを使用して、DEVICE が割り当てられていない接続(ssg_eth0)を削除します。
    nmcli connection delete ssg_eth0
    nmcli connection show
    コマンドを使用すると、更新を確認できます。
  4. 以下のコマンドを使用して、ens160 DEVICE が割り当てられている接続を更新します(ご使用のマシンとセットアップに適した DEVICE 名を使用してください)。
    nmcli connection modify "Wired connection 1" 802-3-ethernet.mac-address "$(cat /sys/class/net/ens160/address)" con-name "ssg_eth0" ifname "ssg_eth0"
    NAME が「Wired connection 1」であり、DEVICE 「ens160」が割り当てられている接続では、NAME が「ssg_eth0」に変更されますが、DEVICE は「ens160」として割り当てられたままです。
    nmcli connection show
    コマンドを使用すると、更新を確認できます。
  5. reboot
    コマンドを使用して OVA を再起動し、クローンの OVA に root ユーザとして再びログインします。
  6. nmcli connection show
    コマンドを使用して最新の接続を一覧表示し、NAME 「ssg_eth0」の接続に DEVICE 「ssg_eth0」が割り当てられていることを確認します。
  7. iptables をオンにします。
  8. これで、クローンの OVA に対して正常に SSH を実行できるはずです。
exited ステータス: ゲートウェイ関連のシステム サービスの意味
問題:
従来、CentOS/RHEL 6 では、init スクリプトを使用してサービスを開始および停止していました。systemd では、これらのスクリプトは systemd サービス ユニットに置き換えられています。それよりも重要なことは、新たに導入された「終了」ステータスが systemd に固有であり、CentOS 7 を初めて使用する場合には混乱を招く可能性があるということです。たとえば、サービスのステータスを確認して、サービスが実行中かどうかを把握しようとした場合に、ステータスが
Active: active (running)
ではなく
Active: active (exited)
と表示されることがあります。これは通常、systemd がサービス ユニット ファイルに指定されたコマンドを実行したものの、そのプロセスを監視する関連デーモンが見つからなかったため、実際にそのプロセスが実行されているかどうかを確認できなかったことを意味します。Gateway ではデーモンが使用されないため、CentOS 7 でサービスを確認したり実行したりすると、このステータスが表示される場合があります。(DE437214)
回避方法:
必要ありません。
Enterprise Service Manager の問題
ESM でのレポート生成が失敗する
問題:
API Gateway Enterprise Service Manager でのレポート生成が失敗します。これは OpenJDK の既知の問題です。(DE437057)
回避方法:
ありません。
Policy Manager の問題
新規ユーザの場合に Policy Manager の起動に時間がかかる
問題:
新しいユーザが作成され、さまざまな異なるロールが割り当てられた場合、管理ユーザの場合の通常の起動時間(約 2 分)と比べて、新しいユーザが Policy Manager にログインするのに最大 30 分かかる場合があります。(DE222762)(DE413957)
回避方法:
以下の手順を使用することで、ユーザのロールを削減できます。これにより、権限を検証する速度およびパフォーマンスが向上する場合があります。
  1. 新しいセキュリティ ゾーンを作成します。以下の 2 つの新しいロールが使用可能になります。
    • View X Zone
    • Manage X Zone
  2. このセキュリティ ゾーンに、ユーザ(開発者など)のグループが使用できるようにする必要があるすべてのエンティティを割り当てます。
  3. 以下のいずれかを実行します。
    • View/Manage X Zone ロールのみをユーザ ロールに割り当てます。
    • 新しいグループを作成し、View/Manage X Zone ロール、およびその他の必要な事前定義済みロールをこのグループに割り当てます。ユーザ ロールにこの新しいグループのみを割り当てます。
  4. クラスタ全体のプロパティを設定することでロールの自動割り当てを無効化して、ユーザのロールが自動的に増加しないようにします。
    rbac.autoRole.managePolicy.autoAssign=false
    rbac.autoRole.manageProvider.autoAssign=false
    rbac.autoRole.manageService.autoAssign=false
Policy Manager が正しく表示されない
問題:
一部の高解像度モニタでは、Policy Manager が正しく表示されない場合があります。小さなフォントや判読不能な行など、表示上の問題が発生した場合は、実行可能ファイルの高 DPI スケーリング動作をオーバーライドしてみてください。(DE211450)
回避方法:
Policy Manager の概要」の「トラブルシューティング」で高 DPI スケーリング動作をオーバーライドする手順を参照してください。
Azure MySQL データベースを使用して Azure で Gateway をアップグレードすると、構文エラーが発生する
問題
: お客様によっては、Azure MySQL データベースを使用して Gateway をアップグレードしたときに、次のエラーが発生する場合があります。
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '@'localhost'' at line 1.
(DE399413)
回避方法
  1. Azure MySQL データベースをバックアップします。
  2. 特権シェルで、以下のコマンドを入力します。
    /opt/SecureSpan/JDK/bin/java -jar /opt/SecureSpan/Gateway/runtime/lib/liquibase-3.2.2.jar --driver=com.mysql.jdbc.Driver --classpath=/opt/SecureSpan/Gateway/runtime/lib/mysql-connector-java-5.1.46.jar --changeLogFile=/opt/SecureSpan/Gateway/config/etc/db/ssg.xml --url=jdbc:mysql://gatewaydb.mysql.database.azure.com:3306/ssgvortx --username='[email protected]' --password='x' update
    「Liquibase Update Successful」というメッセージが返されます。
  3. Gateway のバージョンが 10.0 にアップグレードされたことを確認するには、MySQL で以下のコマンドを入力します。
    select * from ssg_version
    current_version に対してバージョン 10.0.00 が返されない場合は、以下のように入力します。
    update ssg_version set current_version = '10.0.00';
Cloud Foundry にインストールされているコンテナ Gateway が起動時にエラー ログを表示する
問題
: Gateway の起動時に、Cloud Foundry 上で Gateway の初期設定に関するログがエラーとして表示されます。(DE359636)
SSH ルーティング時の接続タイムアウト
問題
Route via SSH2 アサーションで「SFTP」プロトコルが選択されている場合、接続タイムアウトがアサーションで指定されている値の 2 倍になります。(DE215650)
回避方法:
タイムアウトを目的の値の 1/2 に減らします。
カプセル化アサーションを使用する際に、コンテキスト変数 ${request.time} が誤った時間を返す
問題:
カプセル化アサーションの基礎となる(「バッキング」)ポリシーで
${request.time}
が使用されると、誤った値が返されます
(DE305223)。
${service.*} プレフィックスが付いたコンテキスト変数がグローバル スコープとなっている
問題:
「service」プレフィックスを持つコンテキスト変数が、本来あるべきローカル スコープではなく、グローバル スコープ変数になります。(DE293047)
例:
  • グローバル ポリシーで設定されるコンテキスト変数 ${service.AAA} の値は、サービス ポリシーから取得できます。サービス ポリシーからアクセスする場合には、結果として値が空であることが予期されます。
  • カプセル化されたアサーションの基礎となるポリシー フラグメントにおいて設定されたコンテキスト変数 ${service.BBB} の値は、サービス ポリシーから取得できます。変数をパラメータとして返す設定をしていない場合、サービス ポリシーからアクセスをすると変数は空になります。
回避方法:
コンテキスト変数をグローバル スコープにしないようにするには、「service」以外のプレフィックスを使用します。
OAuth フォルダの削除時に依存関係エラーが発生する
問題:
カプセル化されたアサーションが含まれている OAuth ポリシーを削除すると、Policy Manager で依存関係エラーがトリガされます。これらのエラーは一括では確認できず、削除をキャンセルすることもできません。(DE222685)
回避方法:
この問題を回避するには、「トラブルシューティング: 問題と解決方法」の「問題: OAuth ポリシーを削除すると依存関係エラーが発生する」を参照してください。
[Sending Reply to Specified Queue]を使用する場合、Gateway によって例外がスローされる
問題:
MQ 8.0 用の[Sending Reply to Specified Queue]受信オプションを使用する場合、Gateway が例外をスローします。(DE386344)
Gateway ログ内の誤った警告メッセージ
問題:
Gateway のログに、以下のような警告が含まれています。
WARNING 1 com.l7tech.server.policy.PolicyCacheImpl: 3255: Policy "Google Auth Code Extension" (#d095d9a4c56c975b34c64db5a6741dd0) contains an unlicensed assertion: Unknown assertion: RetrieveOAuth2Token
RetrieveOAuth2Token アサーションは、特別なライセンスを必要としない、OAuth Toolkit の一部です。標準的な Gateway ライセンスのみが必要となります。(DE317426)
回避方法:
必要ありません。RetrieveOAuth2Token アサーションが実際に存在し、通常通り機能しています。Gateway の起動時のライセンス チェックの段階で、内部のタイミングの問題が発生することによって、誤ったログ メッセージが引き起こされます。このログ メッセージは無視して問題ありません。
復元後のファイル権限
問題:
ssgrestore.sh
コマンドを使用して Gateway が復元された後、一部のファイル権限が正しく復元されません。これにより、Policy Manager が Gateway に接続できません。(DE221036)
回避方法:
Gateway のトラブルシューティング」の「問題: 復元後に Gateway が正しく実行されない」を参照してください。
古い Oracle サーバを使用している場合の新しいデータベースの作成に関する問題
問題:
この問題は、Oracle X5-2 より前のサーバにのみ発生します。バージョン 9.3 を使用して、古い Oracle サーバ上に新しいデータベースを作成する場合、以下のエラーが発生します(DE333430)。
Configuration Results
---------------------
An error occurred during configuration.
Unexpected error saving configuration 'Could not send Message.'
Would you like to re-configure? [Yes]:
回避方法:
このエラー メッセージが表示された場合、再設定を求められたら「
No
」と入力します。次に、メニューからオプション
3
(Configure the Layer7 API Gateway)を選択し、オプション
1
4
の設定を完了して Gateway を設定します。
JSON Path アサーションが null 値でエラーを返す
問題
null
(大文字と小文字が区別される)値を含む JSON 式を評価する場合、アサーションが失敗します。(DE384413)
回避方法:
JSON Path Expression V2 アサーションを使用します。
Luna HSM でキーの生成が失敗する
問題:
秘密鍵のプロパティの場合。(DE305070 DE314879)
回避方法:
「楕円曲線」キー タイプ以外のキー タイプを使用します。
ロールの管理のパフォーマンスに関する問題
問題:
ロールの管理のパフォーマンスとスピードは、多数の(500 より多い)カスタム ロールが作成され、各ロールが多数(200 ~ 300)の権限を持っている場合に低下する場合があります。(DE326081)
回避方法:
ロールと権限の数を増やしすぎないようにします。
Gateway 間の移行の問題
問題:
アップグレード後に移行の問題が発生する場合があります。リリース 9.1 では、新しい「gateway-hazelcast」 FIREWALL_RULE が導入されます。このルールがまだ存在していない場合、再起動時に Gateway に自動的に追加されます。このエンティティは、Gateway ごとに一意の ID で作成されます。バンドルをインポートしようとする場合、「gateway-hazelcast」 FIREWALL_RULE に対するマッピングは、409 の競合を避けるために、「MapBy:name」である必要があります。(DE211367)
回避方法:
以下のように、バンドルのエクスポート中に作成されるバンドル ファイルを変更します。
以下の行を検索します。
<l7:Mapping action="NewOrExisting" srcId="
<unique_ID>
" srcUri="http://
<IP_address>
:8080/restman/1.0/firewallRules/
<identifier>
" type="FIREWALL_RULE"/>
次のように変更します。
<l7:Mapping action="NewOrExisting" srcId="
<unique_ID>
" srcUri="http://
<IP_address>
:8080/restman/1.0/firewallRules/
<identifier>
" type="FIREWALL_RULE">
<l7:Properties>
<l7:Property key="
MapBy
">
<l7:StringValue>
name
</l7:StringValue>
</l7:Property>
</l7:Properties>
</l7:Mapping>
Look Up Item by Value アサーションでの複数値の変数のエラー
問題:
複数値の変数に同じ値が複数回含まれている場合、Look Up Item by Value アサーションが失敗します。(DE305234)
以下に例を示します。
Set Context Variable fave as String to: banana
Set Context Variable fruits as String to: apple,banana,pear,banana
Split variable fruits into fruitsalad on ","
Look Up Item by Value: find item ${fave} within ${fruitsalad}; output index to ${index}
Return Template Response to Requestor -- ${index}
この場合、「1,3」が返されません。ただし、ssg_0_0.log ファイルには、以下のような INFO エントリが記録されます。
com.l7tech.external.assertions.xmlsec.server.ServerIndexLookupByItemAssertion: 6: More than one value was matched. Exception caught!
回避方法:
以下のサンプル回避策ポリシーを使用します。
回避策ポリシーの使用方法
  1. ご使用のコンピュータに .xml ファイルをダウンロードします。
  2. ポリシー ツールバーの
    [Import Policy]
    をクリックして、ポリシーを Policy Manager にインポートします。詳細については、「ファイルからのポリシーのインポート」を参照してください。
不定期の送信 JMS リクエスト処理エラー
問題:
NamingException に関する既知の問題により、送信 JMS メッセージが正しく処理されず、以下のエラーが返されます。
com.l7tech.server.policy.assertion.ServerJmsRoutingAssertion: 4: Error in outbound JMS request processing: Something already bound at (queue-name). Exception caught!
しかし、メッセージが再処理されると、それらは正常に動作します。(DE304792)
プロシージャ名にハイフンを使用する場合の JDBC Query アサーションの実行エラー
問題:
Perform JDBC Query アサーションを設定するときに、ストアド プロシージャ名にハイフンを使用すると、JDBC の命名規則に準拠していないためクエリが失敗します。(DE309730)
回避方法:
プロシージャ名にハイフンを使用しないでください。
ブートストラップ/バンドル フォルダからロードされたか、RESTman エンドポイントに送信された場合、特別な目的のない秘密鍵が作成される
問題:
コンテナ Gateway のブートストラップ/バンドル フォルダを介して RESTman バンドルで定義された特別な目的を持つ秘密鍵を作成しようとすると、その秘密鍵は作成されますが、特別な目的(デフォルト CA など)が設定されません。(DE320421)
Java Web Start の Policy Manager を使用すると[Published Service Properties]ダイアログ ボックスを開くのに時間がかかる
問題:
Java Web Start バージョンの Policy Manager ブラウザ クライアントを使用しているときに、初めて[Published Service Properties]ダイアログ ボックスを開くと、通常よりも時間がかかります。(DE326621)
回避方法:
ありません。ブラウザ クライアントでは、[Published Service Properties] ダイアログ ボックスの最初の呼び出し時に、追加の .jar ファイルをダウンロードする必要があります。2 回目以降に開く際には、通常のスピードに戻ります。
Gateway が FIPS モードであるときの証明書の取得
問題:
Gateway が FIPS モード(クラスタ プロパティ security.fips.enabled = true)の場合、
Add Certificate ウィザード
が[Retrieve via SSL Connection (HTTPS or LDAPS URL)]オプションを使用したサードパーティ証明書の取得に失敗します。(DE211158)
回避方法:
  1. 外部の手段を使って、証明書ファイルを取得またはダウンロードします。たとえば、以下の OpenSSL コマンドを使用することができます。
    # echo | openssl s_client -connect host.host:port 2>/dev/null | openssl x509 -outform PEM > cert.pem
  2. [Tasks]-[Certificates, Keys, and Secrets]-[Manage Certificates]-[Add]-[Import from a file]
    に移動して、Gateway に証明書をインポートします。
HTTP(S) アサーションを介したルートに予期せぬ失敗が発生する
問題:
[HTTP(S) Routing Properties]の[Other]タブには、[Never fail as long as target returns an answer]コントロールがあります。以下のシナリオでは、応答が返される場合でもアサーションが失敗することがあるという既知の問題があります。
  • [Security]タブで、[Service Authentication]が[Use HTTP Credentials from Request]に設定されている。
  • バックエンド サービスから 401 HTTP エラーが返される。(DE215522)
回避方法:
このシナリオでアサーションの失敗を回避するには、[Service Authentication]の方式として代わりに[Specify HTTP Credentials]を使用します。リクエストからのコンテキスト変数(例:
${request.username}
${request.password}
)としてユーザ名およびパスワードを指定します。
Siteminder のクラスタ全体のプロパティの検証の警告
siteminder.session.generateCookieString のクラスタ全体のプロパティの検証タイプが不適切に設定されていたため、Gateway の起動時に次の警告メッセージが表示されます。「WARNING 973 com.l7tech.util.ConfigFactory$DefaultConfig: Ignoring unknown type '(?i)true|false' for validation of property ‘siteminder.session.generateCookieString’」。これによって機能の問題が発生することはありません。
Azure MySQL データベースを使用して Azure で Gateway をバージョン 9.3 から 9.4 にアップグレードすると、構文エラーが発生する
これは、Microsoft Azure クラウドで Gateway イメージを実行している場合にのみ当てはまります。
問題
: お客様によっては、Azure MySQL データベースを使用して Gateway をバージョン 9.3 から 9.4 にアップグレードしたときに、以下のエラーが発生することがあります。
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '@'localhost'' at line 1.
(DE399413)
回避方法
  1. Azure MySQL データベースをバックアップします。
  2. 特権シェルで、以下のコマンドを入力します。
    /opt/SecureSpan/JDK/bin/java -jar /opt/SecureSpan/Gateway/runtime/lib/liquibase-3.2.2.jar --driver=com.mysql.jdbc.Driver --classpath=/opt/SecureSpan/Gateway/runtime/lib/mysql-connector-java-5.1.46.jar --changeLogFile=/opt/SecureSpan/Gateway/config/etc/db/ssg.xml --url=jdbc:mysql://gatewaydb.mysql.database.azure.com:3306/ssgvortx --username='[email protected]' --password='x' update
    「Liquibase Update Successful」というメッセージが返されます。
  3. Gateway のバージョンが 9.4 にアップグレードされたことを確認するには、MySQL で以下のコマンドを入力します。
    select * from ssg_version
    current_version に対してバージョン 9.4.00 が返されない場合は、以下のように入力します。
    update ssg_version set current_version = '9.4.00';