トラブルシューティング

一般的なトラブルシューティングとログの検査

バージョン2.20.0以降におけるRBIの問題について

RBIセッションが黒い画面のまま表示されたり、エラーが発生したりする場合は、AppArmorおよびSeccompのファイル設定を更新する必要があります。

バージョン2.20.0以降では、リモートブラウザ分離 (RBI) をサポートするための設定変更が必須となっています。手順の詳細は、バージョン2.20.0のリリースノートページに記載されています。

ログを確認

動作が想定どおりでない場合は、最初に必ずログを確認することをお勧めします。Guacamoleやguacdがログに記録したメッセージの中には、障害の内容を正確に説明している情報や、少なくとも問題解決に向けた正しい方向を示してくれる情報があるはずです。

Dockerの自動インストールメソッド

Dockerの自動インストールメソッドを使用してKeeperコネクションマネージャーをインストールした場合は、kcm-setup.runスクリプトを使用してログファイルを確認できます。

すべてのコンテナの最近のログをすべて表示するには以下を実行します。

sudo ./kcm-setup.run logs

ログをリアルタイムで追跡するには、-fフラグを使用します。

sudo ./kcm-setup.run logs -f

以下で解説するように、コンテナ固有のログを監視して特定の問題をトラブルシューティングできます。

guacdログ

  • コマンド: sudo ./kcm-setup.run logs guacd

  • 用途

    • 接続の問題のトラブルシューティング

    • プロトコル固有のエラーのデバッグ (RDP、VNC、SSH)

    • セッションの詳細とパフォーマンス指標の分析

    • 接続の試行と結果の調査

    • guacdに関連するエラーとスタックトレースの確認

guacamoleログ

  • コマンド: sudo ./kcm-setup.run logs guacamole

  • 用途

    • ユーザー認証の問題のデバッグ

    • ユーザーセッションでの操作の監視

    • ウェブリクエストの処理と応答のトラブルシューティング

    • 構成の読み込みと解析結果の調査

    • ウェブアプリケーションに関連するエラーとスタックトレースの確認

    • HTTP クエストとレスポンスのログの確認

dbログ

  • コマンド: sudo ./kcm-setup.run logs db

  • 用途

    • データベース接続の問題のトラブルシューティング

    • クエリ実行の問題のデバッグ

    • トランザクション管理の監視

    • データベースの起動とシャットダウンのログの調査

    • データベースのユーザー認証結果の確認

    • パフォーマンス指標の分析

    • バックアップと復元操作の確認

    • データベースに関連するエラーとスタックトレースの確認

sslログ

  • コマンド: sudo ./kcm-setup.run logs ssl

  • 用途

    • SSL/TLS 接続の問題のトラブルシューティング

    • SSL証明書の読み込みと検証のデバッグ

    • 安全な接続の確立と終了の調査

    • HTTPからHTTPSへのリダイレクトログの確認

    • ハンドシェイクと暗号化の詳細の表示

    • SSL/TLS に関連するエラーとスタック トレースの確認

    • 構成結果の分析

    • クライアントとサーバーの接続の詳細を確認

個々のログファイルを確認するには、以下のようにログ出力のタイプを指定してください。

sudo ./kcm-setup.run logs guacd
sudo ./kcm-setup.run logs guacamole
sudo ./kcm-setup.run logs db
sudo ./kcm-setup.run logs ssl

Dockerイメージをくまなく調べたい場合は、以下のコマンドで始めます。

sudo docker-compose -p "kcm" -f /etc/kcm-setup/docker-compose.yml ps
sudo docker ps
sudo docker exec -it <container ID> /bin/bash
etc...

Dockerカスタムインストールメソッド

Dockerカスタムインストールメソッドを使用してインストールした場合は、組み込みのdockerおよびdocker-composeのログコマンドを使用できます。

例えば、docker-composeを使用する場合は以下のとおりです。

sudo docker-compose logs guacd
sudo docker-compose logs guacamole
sudo docker-compose logs db
sudo docker-compose logs ssl

通常のdockerコマンドを使用し、「docker ps」でコンテナIDを見つけます。

sudo docker ps

CONTAINER ID   IMAGE ...
2aca97c20f5c   keeper/guacamole-ssl-nginx ...
73538e4af0b7   keeper/guacamole-db-mysql ...
44ab1b150bc9   keeper/guacd ...
85e79b62f058   keeper/guacamole ...

続いて、特定のコンテナを参照してログを取得できます。

