win2k3 server spezifisches problem | ssh tunnel | vnc

hoppeldino

Neuling
Thread Starter
Mitglied seit
10.05.2006
Beiträge
2
Hallo erstmal :)

Also ich hätte da mal ein Problem, welches mich wirklich zum verzweifeln bringt.
Ich mache zur Zeit eine IT Ausbildung an einer sehr guten Privatschule und will dort aber nicht auf das remoten meines Servers zu Hause verzichten. Folgender Sachverhalt:

Wir haben nur einen Rechner an der Schule der ans Inet angeschlossen ist, da kann man von "innen" nur über den Port 80 raus, der durch einen Proxy gesteuert wird, damit die Dozenten im Unterricht das Inet abschalten können. Das ganze ist ein DebianServer wo aber "Gott sei Dank" ssh-tunneling aktiviert ist.
Also hab ich von meinem win2k3-Server zu Hause einen sshTunnel auf diesen Debianrechner gelegt und den Port meines Proxies den ich auf dem winserver laufen hab getunnelt. Von "Innen" mach ich das gleiche, ich lege von einem pc einfach nen ssh tunnel mit wieder dem selben port auf den debianrechner und schon kann man mit paar einstellungen surfen ohne dass der proxie(der schule) es mir verbietet. So weit so gut.

Nun mache ich das gleiche mit dem vnc port da ich doch gern meinen server @ home remoten möchte. das ganze funktioniert auch wunderbar, nur gibt es ein problem, das vnc funktioniert absolut ohne einschränkungen, nur bekomme ich kein bild, nur einen schwarzen bildschirm...

nun habe ich gegoogelt und gegoogelt und bin auf folgendes gestoßen:

Alle VNC-Varianten (und auch andere Fernsteuerprogramme) haben oft das Problem, dass bei der Fernsteuerung eines XP-PCs (oder eines Windows 2003 Servers) die Verbindung zwar zustande kommt, der Viewer aber nur einen schwarzen Bildschirm zeigt.

Mögliche Ursache:

Ein MS-Dienst, wie der VNC Server, darf nur mit Session 0 interaktiv kommunizieren. Bei Windows NT und 2000 war Session 0 grundsätzlich die Console Session. Bei Windows XP und 2003 ist dies aber nur so lange der Fall, bis eine Microsoft Remote Desktop / Terminal Server Session gemacht wird; nach deren Beenden kann die Konsole plötzlich Session 1 oder 2 werden. Da der VNC Host darauf keinen Zugriff hat, bleibt der Bildschirm schwarz, und zwar so lange, bis der PC neu gebootet wird.

Damit erklärt sich der Bildschirm aber nicht wie ich das Problem löse...
Es gibt bei meinem server keine lokale session, da keine tasta bzw moni angeschlossen ist, normalerweise wird der rechner nur mit remotedesktop administriert, nur dieser ist aus der schule raus nicht verfügbar.
Also wie kann ich das noch wegmachen?
Hat irgendwer eine Idee dafür?

wäre euch echt sehr sehr dankbar :)

mfg hoppeldino
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hi,

Ich sehe das Problem an einer anderen Stelle.

Ich denke nicht, das man einfach port 80 für Remote nutzen kann, da dieser für tcp vorgeshen ist.
Sobald die Verbindung einmal das Protokol wechselt, stehst du auf dem Schlauch.
Das ist meine Idee, wenn ich mich irre, dann BITTE, korregiert mich!!!!

Aber warum nutzt du nicht einfach port 80 für Remotedesktop?
Dann kannst du den Server auch ruhig neu starten, Remotedesktop wird schon vor der Anmeldung an das System geladen.

mfg
 
Ich denke nicht, das man einfach port 80 für Remote nutzen kann, da dieser für tcp vorgeshen ist.
Sobald die Verbindung einmal das Protokol wechselt, stehst du auf dem Schlauch.
Das ist meine Idee, wenn ich mich irre, dann BITTE, korregiert mich!!!!

zum remoten über vnc nutze ich auch nit den port 80 sondern hab mit den port 5900 getunnelt, wie gesagt geht ja alles was vnc anbietet, nur kein bild kommt, der filetransfer etc macht alles keine probleme.

Ersteinmal funktioniert Remotedesktop von Win NUR auf dem Port 3389 laut meinem Wissen... also nix mit über port 80 -.-
zweitens ist das senden von remotedesktopanforderungen bei uns anner schule im win deaktiviert und sind auch keine rechte vorhanden dies zu ändern.

Danke für deine Antwort, war aber glaub kein Schritt in die richtige Richtung :(
 
1. denn Port für die RDP verbindung kannst du umstellen
2. auch die anderen Ports von VNC sind zu beachten ;

VNC Webseite: 58+display Nummer (e.g. 5801),
VNC Protokoll: 59+distplay Nummer (e.g. 5901) und
den Port 5500 für den Listen Modus des Viewer.

ssh-tunnel-01.gif

3. wenn du nun den tunnel aufbaust und somit an dem debianserver dei PORTS anbietest(tunnel) beachte ob nicht andere Tunnler
auch den PORT anbieten, weil die destination bleibt ja gleich, der debian server. bzw du kommunizierst so "schulpc stellt anfrage an SSH-server wo die verbdinung zum Tunnel (PORT) ist.

lsof -i
hilft da weiter, z.b lsof -i :80 zeigt dir an wer auf den port listet bzw ob überhaupt.

PS: wenn eine sache sich anders verhaelt, kannst mich gern aufklären.


1.Führen Sie Regedt32 aus, und gehen Sie zu dem folgenden Schlüssel:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Hinweis: Bei dem vorstehenden Registrierungsschlüssel handelt es sich um einen einzeiligen Pfad. Er wurde umgebrochen, um die Lesbarkeit zu verbessern.

2.Suchen Sie den Teilschlüssel "PortNumber". Der Wert müsste 00000D3D lauten, da es dem Hex-Wert für "3389" entspricht. Ändern Sie die Portnummer im Hex-Format, und speichern Sie den neuen Wert.

Gehen Sie folgendermaßen vor, um den Port für eine spezielle Verbindung auf dem Terminal Server zu ändern:•Führen Sie Regedt32 aus, und gehen Sie zu dem folgenden Schlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\Verbindung
Hinweis: Bei dem vorstehenden Registrierungsschlüssel handelt es sich um einen einzeiligen Pfad. Er wurde umgebrochen, um die Lesbarkeit zu verbessern.3.Suchen Sie den Teilschlüssel "PortNumber". Der Wert müsste 00000D3D lauten, der Hex-Wert für (3389). Ändern Sie die Portnummer im Hex-Format, und speichern Sie den neuen Wert.

Hinweis: Da die Verwendung alternativer Ports für Terminal Server 4.0 nicht voll implementiert wurde, wird diesbezügliche Unterstützung nur in "angemessenem Rahmen" gewährt. Es ist möglich, dass Microsoft Sie auffordert, den Port auf 3389 zurückzusetzen, falls Probleme auftreten.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh