ライタス株式会社公式ブログ

  こんにちは。 ライタスの営業担当・Kです。 前編では、 Pingは通るのにRDP接続できない問題 を調査しました。 調査の結果、 RDP Listener（rdp-tcp）が正常に生成されていない 状態であることが判明しました。 今回は、その解決方法をまとめます。 RDP Listenerとは RDP接続は Remote Desktop Services が処理しています。 その中でも重要なのが RDP Listener です。 Listenerは、簡単に言うと RDP接続の待受口 の役割を持っています。 通常は以下のように TCP3389で待受 が行われます。 TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING また、以下のコマンドを実行すると qwinsta 通常は rdp-tcp というListenerが表示されます。 今回の問題 今回の環境では次の状態でした。 3389がLISTENしていない qwinsta に rdp-tcp が表示されない つまり RDP Listener が正常に生成されていない 状態でした。 Remote Desktop Services が起動していても、 Listenerの初期化に失敗すると3389で待受しません。 レジストリ確認 RDP Listener の設定は以下のレジストリに保存されています。 HKEY_LOCAL_MACHINE └ SYSTEM └ CurrentControlSet └ Control └ Terminal Server └ WinStations └ RDP-Tcp この設定が破損している場合、 RDPサービスは起動する しかし Listener の初期化に失敗する という状態になることがあります。 RDP設定の再有効化 まず、RDP接続を許可する設定を確認します。 以下のコマンドで RDP接続を有効化 できます。 reg add "HKLM\SYSTEM\CurrentControlSe...

  こんにちは。 ライタスの営業担当・Kです。 社内PC間でリモートデスクトップ接続（RDP）を行おうとしたところ、 Pingは通るのにRDP接続ができない というトラブルに遭遇しました。 調査を進めた結果、原因として RDP Listener（rdp-tcp）の異常 が強く疑われる状態でした。 ただし、そこに辿り着くまでにいくつかの確認を行ったため、 トラブルシュートの記録としてまとめておこうと思います。 本記事（前編）では 発生した状況 切り分けの手順 調査結果 を整理します。 発生した状況 社内ネットワーク上のPC同士でRDP接続を行おうとしました。 接続元：PC1 接続先：PC2 しかし接続できません。 状況は以下の通りです。 同一ネットワーク Pingは通る RDP接続は失敗 つまり ネットワーク疎通はあるがRDPだけ接続できない という状態でした。 Ping疎通確認 まずは基本的な疎通確認です。 ping 接続先IP 結果 Reply from xxx.xxx.xxx.xxx Pingは正常に応答しました。 つまり IPレベルでの到達性は確認できた という状態です。 RDPポート（3389）確認 次にRDPのポートが開いているか確認します。 PowerShellで以下を実行します。 Test-NetConnection 接続先IP -Port 3389 RDPは TCP 3389 を使用します。 結果 PingSucceeded : True TcpTestSucceeded : False つまり Ping → OK TCP3389 → NG という状態です。 ここで考えられる原因は以下です。 Windows Firewall RDP設定 RDPサービス停止 ポート変更 OSエディション グループポリシー OSエディション確認 RDPのホスト機能は、Windowsのエディションによっては利用できません。 接続先PCのOSを確認したところ Windows 11 ...

  こんにちは。 ライタスの営業担当・Kです。 先日、X（旧Twitter）を見ていたところ、 「pingでできる6つの確認」という投稿を見かけました。 https://x.com/run_suru_net/status/1988939911429279745?s=20 内容としては、 pingコマンド1つで通信がどこまで通っているのか順番に確認できる というもので、ネットワークのトラブルシューティングの基本をまとめたものでした。 【 pingでできる6つの確認 】 順番に確認していくことで、 通信がどこで止まっているのか切り分けできるという内容です。 ① 自分のNICは生きているか ping 自分のIPアドレス ここでは、 LANカード ドライバ IP設定 など、自分の端末のネットワーク設定が正常かを確認できます。 ② 同じネットワークに届くか ping 192.168.1.x（同一セグメント） 同一ネットワーク内に通信が届くかを確認します。 ここで問題がある場合は、 LANケーブル スイッチ VLAN設定 などの可能性が考えられます。 ③ デフォルトゲートウェイに届くか ping 192.168.1.1（GW） デフォルトゲートウェイに届くかを確認することで、 ルーティングの入口が正常かを確認できます。 ④ 別ネットワークに届くか ping 192.168.2.x（別セグメント） ここでは、 ルーティング設定 VLAN間通信 などが正常に機能しているかを確認できます。 ⑤ 外部ネットワークに出られるか ping 8.8.8.8（Google DNS） 外部に通信できるかを確認します。 問題がある場合は、 外部ルーティング ファイアウォール NAT設定 などが原因の可能性があります。 ⑥ 名前解決ができるか ping google.com ここでは DNSの動作確認 ができます。 IPアドレスでは通信できるのに ドメインで通信できない場合は、 DNS周りの設定が疑わしいということになります。 上から順に確認すると原因が見えやすい この方法のポイントは、 上から順番に確認していくこと。 順番に確認することで、 ・端末側の問題なのか ・ネットワーク内部の問題なのか ・外部接続の問題なのか ・DNSの問題なのか といった原因の当たりが一気につくというわけです。...