sudo docker logs 44ab1b150bc9
sudo docker logs 85e79b62f058
sudo docker logs 73538e4af0b7
sudo docker logs 2aca97c20f5c

接続の問題

Keeperコネクションマネージャーが起動中に異常停止している場合、またはどのホストにも接続できない場合は、Linuxマシンが乱数生成に十分なエントロピーを生成できるかどうかを直ちに確認する必要があります。この問題を解決するために、haveged パッケージのインストールをお勧めします。

これらのパッケージは、以下のコマンドを使用してインストールできます (CentOS/RHEL)。

sudo yum install epel-release
sudo yum install haveged
sudo systemctl start haveged
sudo systemctl enable haveged

Docker自動インストールのデバッグ

kcm-setup.run スクリプトで、KCM_SETUP_DEBUG 環境変数がサポートされるようになりました。この変数を有効にすると、詳細モードが有効になり、実行されたすべてのコマンドとその出力が表示されます。このデバッグ出力は KCM_SETUP_DEBUG の値に応じてターミナルに直接表示したりファイルに保存したりできます。

export KCM_SETUP_DEBUG=/path/to/file
sudo -E ./kcm-setup.run

詳細ログ

LOG_LEVEL

この変数はオプションであり、表示されるログメッセージの最低レベルを指定します。詳細度の昇順で、有効な値は「error」、「warn」、「info」、「debug」、「trace」です。

デフォルトのログ レベルは「info」です。

管理

LDAPとデータベースを連携する場合、LDAPユーザーのリストを取得できない

ご利用の (管理用) Keeperコネクションマネージャーユーザーカウントに、LDAPユーザーのリストを取得する権限があることを確認します

KeeperのLDAPサポートは、LDAPディレクトリ側で適用されているアクセス制御 (パーミッション) を迂回することはできません。つまり、Keeperコネクションマネージャーの管理画面上でLDAPユーザーを一覧表示できるかどうかは、Keeperの「検索用」LDAPユーザーにその権限があるかどうかや、データベースユーザーにその管理権限があるかどうかに関係なく、実際にログインしているLDAPユーザー自身が、その一覧表示権限を持っているかどうかによって決まります。

自分のLDAPアカウントにその権限があるか不明な場合は、実際にそのアカウントを使ってLDAPディレクトリにバインドし、検索クエリを実行してみるのが有効です。このような検索には、標準的なツールであるldapsearchを使用するのが一般的です。

$ ldapsearch -x -LLL -H ldap://YOUR_LDAP_SERVER -D "YOUR_LDAP_DN" -W -b USER_BASE_DN "(objectClass=*)"

ここで、YOUR_LDAP_SERVER はLDAPサーバーのホスト名またはIPアドレス、YOUR_LDAP_DN はLDAP内における自身のアカウントの完全なDN、USER_BASE_DN は対象となるユーザーが格納されているLDAPディレクトリのベースDNを指します（これは、docker-compose.yml ファイルの LDAP_USER_BASE_DN プロパティ、またはコンテナ内の /etc/guacamole/guacamole.properties にある ldap-user-base-dn プロパティで指定されている値です）。

Keeperコネクションマネージャーへのサインインにデータベース認証情報ではなく、LDAP認証情報を使用していることを確認します

データベース内のユーザーアカウントにパスワードが設定されており、そのパスワードをLDAPアカウントのものではなく使用した場合、認証はデータベース側でのみ成功します。これは有効な認証結果ですが、そのセッションではLDAPオブジェクトへのアクセス権がありません。LDAP内のユーザーなどのオブジェクトにアクセスするには、LDAPディレクトリが受け入れる認証情報でログインする必要があります。

LDAP関連のプロパティの後に空白が付いていないか確認します

Javaの .properties ファイルでは、プロパティ値の前にある空白には特別な意味はありませんが、最初の空白以外の文字以降は、たとえ空白であってもすべてプロパティ値の一部として扱われます。

docker-compose ファイル内のLDAP関連のプロパティ (結果としてコンテナ内の /etc/guacamole/guacamole.properties に反映される内容) がすべて正しく見える場合でも、値の末尾に不要な空白が紛れ込んでいないかを必ず確認してください。

LDAP関連プロパティの末尾に空白が含まれていると、クエリが失敗したり、成功しているように見えるクエリの結果をGuacamoleが誤って解釈する原因となる可能性があります。

「guacadmin」 (または現在のユーザー) のパスワードを変更できない

自分のパスワードの変更には、管理ユーザーエディタではなく、[ユーザ設定] インターフェースを使用します

Keeperコネクションマネージャーでは、ユーザーのパスワードを変更する方法が2つ用意されています。1つは他のユーザーのパスワードを変更するためのユーザー編集画面、もう1つは自分の現在のパスワードを確認したうえで変更する [ユーザ設定] 画面です。

このうち、現在のパスワードを確認する機能があるのは [ユーザ設定] のみであるため、自分自身のパスワードを変更する場合、Keeperが許可するのはこの方法だけです。[User Editor] 画面から自分のパスワードを変更しようとすると、権限が拒否されます。

管理者が [ユーザ設定] 画面にアクセスするには、[設定] を開いて [ユーザ設定] を選択してください。

問題のユーザーが自分のパスワードを変更する権限を持っていることを確認します

Keeperコネクションマネージャーデータベース内で定義されたユーザーアカウントには、自分自身のパスワードを変更する権限が最初から付与されているとは限りません。自分のパスワードを更新する権限は、管理者によって明示的に付与される必要があります。

管理者として新しく作成したユーザーに自分のパスワードを変更させたい場合は、ユーザー編集画面内で [自身のパスワードの変更:] の権限にチェックを入れてください。

リモートデスクトップの到達性と動作

RDPでWindowsに接続できない場合

セキュリティ方式を指定する

最近のWindowsでは、標準でNLA (Network Level Authentication) が有効になっており、これはRDP専用のセキュリティ方式で、より強力な暗号化を使用し、デスクトップセッションを開始する前に認証を行います。

WindowsのRDPサーバーへの接続が失敗する場合は、接続設定で [セキュリティモード:] に [NLA] または [TLS] を選択してみてください。また、ユーザー名、パスワード、ドメイン (必要な場合) をあらかじめ入力していない場合、接続時にKeeperから入力を求められます。

一方、古いバージョンのWindowsではNLAやTLSがサポートされていないことがあり、その場合は [RDP] を選ばないと接続時のセキュリティ交渉が失敗する可能性があります。

RDPサーバー証明書の検証を無効にする

NLA (Network Level Authentication) と TLS のセキュリティモードは、どちらもクライアント側でRDPサーバーの証明書を検証する仕組みを備えています。しかし、多くのWindowsサーバーでは自己署名証明書が使用されており、これらは信頼された認証局によって署名されていないため、検証が行えません。

証明書を信頼された認証局で検証できない場合、KeeperはRDP接続を拒否します。

この問題を回避するには、接続設定内の [サーバ証明書を無視:] オプションを有効にすることで、証明書の検証をスキップするよう個別に設定することができます。

WindowsファイアウォールのルールによってguacdからのRDP接続がブロックされているか確認します

Windowsファイアウォールは、ローカル設定やグループポリシー (GPO) によって、RDP接続の受信をブロックするよう構成されている場合があります。対象のWindowsマシンが過去にRDP経由でアクセスされていた場合でも、特定のサブネットからの接続のみ許可されており、Keeperコネクションマネージャーサーバーがそのサブネット外にあると、RDP接続がブロックされることがあります。

このような場合は、Keeperコネクションマネージャーサーバー (またはその所属するサブネット) からのRDP接続を許可するように、Windowsファイアウォールの設定を見直す必要があります。なお、Windowsサーバーをインターネット上に公開する必要はありません。

RDPでドライブのリダイレクトを使用したファイル転送が機能していない

ドライブのパスが、「guacd」ユーザーまたは「guacd」グループが書き込み可能なディレクトリを指していることを確認します

Keeperコネクションマネージャーのパッケージは、guacdのみにアクセスを許可すべきファイルの制御を行うために、guacdユーザーおよびグループを作成します。

RDPのドライブリダイレクト機能を構成する場合、指定したドライブパスのディレクトリに対して、このユーザー (またはグループ) に書き込み権限が付与されていないと、guacd はそのディレクトリ内のファイルを読み書きできません。これは、guacd がリダイレクトされたドライブをエミュレートするために必要です。

RDP接続用のドライブパスとして使用する任意のディレクトリには、適切なアクセス権と所有者の設定を行ってください。

$ sudo chown -R root:guacd /path/to/directory
$ sudo chmod 770 /path/to/directory

HTTPプロキシ使用時におけるKeeperコネクションマネージャー (KSM) への接続問題

CATALINA_OPTSを参照

前へログイン試行のプロパティ次へ接続のインポート

最終更新