Working remote

All people who have done helpdesk work or another support job in the IT area do know the problem by heart: How do you direct users to do exactly what you want them to do? Well – usually you tell them every mouse click. But what if you don’t know the exact word on the buttons or the exact command? Most times the supporter might repeatedly bang his head against the desk and give up.

But as usual, there is that “we will do it” spirit in the IT field, so some bright heads invented remote maintenance software. But according to our experience such software usually just works if you don’t need it or even worse, there’s a firewall or router blocking access to our host preventing our work.

In other words, if you don’t have an admin on the remote site, a common program like VNC just doesn’t work without routing tricks. But what alternatives do we have? The answer’s pretty simple – the remote hands got to run via a server that is reachable by booth hosts: the supporter AND the supported client. Besides that it would be a good thing if the server we’re using as man in the middle would be trustful.

Any ideas?

Author:

15 thoughts on “Working remote”

  • [lang_de]Und wie ich dich kenne, sollte es am Besten sowohl unter Linux als auch unter Windows laufen – und eventuell sogar noch am Handy, oder wie?[/lang_de][lang_en]As I know you, I guess the software should run everywhere – Windows and Linux – and I guess you’d be happy if it would work on a mobile phone too[/lang_en]

  • Tux2000 says:

    Just vor einigen Tagen durchexerziert: Vater (250 km weit weg) hat einen neuen DSL-Router bekommen und dank TR069 halbwegs in Gang gesetzt bekommen. Feintuning sollte ich machen. Also erstmal in MEINEM Router ein Port Forwarding von Port 5500/tcp am Internet auf Port 5500/tcp auf einen MEINER Rechner eingerichtet, dann auf MEINEM Rechner den VNC-Client im Listener-Modus gestartet, und Vater soweit durchtelefoniert, dass er auf SEINEM Rechner den VNC-Server gestartet und dort “Add new client” mit MEINER externen IP-Adresse (bzw. meinem dyndns-Hostnamen) gemacht hat. Ergebnis: SEIN Bildschirm erscheint auf MEINEM Rechner, ohne das er irgendetwas an seinem Router erledigen mußte, und ohne einen dritten Server zu bemühen.

    Technisch gesehen läuft in diesem Fall der VNC-Viewer als TCP-Server und der VNC-Server als TCP-Client. Das ist den beiden aber nach dem Verbindungsaufbau vollkommen egal, und alles funktioniert wie gewohnt.

    Ach ja, irgendwelche Kiddies könnten theoretisch versuchen, sich auf Port 5500/tcp auf meinem Router zu connecten und meinem VNC-Viewer irgendetwas anbieten. Deswegen kann der VNC-Viewer nachfragen, ob ich die Verbindung wirklich herstellen will. Und natürlich läuf t der VNC-Viewer nicht ständig im Listener-Mode.

    Tux2000

  • Tux2000 says:

    Nachtrag: Beide Rechner liefen zufällig unter W2K, das ist aber bei VNC völlig unerheblich, es hätte auch mit MacOS, MacOS X, und Linux funktioniert, auch wild gemischt.

    Tux2000

  • In der Theorie klingt das Ganze ja schon brauchbar, nur sitze ich oftmals auch hinter Router, die ich nicht beeinflussen kann. Trotzdem mal Danke für den Tipp mit dem ‘Backconnect’ beim VNC – ich werd’s bei Gelegenheit testen

  • Tux2000 says:

    Wenn Du einen Unix-basierten (virtuellen oder realen) Server irgendwo im erreichbaren Internet stehen hast, könnte ein SSH-Tunnel weiterhelfen, der eine Connection vom Server auf einen wartenden VNC-Viewer weiterleitet. “ssh -R :5500:localhost:5500 dein.server.example.com” bzw. “ssh -R dein.server.example.com:5500:localhost:5500” sollte funktionieren, nachdem Du einen VNC-Viewer in den Liste-Mode geschaltet hast. Der zu supportende Kunde macht dann ein add client für dein.server.example.com.

    Tux2000

  • Manfred says:

    Die Umwege über einen Server sind genauso umständlich wie der direkte Weg über Ruter und Firewalls. Eine bessere Lösung finde ich ist das auch nicht. Wenn Router und Firewall richtig konfiguriert sind, dann sollte es doch keine Probleme geben. Man muss im lokalen Netzwerk feste IPs oder statische DHCP-IPs vergeben und diese dann freigeben.

  • Ich hab mir mal Teamviewer angesehen und muss zugeben, dass das Ding relativ unkompliziert zu handlen ist. Der Rest war dann dank Virtualisierung auf meiner Seite nicht gerade das Problem :)

  • Ich denke Stargazer denkt über Leute nach, die er zu betreuen hat, an deren Firewall man nicht schrauben kann/darf/soll.

  • Korrekt erkannt. Und wenn man mal via Mobiltelefon oder ähnlichem Gerümpel online ist, sind die Schweinereien die, dass man da hinter der Firewall des Anbieters rumdümpelt…

Leave a Reply

Your email address will not be published. Required fields are marked *