TeamViewerエンジニア及びテクニカル部門は、ログファイルを使用してTeamViewerの履歴アクション、技術的なトラブルシューティング、およびバグの検出を識別します。
これらのログファイルは一般ユーザーもご自由に取得できますが、基本的にTeamViewerスタッフ専用としてデザインがされている為、一般ユーザーの方向けではございません。
ログファイルを開くと、大量のデータが含まれているため、読み方に関して難しい点があります。この記事では基本的なログファイルの読み方、さらに着信接続の接続アクション(接続の成功・失敗)を特定できるようにする方法をご案内いたします。
この記事は、すべてのTeamViewerユーザーに適用されます。
🚨免責事項
この記事では、すべての方に理解して頂ける基本的な情報と知識を提供することを目的としております。出来る限り分かりやすく説明する為、例を用いてご案内します。
ログファイルの読み方は、基本的な情報のみの提供となります。TeamViewerセッションが実際にどのように生成されるかを確認することはできませんことご了承くださいませ。
ステージ3では、例に基づいて簡潔に説明がされています。TeamViewerのパスワードを確認することは一切出来かねます。 つまりTeamViewerはパスワードを認識しませんことご了承くださいませ。パスワードはクライアントでローカルにチェックされる必要があります。
ログファイルはトラブルシューティング用に設計されております。このため、ログファイルが保管できるデータ量は制限されています。ログファイルはデフォルトで1MBです。これが最大サイズに達すると、ファイル名がlogfile_oldへと変更され、代わりに新しいログファイルが開始されます。 （これらが繰り返され、既存のlogfile_oldはすべて消去され上書きされます）
予期しない接続問題が生じた場合、探している情報すべてを確認出来ないこともございます。この記事では、エラーが発生したすべてのケースを網羅しておりませんことご了承くださいませ。
接続を特定する
TeamViewerの接続は中央サーバーを介してネゴシエートされるため、着信接続の試行が成功する前に多くの暗号化と認証が行われることを念頭に置くことが重要です。
TeamViewerセッションの詳細については、セキュリティハンドブックをご覧くださいませ。
📌注意：TeamViewerログファイルすべてを完全に読み取ることができるようにするには、TeamViewerスタッフでかつ特定の部署のみが受ける特別なトレーニングが必要です。
一般ユーザーがTeamViewerログファイルの分析を行った際に、接続に失敗したケースが表記されているにも関わらず、セッションが確立されたと判断してしまうケースもありました。
この記事をご覧頂くと、接続の試行と成功した接続を区別できるようになります。
成功した接続と接続の試行
接続が成功するのは、高度に保護された暗号化および認証プロセスの結果であり、実際には1人のユーザーがリモートデバイスを見ることができます。デバイスの設定に応じて、制限付きまたは完全なリモートアクセスが可能です。成功したすべての接続は、TeamViewerフォルダにあるConnections_incoming.txtログに一覧表示されます。
接続を試行すると、その後接続が成功する場合と成功しない場合があります。
TeamViewer接続の5つの段階
着信TeamViewer接続を5つの段階に識別して説明するため、TeamViewer接続の説明と身近に感じて頂ける例を取り上げながら説明します。身近に感じて頂ける例として、太郎が花子にオペレーターを介して電話をしようとしている状況を想定して説明します。
💡接続の各段階は成功する必要があります。単一の障害により、TeamViewerによって接続が拒否されます。
ステージ1：接続試行の確立
※太郎と花子を例に説明します。
太郎が花子に遠隔操作をしようとしている最初の段階は、身近な例えを用いると、太郎が花子の電話番号を入力し、彼女の電話が鳴っている状況と同じです。
上記の状況を一旦整理し、花子の電話を鳴らすために何が起こっているか分析しましょう。太郎の要求を受信している途中に電話オペレーターがいると仮定します。
太郎はオペレーターに「すみません、オペレーターさん。太郎と申しますが、花子さんと話しがしたいです」と呼びかけます。
オペレーター：「はい、お待ちください。」
オペレーターが花子に電話します。
オペレーターが花子に電話をかけると、花子の電話が鳴ります。
👉太郎はこの段階では花子と直接話はしていません。あくまで通話を試みている状態です。以下は、この試行がログファイルでどのように表示されるかを説明します。
ここでは、接続の試行に使用されたルーターも確認できます。選択したルーターは、可能な限り最高のパフォーマンスを保証するように選択されており、時間帯によって異なる場合があります。すべてのルーターはISO27001認定環境にあり、すべての接続は常にエンドツーエンドで暗号化されています。
注意：この時点では、接続は確立されていません。
CommandHandlerRouting[2]::CreatePassiveSession(): incoming session via AU-SYD-IBM-R008.teamviewer.com, protocol Tcp
ステージ2：ブロックリストと許可リストのチェック
花子が電話を取ります：「こんにちは、花子です。」
オペレーター：「花子さん、こんにちは。こちらオペレーターです。太郎さんがあなたと通話しようとしています。許可されますか？」
花子は、許可リストに太郎が含まれているのを確認した後、許可リストを確認して回答します。「はい、太郎さんは許可リストに含まれています。認証の次の段階に進む準備ができています。」
👉太郎は過去に花子の通話許可リストに追加されたため、花子はこの通話試行のプロセスを続行することに同意します。まだこの段階では太郎は花子と直接通話していません。この状況はあくまで接続の試みを行っている段階です。以下は、この状況ががログファイルでどのように表示されるかの例です。繰り返します、この段階では接続は確立されていません。
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::AuthenticateServer()
👉太郎が花子の許可リストに含まれていない場合や、ブロックリストに含まれている場合は、花子は太郎との会話を拒否し、通話試行はすぐに停止します。以下は、通話が拒否された場合にログファイルではどのように表示されるかを紹介します。
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::CheckIfConnectionIsAllowed: Partner 111111111 (Taro) not whitelisted CLoginServer::runServer: Connection is not allowed
ステージ3：簡易アクセスとパスワードチェック
オペレーターは花子に「お待ちください。」と伝え、一旦太郎と会話をします。
オペレーター：「お待たせしました。花子さんと話すためのパスワードを教えてください。」
太郎：「『開けゴマ』です。」
オペレーター：「ありがとうございます。お待ちください。」
オペレーターは花子に通話を切り替え：「花子さん、お待たせいたしました。太郎さんは、パスワードは「開けゴマ」だと仰っています。」と伝えます。
🚨免責事項：上記は、TeamViewerのパスワードがログファイルから確認出来る事を指しておりません。以上の例はあくまで遠隔操作がどの様に設立され、それがログファイルに表記されるかを、例を用いて説明しております。 TeamViewerはパスワードを認識しません。パスワードはクライアントでローカルにのみ確認されます。
花子がパスワードを確認した場合、オペレーターは2つの回線を接続し、接続を解除します。（=ハンドシェイクの成功）これにより、オペレーターは太郎や花子との会話ができなくなります。
👉ログファイルで、簡易アクセスとパスワードのチェックは次のように表示されます。（接続に成功した場合）：
簡易アクセス・その1
AuthenticationPublicKey_Passive::Verify: Success
修正されたパスワード
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: authentication using fixed password was successful
花子がパスワードが間違っていると言った場合、ステージ3の最初に戻ります。太郎は正しいパスワードを伝える機会を再度得ます。失敗した試行が多すぎると、花子とオペレーターは接続の試行を拒否し、太郎はしばらくの間ブロックされます。
👉ログファイルで、簡易とパスワードのチェックは次のようになります（接続に失敗した場合）：
簡易アクセス・その2
LookupPublicKeyV2: Manager {~keyabcd1234} does not have EasyAccess right, reject Authentication
動的パスワード
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: authentication using dynamic password was denied
ステージ4：正常な接続の開始
太郎が簡易アクセスまたはパスワードを介して正常に認証できた後、接続が開始されます。
太郎は花子と直接通話をしています。通話に成功しました。
以下は、この正常な接続がログファイルでどのように表示されるかの例です。
CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=Taro CPersistentParticipantManager::AddParticipant: [222222222,-987654321] type=6 name=Hanako CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=Taro
ステージ5：接続の終了
花子または太郎はいつでも通話を終了でき、太郎と花子はお互いの声を聞くことができなくなります。もう一度話したい場合は、ステージ1からやり直す必要があります。
👉以下は、成功した接続のセッション終了がログファイルでどのように見えるかの例です：
SessionManagerDesktop::SessionTerminate: removing session with TVSessionID = -123456789
ボブが簡易アクセスまたはパスワードを介して正常に認証できなかった場合、接続の試行は完全に拒否されます。全くつながりがありませんでした。
👉以下は、失敗した接続のセッション終了がログファイルでどのように表示されるかの例です。
SessionManagerDesktop::SessionTerminate: no session with ID=123456789, aborting logins
💡ヒント：ログファイルに表示されるTVSessionIDのIDは、TeamViewer IDではなく、個々のセッションのIDです。これらを使用してデバイスを識別したり、誰かに接続したりすることはできません。
この例で使用されているID
111111111 - 太郎の TeamViewer ID
222222222 花子の TeamViewer ID
123456789 - session ID 1 (= no TeamViewer ID)
987654321 - Session ID 2 (= no TeamViewer ID)