web-dev-qa-db-ja.com

インターネットを介したWindows2k3およびRDPの問題(RDPはローカルで機能します)

家族の友人のWin2k3サーバーを見るように頼まれました-リモートデスクトップはもう機能していませんでした、そして彼らはその理由を理解しようとしていました。このサーバーはWin2k3SP2を実行しています。

ライセンスサービスにいくつかの問題があると判断しました(イベントID 19、詳細については http://support.Microsoft.com/kb/2021885 を参照)-これは修正プログラムをインストールすることで修正されました(- http://support.Microsoft.com/kb/983385 )およびライセンスの再アクティブ化により、エラーは表示されなくなりました。ただし、インターネットからのRDP接続は引き続き失敗します。

接続されているネットワークハードウェアは、SonicWALL TZ170アプライアンスへのDSLモデムであり、1台のPCと10または11のシンクライアント(Neoware)への有線アクセスを提供する24ポートスイッチに接続されています。

見たものを確認するだけです:
1。ポート3389はサーバーでリッスンしています(netstat -a -oはms-wbt-serverが3389でリッスンしていることを示します)
2。 Portqry(リモートWin7システムから)は、3389 TCPはリッスンしていますが、3389 UDPはリッスンまたはフィルタリングされています(UDPはオーディオのみを決定しますね?)
3。リモートWin7システムから、ポート3389のホスト名/ IPの両方にtelnetで接続し、正常に接続できます。
4。 RDPはローカルで動作します(つまり、ラップトップをローカルLANに接続し、mstscは、ラップトップが内部192.168.0.xアドレスを持つサーバーに正常に接続します)
5。リモートシステムでnmapを使用したポートスキャンは、3389が開いていることを示しています。
6。 Win2k3システムでアンチウイルスに気づきませんでした(SonicWALLアプライアンスで実行されているかどうかはわかりませんが、管理者パスワードを忘れたため確認できません。工場出荷時の状態にリセットすることは避けたいと思います)。 。 Win2k3サーバーのローカルWindowsファイアウォールが有効になっていません。

サーバーへの接続は、リモートで次のメッセージを受け取ります。

This computer can't connect to the remote computer.

Try connecting again. If the problem continues, contact the owner of the remote 
computer or your network administrator.

Win2k3サーバーは、Windows Updateからの修正/パッチで十分にバックレベルですが、ライセンスの問題が私を超えてしまう前にこれが機能していたときに問題が発生するのはなぜですか?システムには完全バックアップがなかったためです(ユーザーデータ)、修正プログラムを実行する前にドライブのイメージを作成しました(念のため)。

助言がありますか?ライセンスやポートなどに関連して考えられるすべてのことを行いました。ローカルでは機能しますが、インターネット経由では機能しないため、Sonicwallが何かをしていることしか考えられませんでした(ポートフォワードは正常に機能しているようですが) win2k3サーバーはサービスをリッスンしていると見なすことができるため、内部IPに接続します。

私のロープ(そして忍耐)の終わりに。

ありがとうございました。

編集:

現在、リモートサイトにいないため、Wiresharkを使用して確認することはできません。ただし、Wiresharkを使用してリモートで確認すると、サーバーが応答する(SYN/ACKが実行される)ことが示されますが、接続が応答しないようです。やってくる。

お分かりのように、私はWin2k3にあまり精通していません。私は主にUNIXの人です。/grin

SonicWALLでもポート443が開いているので、TSゲートウェイが使用されているのではないかと思います。

RDゲートウェイ(RD/TSなど)を使用するようにRDP設定を変更すると、Sonicwallから証明書エラーが発生します-その証明書のエクスポートとルート証明書へのインポートは機能しますが、再接続しようとすると名前が表示されます(つまり、CN )が一致しません-接続しているFQDNが証明書名と一致しないため、これは理にかなっています(Sonicwallから受け取った証明書にはSonicwall 192.168.0.1の内部IPが表示されますが、フルネームは表示されません) 。

正しい!今はもっと混乱しています。/grin

6
Karthanon

問題を発見しました:

'netstat -a'は、リッスンしているターミナルサービスを表示しますが、ポートではなく名前で表示します(つまり、ポート3389ではなくms-wbt-serverを表示します)。 Wiresharkなどを使用して戻ってきました。サーバーに届く情報がネットワークを介して作成されていることを確認するため(これは、上記の2つの提案を評価しますが、まだ担当者がいません!)。

誰かがサーバーのRDPを非標準ポートで実行するように設定したことが判明しました。

これを含むレジストリキーは次のとおりです。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

これを3389(10進数)に戻し、保存して、サーバーを再起動しました。

その後、ターミナルサービスが機能しました。

TSゲートウェイ/ 443はWindowsServer 2008でのみ使用されるため(MS Technetによる)、ポート443/TSゲートウェイに関する以前の考慮事項は適用されなかったことに注意してください。

2
Karthanon

Windows 2003サーバーでNetMonまたはWiresharkを使用して、リモートシステム接続が実際に3389のサーバーに接続されていることを確認することをお勧めします。

1
Greg Askew

「リモートのWin7システムから、ポート3389のホスト名/ IPの両方にtelnetで接続し、正常に接続できます。」

「インターネット経由」と「ネットワーク内のローカル」のTelnet接続バナーを比較して、一致するかどうかを確認します。

  • そうでない場合は、そのネットワークからインターネットに向かって作業を開始します。
  • それらが一致する場合は、システム構成/相互運用性の問題である可能性があります。
0
user48838