つながらないときはここをチェック
リモートデスクトップのトラブルシューティング
Windowsの「リモートデスクトップ」は遠隔地から自分のコンピュータに接続するための機能だが、セッションの確立がうまくいかないことがある。リモートデスクトップの接続や認証、暗号化に関するトラブルシューティングを紹介しよう。
Windows XPがリリースされて以来、筆者が最も好んで利用している機能の1つが「リモートデスクトップ」だ。よく知らない読者のために説明しておくと、これはWindowsに組み込まれている機能の1つで、RDP(Remote Desktop Protocol)というプロトコルを使ってリモートから自分のコンピュータに接続することを可能にする。例えば、あなたが自宅にいるときに会社にある自分のコンピュータに保存されたデータを参照する必要が生じた場合、リモートデスクトップセッションを確立すれば、自宅から会社のPCをリモートでコントロールすることができるのだ。リモートデスクトップはWindows Terminal Servicesと同じ技術をベースとしており、使用するプロトコルも同じだ。
リモートデスクトップはとても便利だが、問題が起きることもある。リモートデスクトップセッションは通常は安定しているが、接続時および認証時にトラブルが発生することがあり、その原因は幾つかある。リモートデスクトップで問題が起きた場合に役立つトラブルシューティングテクニックを以下に示す。
リモートコンピュータが見つからない
リモートデスクトップで最も多い問題は、恐らくリモートPCが見つからないというトラブルだろう。この問題を引き起こす原因は幾つかある。最も単純な原因は、リモートコンピュータ名のスペルが間違っているというものだ。リモートコンピュータに接続できないときは、まずリモートコンピュータ名のスペルが間違っていないか確認しよう。
リモートマシン名のスペルが正しければ、次はDNSに関連した問題が考えられる。リモートデスクトップが使用するRDPプロトコルは、TCP/IPプロトコルの上に乗っている。読者もご存じだと思うが、TCP/IPがシステムを特定するメカニズムではWindowsのコンピュータ名を使用しない。コンピュータ名を指定できるのは、DNSサーバがコンピュータ名をIPアドレスに名前解決するからだ。
名前解決に問題がある場合の対処法は2つある。1つの方法は、リモートシステムのNetBIOS名ではなく完全ドメイン名を使用することだ。これで必ずしもコネクションを確立できるとは限らないが、この方法で問題が解決する場合もある。
もう1つの対処法は、名前ではなくリモートコンピュータのIPアドレスを指定することだ。一般に、接続にはコンピュータ名よりもIPアドレスを使用した方が、問題が起きることはずっと少ない。しかし、IPアドレスが問題の原因になることもある。
IPアドレスを使って接続する場合に問題が生じる最大の原因は、動的IPアドレスの使用だ。サーバに接続するのであれば、これが問題になることはないだろう。ほとんどのサーバは固定IPアドレスを使用しているからだ。一方、ほとんどすべての作業用(クライアント)PCは動的IPアドレスを使用している。すなわち、あなたのPCが今日使っているIPアドレスが、明日には別のPCに割り当てられるかもしれないのだ。接続先のマシンが動的IPアドレスを使用しているのであれば、接続の際にマシンのIPアドレスではなくホスト名を指定する以外に実質的には選択肢がない。
リモートデスクトップを利用してリモートコンピュータに接続する上で、障害となり得るもう1つの要因がファイアウォールだ。RDPは基本的に、TCPポート3389を使用する。ファイアウォールの内側に置かれたリモートマシンに接続するのであれば、ファイアウォールはトラフィックがTCPポート3389を通過するのを許可しなければならない。もちろん、ファイアウォール上でこのポートをむやみに開けるのは、重大なセキュリティリスクを招く恐れがある。それよりもポートフォワーディング機能を有効にして、インバウンドのRDPトラフィックを特定のIPアドレスに転送するという方法をお勧めする。こうすれば、外部の人間が社内ネットワークの任意のマシンにRDP接続を試みることができなくなる。
多くのネットワークでは、RDPトラフィックに対してポートフォワーディングを使用する以外に選択肢がない。大抵のネットワークでは、ネットワーク内のマシンにはプライベートIPアドレスを使用し、ルータだけがグローバルIPアドレスを使用するようになっている。ルータはNAT(Network Address Translation)機能を使って、プライベートネットワーク上のホストとインターネットとの間のトラフィックを代理転送する。インターネット経由でNATファイアウォールの背後にあるホストとRDPコネクションを確立するには、RDPトラフィックを接続先ホストに転送するようファイアウォールを設定する必要がある。
上記の方法は、ネットワーク境界部の外側から直接接続する場合を想定している。VPNあるいはダイヤルアップ接続を通じてプライベートネットワークに接続するのであれば、NATファイアウォールの設定を変更する必要がある。VPNやダイヤルアップ接続は、プライベートネットワークへの接続を提供するだけだからだ。VPNまたはダイヤルアップ接続を確立するために使用されるリモートアクセスサーバは通常、ファイアウォールの内側に置かれているため、RDPトラフィックがプライベートネットワークに入るのを許可するように、このファイアウォールを設定する必要がある。
ファイアウォールに関していえば、Windows XP SP2とWindows Vistaにはファイアウォールが組み込まれている。これらのOSが動作しているマシンに対してコネクションを確立するには、RDPトラフィックを許可するようWindowsファイアウォールを設定する必要がある。
認証に関連する問題
最初のコネクションの確立がリモートデスクトップで最も厄介な部分であるのは間違いないが、問題はほかにもある。リモートコンピュータに接続でき、認証情報を入力したのに、「このシステムのローカルポリシーは、このユーザーが対話的にログオンすることを許可していません」というエラーメッセージが表示されて驚くユーザーは多い。
Windowsがこのエラーメッセージを表示するのは、ユーザーがRDPを使ってログインするのに必要な権限を持っていない場合だ。この問題は、リモートデスクトップユーザーグループまたはローカル管理者グループにユーザーアカウントを追加することによって解決できる。
データの暗号化
リモートデスクトップで最も不可解な問題の1つが、「データの暗号化のエラーのため、このセッションは終了します。リモートコンピュータに接続し直してください」というメッセージが表示されることだ。
ほとんど場合、このエラーメッセージは、旧式のリモートデスクトップ(あるいはターミナルサービス)クライアントの使用に関係している。MicrosoftがWindows 2000をリリースしたとき、同社は「管理ツールパック」(Adminpak)というアドオンを提供した。管理ツールパックには、リモートセッション確立に利用できるクライアントコンポーネントが含まれていた。このクライアントは一見、Windows XPと互換性があるように思えるが、実はそうではない。Windows XPとのリモートデスクトップセッションを確立するのにWindows 2000版の管理ツールパックを使用すると、上記のようなエラーメッセージが表示されることが多い。
Windows XPには専用のリモートデスクトップクライアントが付属しているので、Windows XPが動作しているほかのマシンとのコネクションを確立するには、このクライアントを使用すべきだ。どうしても管理ツールパックを使いたいのであれば、Windows Server 2003版にアップグレードする必要がある。これはMicrosoftのサポートサイトからダウンロードできる。
本稿筆者のブライエン・M・ポージー氏はテクニカルライターで、これまでに3000本以上の記事を執筆した。同氏が著作あるいは寄稿した本は27冊に上る。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー