つながらないときはここをチェック
リモートデスクトップのトラブルシューティング
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
-
製品資料
[株式会社シーイーシー] 脱VMwareに成功した企業は何をどう実践した? 事例に学ぶ戦略立案&実装のコツ -
製品資料
[株式会社オービックビジネスコンサルタント] ランサムウェア攻撃を“二重の防御構造”で防ぐ、クラウド型基幹システムの実力 -
製品資料
[株式会社オービックビジネスコンサルタント] 動画で知るランサムウェア被害企業のリアル、会計データが無事だった理由とは -
市場調査・トレンド
[セコムトラストシステムズ株式会社] EDR導入を成功に導くロードマップ:選定/稟議/運用のつまずきを防ぐコツ -
事例
[日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は? 先行企業の導入事例3選
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「企業におけるAI導入検討度とIT投資優先度」に関するアンケート
-
2
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
3
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
4
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
5
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
6
年収700万超エンジニアに共通するスキルと「もっと勉強すべきだった分野」
-
7
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
8
「0.3秒のスピード顔認証」の入退室管理が社員に好評 事例に学ぶオフィス改革
-
9
IT製品の導入に関するアンケート「PC&デバイス」編
-
10
エンジニアの生産性はどう測る? マネジメントに不可欠な可視化の実現方法とは
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー