bin gerade unterwegs und wollte mal eben schnell per VNC auf meinen heimischen Rechner, aber irgendwas muss beim Austausch des Routers auf einen Speedport 700 und nun vorgesehenem VPN-Tunnel schief gelaufen sein.
Im LAN funktionierte VNC gestern noch problemlos. Eine VPN-Verbindung zum heimischen PC bekomme ich auch problemlos aufgebaut, VNC meldet sich auch offenbar vom heimischen PC, denn bei falschem Paßwort wird dies mit entsprechendem Fehler quittiert, aber bei richtigem Paßwort kommt nur „Connection closed“ und das war es dann. Einrichtung/Nutzung wie folgt: Auf dem Speedport Port 1723 für VPN freigegeben, VPN verbunden, und dann mit der festen IP-Adresse im heimischen LAN den PC angesprochen.
Testweise dann aufgrund der funktionierenden VPN-Verbindung dann mal die Router-Konfiguration angesprochen und versucht VNC direkt freizuschalten, und dafür ein weiteres Portforwarding von 5800 und 5900 auf meinen Rechner eingerichtet. VPN getrennt und dann VNC über den DynDNS-Namen aufgerufen. Gleiches Spiel (richtiges Paßwort „Connection closed“, falsches Paßwort mit entsprechender Meldung).
Grübel, Grübel, zumindest zweite Variante hat mit dem guten alten Zyxel immer funktioniert, und da VNC im LAN gestern noch lief, kann es daran eigentlich auch nicht liegen.
Grübel, Grübel, zumindest zweite Variante hat mit dem guten
alten Zyxel immer funktioniert, und da VNC im LAN gestern noch
lief, kann es daran eigentlich auch nicht liegen.
Das klingt alles nicht, als habe es mit der Netzweinrichtung oder dem Router zu tun, sondern als sei der VNC-Dienst auf dem fernzusteuernden Rechner in einem instabilen Zustand. Kannst du das Portforwarding alternativ auf einen zweiten Rechner einrichten oder den ersten Rechner durchstarten lassen?
Bir mir hat TightVNC auch immer rumgebockt, ich bin auf UltraVNC umgestiegen, seither geht es einwandfrei, trotz gleichgebliebener Konfiguration.
Ich vermute mal, das Tight noch einen anderen Port benutzt, der allerdings in der Dokumentation nicht genannt wird. Den müsste man am Router auch noch forwarden, aber wenn man den nicht kennt . . .
P.S.: Es ist natürlich auch denkbar, dass hier ein MTU-problem vorliegt. In dem Fall müsstest du die MTU-Size auf dem fernzusteuernden Rechner heruntersetzen - ein schöner circulus vitiosus.
um einen Reboot kann ich meine Liebste heute Abend mal bitten, wobei ich eigentlich nicht so ganz an Probleme mit dem Dienst glaube, da die Kiste immer wochenlang 7/24 durchläuft und es gestern im eigenen LAN über die feste heimische Adresse im eigenen LAN noch funktionierte, und hierüber per VPN ja auch Freigaben weiterhin erreichbar sind. Das wäre schon ein größerer Zufall. An die MTU-Geschichte glaube ich eigentlich auch nicht so ganz, weil daran noch nie etwas geändert worden ist, und die Kiste problemlos von außen ansprechbar war (ohne VPN), als noch der alte Zyxel-Router im Einsatz war. Der Router ist erst vor einigen Wochen ausgetauscht worden, und das Forwarding genau von 5800 und 5900 stammt direkt von der TightVNC Homepage und ist auf beiden Routern identisch eingerichtet.
Was mir jetzt aber aufgefallen ist: TightVNC macht offenbar beim Client ein lokales Caching der Paßwörter. D.h. der Fehler bzgl. falschen Paßworts kommt auch dann, wenn ich ohne VPN-Verbindung fälschlicherweise mal versuche den Rechner über seine Adresse im heimischen LAN anzusprechen. Die dürfte dann ja überhaupt nicht erreichbar sein und insoweit kann dann auch kein Server feststellen, dass das Paßwort falsch ist. Die Meldung muss also vom Client selbst aufgrund eines Cachings kommen, und ist daher zur Fehlereingrenzung nicht so sehr hilfreich. Bislang war ich davon ausgegangen, dass die Meldung tatsächlich vom Server kommt, dieser also durchaus erreicht worden ist und dann Zicken gemacht hat. Nach dieser neuen Feststellung muss man wohl davon ausgehen, dass man aufgrund der abweichenden Fehlermeldungen (je nachdem ob das Paßwort stimmt oder nicht) nicht davon ausgehen kann, dass der Server überhaupt erreicht worden ist.
BTW: Ich habe bislang nicht viel mit VPNs gemacht, aber meine Ansatz, einfach nur 1723 im Router auf meinen Rechner weiterzuleiten, und dann den VNC-Server über die Adresse des Rechners im LAN ansprechen zu wollen, ist doch richtig, oder?
Gruß vom Wiz, der gerade aus dem Hirschgarten kommt, und den gewonnenen Feiertag bei den Bayuvaren genießt, bevor er morgen wieder ins Projekt muss
BTW: Ich habe bislang nicht viel mit VPNs gemacht, aber meine
Ansatz, einfach nur 1723 im Router auf meinen Rechner
weiterzuleiten, und dann den VNC-Server über die Adresse des
Rechners im LAN ansprechen zu wollen, ist doch richtig, oder?
Port 1723 ist pptp, und wenn mein pptp-Wissen (lang ist’s her…) nicht gänzlich veraltet bzw. verschüttet ist, benötigt pptp zum Verbindungsaufbau zusätzlich das gre-Protokoll, welches ebenfalls auf den offenbar als VPN-Endknoten fungierenden Rechner weitergeletet werden muss. Kann nicht jeder Router, gerade der Speedport 700 scheint für diese Fähigkeit nicht gerade berühmt zu sein. In dem Fall (und sowieso!) wäre für die Zukunft der Einsatz von OpenVPN zu empfehlen.
Aber davon unabhängig müsste der VNC-Server auf jeden Fall ansprechbar sein, wenn du Port 5900 per NAT auf den Rechner weiterleitest und nicht auf dem Router oder dem Rechner irgendwelche Sperrregeln hast, die dem entgegenstehen. Wenn selbst das nicht funktioniert, ist ein routerbedingtes MTU-Problem durchaus nicht auszuschliessen.