メンテナンスや構成変更など、ネットワーク機器の操作では、「LANケーブルの抜線」をすることがあります。 この際にケーブルを取り違えれば、稼働中のサービスが停止するなど、様々な問題を引き起こします。 そのため「このケーブルのもう一端はどこに接続されているのか？」 というのを把握する必要がありますが、 ケーブルが煩雑・多量で識別が困難 ケーブルが壁内・床下に埋設されており、識別が不可能 という場面もあろうかと思います。 頑張ってパケットを流してポートのランプを光らせてみたり、タグを付けて対向がわかるようにしたりと、様々な工夫を要求されることになります。 そういった苦労が不要になるLANケーブルとして、今日は「PatchSee」をご紹介します。 公式： https://www.patchsee.com/ 参考動画： PatchSeeは内蔵された光ファイバーによって、ケーブルの両端を容易に識別することができます。 これが 目視 かつ 活線 で可能、というのは非常に価値があります。 是非弊社までお問合せいただければと思います。 お問合せは、弊社ホームページより http://litus.co.jp

ある仮想サーバー（Windows機）をホスティングすることになり、相手方の環境にVPNを張って リモートで環境構築をしていたところ、、、 相手方でNICの設定をいじったのか、DNSを設定しようとするとエラーになりました。 このネットワーク アダプタ用に入力された IP アドレス  XXX.XXX.XXX.XXX  は別のアダプタ  アダプタ名 に既に割り当てられています。 アダプタ名  は物理的にコンピュータにないか動作していないレガシ アダプタであるため、ネットワーク接続フォルダには表示されていません。同じアドレスが割り当てられた 2 つのアダプタがアクティブになった場合、どちらか 1 つのアダプタがそのアドレスを使うことになり、システム構成エラーの原因となります。このアダプタ用に別の IP アドレスを指定しますか? ありがちというか、なんというか、古い方のNICに同一のIPが設定されたままになっているようです。 無視してOKでもいいのですが、なんとも気持ち悪いので、何とかしたいところ。 仮想だと、ソフトウェア上でNICの設定ができてしまうので、頻発するのではないでしょうか。 こういう時には、消したハードウェアを表示させることで、何とかできるようです。 参考 http://www.atmarkit.co.jp/fwin2k/win2ktips/279nodevice/nodevice.html コマンドプロンプトを開く set devmgr_show_nonpresent_devices=1 　・・・実行 start devmgmt.msc　・・・実行 ハードウェアマネージャーが開く [表示] -> [非表示デバイスの表示] とすると、OSが認識しているハードウェアが表示されるようになります。 NICを調べれば、通常使用しているものと、過去に外したものが表示されていると思います。 過去に外したものは、必要無いので、削除したあと、再起動すればOKです。 （再起動いらないかも） 本記事は、弊社代表のブログ記事 なんでもIT屋の宿命 からの転載です。