トラブルシューティング
一般的なトラブルシューティングとログの検査
Last updated
一般的なトラブルシューティングとログの検査
Last updated
動作が想定どおりでない場合は、最初に必ずログを確認することをお勧めします。Guacamoleやguacdがログに記録したメッセージの中には、障害の内容を正確に説明している情報や、少なくとも問題解決に向けた正しい方向を示してくれる情報があるはずです。
Dockerの自動インストールメソッドを使用してKeeper Connection Managerをインストールした場合は、kcm-setup.runスクリプトを使用してログファイルを確認できます。
個々のログファイルを確認するには、以下のようにログ出力のタイプを指定してください。
Dockerイメージをくまなく調べたい場合は、以下のコマンドで始めます。
Dockerカスタムインストールメソッドを使用してインストールした場合は、組み込みのdockerおよびdocker-composeのログコマンドを使用できます。
例えば、docker-composeを使用する場合は以下のとおりです。
通常のdockerコマンドを使用し、「docker ps」でコンテナIDを見つけます。
続いて、特定のコンテナを参照してログを取得できます。
Keeper Connection Managerが起動中に異常停止している場合、またはどのホストにも接続できない場合は、Linuxマシンが乱数生成に十分なエントロピーを生成できるかどうかを直ちに確認する必要があります。この問題を解決するために、havegedパッケージのインストールをお勧めします。
これらのパッケージは、以下のコマンドを使用してインストールできます（CentOS/RHEL）。
サーバーがインターネットにアクセスできることを確認します
ネットワークとサーバーの構成によっては、インターネットにアクセスできない場合があります。このような場合、リポジトリを提供しているサイトに到達できず、パッケージをダウンロードできなくなります。ネットワーク/サーバーの設定を調整して、リポジトリにアクセスできるようにする必要があります。また、独自のリポジトリのミラーセットを組織内に保持している場合は、Keeperのリポジトリをミラーリングするように設定し、サーバーをミラーサイトに向けてください。
ファイアウォールがアクセスをブロックしていないことを確認します
CentOSとRHELにはデフォルトでファイアウォール（firewalld）が付属しており、通常はSSH用のポート22への着信接続のみを許可します。システムでfirewalldが有効になっていて、ポート8080にアクセスしたい場合は、一時的にファイアウォールを無効にするか（想定通りに機能しているかテストしているだけの場合）、ポート8080への直接アクセスを許可する（ネットワーク上の別のサーバーがSSLターミネーションを提供し、このサーバーが公開されていない場合）必要があります。
ファイアウォールを一時的に無効にする手順は以下のとおりです。
ポート8080への直接アクセスを許可する手順は以下のとおりです。
問題のサーバーが到達可能であることを確認します
サーバーがプライベートネットワーク上にある場合、テストに使用しているマシンがそのネットワークに到達できないだけかもしれません。同じネットワーク内のマシンに移動してテストを実行したり、ネットワーク間に一時的なトンネルやブリッジを確立したりしてサーバーに到達できるようにする必要があるかもしれません。
Tomcatが確かに実行されていることを確認します
Apache Guacamoleウェブアプリケーションは、Apache Tomcatを使用して実行されます。TomcatのインストールはKeeper Connection Managerのインストール手順の一部であり、Keeper Connection Managerの一部としてインストールされたGuacamoleウェブアプリケーションに到達できるように、Tomcatサービスが実行されている必要があります。Tomcatが実行されているかどうかが不明な場合、最も簡単な確認方法はsystemctlを使用することです。
Tomcatが実行されていない場合、ポート8080経由でウェブアプリケーションにアクセスできるようにするには、Tomcatを起動する必要があります。また、サーバーの再起動後にサービスがオンラインに戻るように、起動時にサービスが自動的に開始されるように設定する必要もあります。
Tomcatを手動で起動する手順は以下のとおりです。
サーバーの次回起動時にTomcatが自動的に開始するように設定する手順は以下のとおりです。
ウェブアプリケーション（guacamole.war）がデプロイされていることを確認します
完全にサポートしているのはApache Tomcatのみですが、Keeper Connection Managerに含まれるパッケージは、Apache Tomcatの使用を想定していません。そのため、ウェブアプリケーション（guacamole.war）を含むファイルは、Tomcatのインストール後に手動でデプロイする必要があります。ウェブアプリケーションがデプロイされていない場合、Tomcatは8080ポートへの接続を受け入れますが、Guacamoleにアクセスしようとするとエラーを報告します。
このウェブアプリケーションは、インストール手順に記載されているように、/var/lib/tomcat/webapps内に/opt/keeper/share/guacamole/guacamole.warへのシンボリックリンクを作成することによってデプロイされます。正しくデプロイされれば、リンクの名前がアプリケーションの指すファイルと異なっていても、/var/lib/tomcat/webappsのディレクトリリストには、guacamole.warへのシンボリックリンクが表示されるはずです。たとえば、「guacamole」としてデプロイした場合は、以下のようになります。
または、ルートパスにデプロイした場合は、以下のようになります。
ファイアウォールがアクセスをブロックしていないことを確認します
CentOSとRHELにはデフォルトでファイアウォール（firewalld）が付属しており、通常はSSH用のポート22への着信接続のみを許可します。システムでfirewalldが有効になっており、同じシステムを使用してSSLターミネーションを提供している場合は、標準のHTTPSポート（443）への直接アクセスを許可する必要があります。ポート443への直接アクセスを許可する手順は以下のとおりです。
サーバーがデプロイのSSLターミネーションとして機能する場合は、ポート8080への直接アクセスを公開する必要のないことにご注意ください。ポート8080は、ローカルにのみ解放し、プロキシによって厳密に内部で使用されるようにする必要があります。
SELinuxがTomcatへのプロキシ接続を拒否していないか確認します
SELinuxシステムはデフォルトでは、Apache HTTPサーバーとNginxの両方に対し、発信ネットワーク接続（Apache Tomcatの内部インスタンスへのTCP接続など）の確立を禁止します。このような場合、SELinuxの監査ログ（/var/log/audit/audit.log）内にAVC拒否が表示されることがあり、これらの接続を許可するようにSELinuxを設定するには、httpd_can_network_connectブール値を「1」に設定する必要があります。
リバースプロキシが動作していることを確認します
パッケージ化の業界標準に従い、Apache HTTPサーバーが含まれるパッケージもNginxが含まれるパッケージも、デフォルトでは対応するサービスを開始しません。これらは手動で開始し、起動時に自動的に開始するように手動で設定する必要があります。リバースプロキシが動作していない場合、ポート443で待ち受けるサービスがなくなり、接続はタイムアウトするか、完全に拒否されます。
Apache HTTPサーバーを開始し、起動時に自動的に開始するように設定する手順は以下のとおりです。
NGINXを開始し、起動時に自動的に開始するように設定する手順は以下のとおりです。
「tomcat」ユーザーが「guacamole」グループに属していることを確認します
Keeper Connection Managerパッケージは、「guacamole」グループを作成して、Apache Guacamoleウェブアプリケーションのみが読み取り可能にする必要のあるファイルへのアクセスを制御します。/etc/guacamole/guacamole.propertiesのようなGuacamole固有の設定ファイルでは、rootおよび「guacamole」グループのメンバーのみが読み取りアクセス権を持つように権限を設定します。Guacamoleウェブアプリケーションを実行するのはApache Tomcatであり、Tomcatサービスは「tomcat」ユーザーとして実行されるため、「tomcat」ユーザーは「guacamole」グループのメンバーである必要があります。
このコマンドを実行しないと、Guacamoleは自身の設定ファイルを読み取ることができず、ウェブアプリケーションの起動は失敗します。
SELinuxがデータベースへのアクセスを拒否していないか確認します
SELinuxシステムはデフォルトでは、Apache Tomcatによるデータベースへの発信ネットワーク接続（ローカルデータベースインスタンスへの接続など）の確立を禁止します。このような場合、SELinuxの監査ログ（/var/log/audit/audit.log）内にAVC拒否が表示されることがあり、これらの接続を許可するようにSELinuxを設定するには、tomcat_can_network_connect_dbブール値を「1」に設定する必要があります。
データベース初期化スクリプトが実行されていない可能性があります
Apache Guacamoleのデータベースは、搭載されているSQLスクリプトを使用して手動で初期化する必要があります。これらのスクリプトが実行されていない場合、Guacamoleに必要なテーブルは存在せず、これらのテーブルを照会しようとすると失敗します。MySQLをご使用の場合は、実際にMySQLの初期化スクリプトを記載どおりに実行したことを確認します。PostgreSQLをご使用の場合は、記載どおりにPostgreSQL初期化スクリプトを実行したこと、および必要なデータベース権限を付与する前に実行したことを確認します。
（PostgreSQLをご使用の場合）PostgreSQLの設定が「Ident」認証を想定するようになっているかを確認します
PostgreSQLがApache Guacamoleと同じサーバーにローカルでインストールされている場合、PostgreSQLのデフォルト設定では、Guacamoleによるユーザー名とパスワードを使用した認証が禁止されます。PostgreSQLが認証に使用するメカニズムは、データベース接続のソースによって異なります。PostgreSQLのデフォルト設定では、ユーザー名とパスワードによる認証ではなく、「Ident」認証が想定されているため、GuacamoleはPostgreSQLに接続できないことになります。
/var/lib/pgsql/data/pg_hba.confの内容を確認し、IPv4またはIPv6のループバックアドレスが「Ident」に関連付けられた1つまたは複数の行を探します。
見つかった場合は、identキーワードをmd5に変更して、これらのアドレスからのユーザー名/パスワード認証を許可する必要があります。
その後、これらの変更を適用するためにPostgreSQLを再起動する必要があります。
（MySQLをご使用の場合）MySQLにデフォルトの匿名ユーザーが設定されているか確認します
MySQLまたはMariaDBがApache Guacamoleと同じサーバーにローカルでインストールされている場合、MySQLとMariaDBの認証の処理方法により、デフォルトの設定ではGuacamoleによる認証ができない場合があります。同じホスト名/アドレスに対して、匿名ユーザーが定義されている場合、同じホスト名/アドレスからの非匿名ユーザーとパスワードを使用した認証は失敗します。
これは、MySQLユーザーテーブルを直接照会することで確認できます。
上記のクエリの結果に含まれるユーザー名が空のユーザーはすべて匿名ユーザーであり、認証が成功しない可能性があります。
これらのユーザーを削除すると、同じホストからの非匿名認証が成功するはずです。
データベースユーザーに必要なデータベース権限が付与されていることを確認します
Apache Guacamoleには、データベース内のすべてのテーブルに対するSELECT、INSERT、UPDATE、DELETE権限が必要です。PostgreSQLではさらに、データベース内のすべてのシーケンスに対するSELECT、USAGE権限が必要です。
MySQLをご使用の場合は、記載どおりに、GRANTステートメントとFLUSH PRIVILEGESステートメントを実際に実行したことを確認します。MySQLはデータベース権限をキャッシュするため、FLUSH PRIVILEGESが実行されない限り権限の変更は適用されないことにご注意ください。
PostgreSQLをご使用の場合は、記載どおりに両方のGRANTステートメントを実行したこと、および必要なデータベース権限を付与する前に実行したことを確認します。PostgreSQLが付与できるのは、存在するテーブルとシーケンスに関する権限のみであることにご注意ください。Guacamoleのデータベーステーブルが存在する前に、GRANTステートメントを実行しても、何の効果もありません。
データベース関連のプロパティの後に空白が付いていないか確認します
Javaの.propertiesファイルでは、プロパティ値の_前に_ある空白に意味はありませんが、プロパティ値の最初の空白でない文字の後は、空白も含めてすべてプロパティ値に含まれます。/etc/guacamole/guacamole.properties内のすべてのデータベース関連プロパティの見た目が正しいと確信できる場合でも、普通なら正しく見える値の末尾に空白が誤って挿入されていないか確認してください。
ご利用の（管理用）Guacamoleユーザーカウントに、LDAPユーザーのリストを取得する権限があることを確認します
Apache GuacamoleのLDAPサポートは、LDAPディレクトリによって強制される権限をバイパスしません。これはつまり、Guacamoleの「検索」LDAPユーザーが権限を持っているか否か、およびデータベースユーザーが一般的なユーザー管理権限を持っているか否かに関係なく、_ご利用の_該当するLDAPユーザーがこれらのユーザーのリストを取得する権限を持っている場合にのみ、そのGuacamoleユーザーでGuacamoleの管理者インターフェース内にLDAPユーザーを表示できることを意味します。
ご利用のユーザーに権限があるか分らない場合のお勧めの確認方法は、自分のディレクトリに対してLDAPクエリを実行し、LDAPアカウントに関連付けられたDNとパスワードを使用してバインドすることです。「ldapsearch」ユーティリティは、このような検索を実行できる標準ツールです。
ここで、YOUR_LDAP_SERVERはLDAPサーバーのホスト名またはIPアドレス、YOUR_LDAP_DNはLDAP内のアカウントの完全なDN、USER_BASE_DNはLDAPディレクトリ内の関連するすべてのユーザーのベースDN（/etc/guacamole/guacamole.propertiesのldap-user-base-dnプロパティで指定されているとおり）です。
Guacamoleへのサインインにデータベースクレデンシャルではなく、LDAPクレデンシャルを使用していることをご確認ください
データベース内のユーザーアカウントにパスワードが関連付けられており、LDAPアカウントに関連付けられているパスワードの代わりにそのパスワードを指定すると、データベースに対してのみ正常に認証されます。これは有効な認証結果ですが、セッションがLDAPオブジェクトにアクセスできなくなることを意味します。ユーザーを含むLDAP内のオブジェクトにアクセスできるようにするには、LDAPディレクトリが受け入れるクレデンシャルで認証する必要があります。
LDAP関連のプロパティの後に空白が付いていないか確認します
Javaの.propertiesファイルでは、プロパティ値の_前に_ある空白に意味はありませんが、プロパティ値の最初の空白でない文字の後は、空白も含めてすべてプロパティ値に含まれます。/etc/guacamole/guacamole.properties内のすべてのLDAP関連プロパティの見た目が正しいと確信できる場合でも、普通なら正しく見える値の末尾に空白が誤って挿入されていないか確認してください。LDAP関連のプロパティの最後に空白があると、クエリが失敗したり、Guacamoleが誤解してクエリの結果が成功したように見える可能性があります。
自分のパスワードの変更には、管理ユーザーエディターではなく、「ユーザー設定」インターフェースを使用します
Apache Guacamoleには、ユーザーのパスワードを変更するためのメカニズムが2つ用意されています。他のユーザーのパスワード（現在のパスワードを知っている必要はありません）を変更するためのユーザーエディターと、現在のパスワードを知っていることを確認したうえで、_自分の_パスワードを変更するための「ユーザー設定（Preferences）」画面です。現在のパスワードを知っているかどうかは、「ユーザー設定（Preferences）」画面でしか確認できないため、自分のユーザーに変更を加える場合に、Guacamoleが許可するメカニズムはこれだけです。ユーザーエディターを使用して自分のパスワードを変更しようとしても、許可されません。管理者の場合、「設定（Settings）」から「ユーザー設定（Preferences）」に移動して、「ユーザー設定（Preferences）」画面にアクセスできます。
問題のユーザーが自分のパスワードを変更する権限を持っていることを確認します
Apache Guacamoleデータベース内で定義されたユーザーアカウントには、必ずしも自分のパスワードを変更する権限はありません。自分のパスワードを更新する権限は、管理者が明示的に付与する必要があります。自分が管理者で、新規作成したユーザーが自分のパスワードを変更できるようにしたい場合は、ユーザーエディター内の「自分のパスワードを変更する（Change own password）」権限の横にあるチェックボックスをオンにします。
セキュリティ方式を明示的に指定してみます
最近のバージョンのWindowsでは、デフォルトでネットワーク レベル認証（Network Level Authentication、NLA）が必要です。NLAは、より高度な暗号化を使用し、デスクトップセッションのリソースを割り当てる_前に_認証を強制するRDP固有のセキュリティ方式です。Windows RDPサーバーへの接続に失敗している場合は、失敗している1つまたは複数の接続のパラメータ内で「NLA」または「TLS」セキュリティモードを選択してみてください。ユーザー名、パスワード、および（該当する場合は）ドメインも指定しない場合、Guacamoleは接続時にこれらの詳細情報の入力を求めます。
同様に、古いバージョンのWindowsはデフォルトでNLAもTLSもサポートしていない場合があり、古い「RDP」セキュリティ方式を明示的に選択しない限り、Guacamoleの初期セキュリティネゴシエーションが失敗する可能性があります。旧バージョンのGuacamoleでは、「RDP」セキュリティ方式がデフォルトでした。
RDPサーバー証明書の検証を無効にしてみます
NLAセキュリティモードとTLSセキュリティモードの両方で、RDPサーバー証明書のクライアント検証が行われます。ほとんどのWindowsサーバーの場合、この証明書は自己署名のため、検証できません。既知の認証局に対して証明書を検証できない場合、GuacamoleはRDP接続の完了を拒否します。個々のRDP接続は、接続パラメータ内の「サーバー証明書を無視する（Ignore server certificate）」オプションをオンにすることで、この検証をバイパスするように設定できます。
WindowsファイアウォールのルールによってguacdからのRDP接続がブロックされているか確認します
Windowsファイアウォールは、ローカルまたはGPOを使用して、着信RDP接続をブロックするように設定できます。問題のWindowsマシンが過去にRDPを使用してアクセスされていた場合でも、Guacamoleサーバーが属さない特定のサブネットを除くすべてのサブネットに対してRDPアクセスがブロックされている可能性があります。このような場合は、Guacamoleサーバー（またはそのサブネット）がRDP経由で接続できるように、Windowsファイアウォールを再設定する必要があります。Windowsサーバーへのアクセスを公開する必要はありません。
ドライブのパスが、「guacd」ユーザーまたは「guacd」グループが書き込み可能なディレクトリを指していることを確認します
Keeper Connection Managerパッケージは、guacdのみがアクセス可能にする必要のあるファイルへのアクセスを制御するために、「guacd」のユーザーおよびグループを作成します。RDPでドライブのリダイレクトを設定していて、guacdユーザー（またはグループ）にRDPでドライブのパスとして選択されたディレクトリへの書き込み権限が与えられていない場合、guacdがリダイレクトされたドライブをエミュレートしても、そのディレクトリ内のファイルの読み取り/書き込みができなくなります。RDP接続でドライブのパスとして使用するディレクトリには、以下のように適切な権限と所有権を割り当てる必要があります。
パッケージがインストールされると、デフォルトではサービスごとに/var/lib/guacamoleフォルダが作成されます。
「guacd」サービスはguacdユーザーとして実行され、guacdユーザーは、「recordings」フォルダや「drives」フォルダなどの/var/lib/guacamoleサブフォルダ内のサブフォルダに対する読み取り/書き込み権限を必要とする唯一のユーザーです。
「guacamole」プロセスは「guacamole」ユーザーとして実行され、「recordings」のサブフォルダとファイルへの読み取りアクセス権が必要です。
