ubuntuusers.de

Verbindungsaufbau mit gitso scheitert außerhalb des LAN

Status: Gelöst | Ubuntu-Version: Ubuntu MATE 16.04 (Xenial Xerus)
Antworten |

_dabear_

Anmeldungsdatum:
17. Juli 2017

Beiträge: Zähle...

Hallo liebe Gemeinde von ubuntuusers.de,

euer Wiki und euer Forum haben mir schon seit Jahren zuverlässig bei Problem geholfen. Ich bin zuversichtlich auch jetzt mit euch mein Problem zu lösen.

Ausgangslage:

  • Ich habe bei einem Verwandten Ubuntu Mate 16.04 LTS installiert.

  • Ich selbst benutze ebenfalls Ubuntu Mate 16.04 LTS (sowohl auf meinem Desktop, als auch meinem Laptop).

  • Zur Fernwartung habe ich mich für https://wiki.ubuntuusers.de/Gitso/ entschieden.

  • Ich bin Kunde bei Kabel-Deutschland und benutze bei mir einen Hitron WLAN-Router.

  • Eine Portweiterleitung von Port 5500 auf die korrekte LAN-IP meines Desktops ist aktiv.

  • Zusätzlich benutze ich den DynDNS-Dienst von https://desec.io. Der Dienst findet auch die korrekte IP meines Routers. Das habe ich überprüft.

  • Damit mein Verwandter wirklich einfach Hilfe erhält, habe ich zusätzlich eine .desktop-Datei angelegt, die sich bei Auswahl direkt über die DynDNS-Adresse verbindet.

  • Mit diesem Setup hat die Verbindung über gitso schon mehrfach funktioniert. Das letzte mal vor ca. 3-4 Monaten.

  • Zur Zeit funktioniert es nicht.

Was passiert:

  • Ich habe den gitso-Server gestartet. Die Applikation gibt mir in der Statuszeile "Server running." zurück.

  • Mein Verwandter startet gitso bei sich über die .desktop-Datei. Sein gitso gibt "Could not connect" zurück.

Im Nachgang habe ich folgendes zwischen meinem Laptop und meinem Desktop-Rechner benutzt. Beide Rechner befinden sich im selben lokalen Netzwerk. Ein Verbindungsaufbau zwischen meinem Laptop (als Client) und meinem Desktop (als Server) funktioniert nicht wenn...

  • ...ich versuche mich über den DynDNS-Dienst zu verbinden.

  • ...ich versuche mich direkt über die öffentliche IP des Routers zu verbinden.

Ein Verbindungsaufbau zwischen meinem Laptop (als Client) und meinem Desktop (als Server) funktioniert wenn...

  • ...ich versuche mich über die lokale IP meines Desktop-Rechners zu verbinden.

  • ...ich versuche mich über dabear-desktop.local (avahi) mit meinem Desktop-Rechner zu verbinden.

Meine Schlussfolgerung ist, dass der Fehler im Router liegen muss. Leider bin ich ratlos wie ich mich an den Fehler herantasten und ihn abstellen kann.

Ich hoffe, dass ich alle wichtige Fakten beschrieben habe. Solltet ich noch wichtige Angaben vergessen haben, fragt einfach nach.

Vielen Dank und viele Grüße, Martin

lionlizard

Avatar von lionlizard

Anmeldungsdatum:
20. September 2012

Beiträge: 6244

Wohnort: Berlin

Da ich ebenfalls KabelDeutschland-Kunde bin, vermute ich, dass es ein IPV4/IPV6 Problem gibt.

Seit ca. einem Jahr bekomme ich nur noch eine IPV6-Adresse zugewiesen, und seitdem habe ich immer wieder Probleme, auf Seiten zuzugreifen, die noch nur über IPV4 zu erreichen sind. Manchmal funktioniert das gut, aber gelegentlich dauert es Ewigkeiten, bis eine Adresse gefunden und die zugehörige Seite aufgebaut wird, mitunter scheitert es ganz. IPV6-Verbindungen funktionieren problemlos. Ich habe es bei mir nicht geschafft, meinen Rechner über dyn-dns erreichbar zu machen (meine Anstrengungen hielten sich aber auch in Grenzen) und benutze stattdessen für die Fernwartung den Teamviewer, was bei mir problemlos funktioniert. Für die private Nutzung ist der Teamviewer auch kostenlos, man muss halt nur dem Hersteller vertrauen - was ich tatsächlich relativ vorbehaltlos mache.

_dabear_

(Themenstarter)

Anmeldungsdatum:
17. Juli 2017

Beiträge: 13

Vielen Dank für Deine Antwort, lionlizard. Was hast Du denn alles probiert um den Fehler bei Dir zu finden und zu analysieren?

Ich befürchte aber, dass mein Fehler woanders liegt als von Dir vermutet.

  • Zum einen schreibt deSEC, dass sie IPv6 unterstützen (https://desec.io/#!/de/product/dyndns).

  • Zum anderen bekomme ich in der Übersichtsseite meines Routers angezeigt, dass ich per IPv4 verbunden bin. Die Anzeige für eine IPv6-Verbindung zeigt keine Verbindung ('–––'). Auch https://www.wieistmeineip.de/ zeigt an, dass ich nicht über IPv6 verbunden bin.

Hat sonst noch jemand eine Idee?

Die Verwendung von TeamViewer kommt bei mir leider nicht in Frage, da hier der Hilfesuchende erst einmal die Sitzungsnummer des Hilfegebenden eingeben muss. Gerade die Möglichkeit meinem Verwandten eine One-Klick-Solution anzubieten war für mich der ausschlaggebende Grund mich für gitso zu entscheiden.

lionlizard

Avatar von lionlizard

Anmeldungsdatum:
20. September 2012

Beiträge: 6244

Wohnort: Berlin

_dabear_ schrieb:

Vielen Dank für Deine Antwort, lionlizard. Was hast Du denn alles probiert um den Fehler bei Dir zu finden und zu analysieren?

Erinnere ich nicht mehr

Die Verwendung von TeamViewer kommt bei mir leider nicht in Frage, da hier der Hilfesuchende erst einmal die Sitzungsnummer des Hilfegebenden eingeben muss. Gerade die Möglichkeit meinem Verwandten eine One-Klick-Solution anzubieten war für mich der ausschlaggebende Grund mich für gitso zu entscheiden.

Das ist so nicht ganz richtig. Man kann ein Teamviewer-Konto anlegen, und diesem Konto beliebige Rechner hinzufügen (gibt wohl eine Begrenzung bei 30 Stück oder so), sofern darauf Teamviewer installiert wurde. Wenn ich am Teamviewer-Konto angemeldet bin, sehe ich alle hinzugefügten Rechner, sobald dort Teamviewer gestartet wurde. Nun genügt, je nach Konfiguration, ein Klick von mir, um mich auf den Rechner zu verbinden.

Auf diese Art warte ich seit Jahren den Rechner meines Bruders, früher Windows, heute Kubuntu. Indem beim Teamviewer der Autostart akiviert ist, kann ich sogar in dessen Abwesenheit das System neu starten lassen, wenn dies Not tut. Bei anderen sage ich nur, dass sie den Teamviewer starten sollen, und ich kann mich sofort drauf verbinden, sobald die Internet-Verbindung steht.

Ist eben nur eine Frage des Vertrauens gegenüber Teamviewer, aber das habe ich.

_dabear_

(Themenstarter)

Anmeldungsdatum:
17. Juli 2017

Beiträge: 13

Hallo liebe Gemeinde von ubuntuusers.de,

es gibt inzwischen Neuigkeiten von mir über dieses Problem.

lionlizard hatte zwar bereits mit TeamViewer einen funktionierenden Lösungsvorschlag gemacht, ich wollte aber trotzdem wissen, wieso auf einmal gitso (bzw. rvnc) nicht mehr funktionierte.

Leider muss ich etwas ausholen, da dann schlussendlich mehrere Aspekte zusammen kamen bis ich eine funktionierende Lösung des Problems hatte. Ich habe viele Male mit dem Kundenservice von Vodafone (ehem. Kabel-D) telefoniert und habe dann sogar die Support-Nummer des Router-Herstellers Hitron genannt bekommen. Dort wurde mir ebenfalls kompetent geholfen und ich konnte einige mögliche Fehlerursachen (bspw. Router-FW oder falsche Nutzereinstellungen) ausschließen. Danach hatte ich den Kundenservice so weit, dass bei mir eine Einstellung aktiviert wurde, sodass ich ausschließlich per IPv4 ins Internet verbunden werden sollte. Leider sind fast zeitgleich massive Verbindungsprobleme bei meinem Anschluss aufgetreten. Dadurch war es mir unmöglich zu testen, ob ich jetzt wirklich konsequent per IPv4 verbunden bin.

Im Zuge der Verbindungsprobleme habe ich dann von Vodafone einen neuen Router gestellt bekommen. Dieser ist ein Modell CH6640E (Firmware-Version: CH6640-4.5.0.5-NOSH) von der Firma CBN Inc. Das ist auch ein einfaches Modell ohne DDNS-Client. Der neue Router hat sich dann konsequent mit IPv4 und IPv6 eingewählt. Nur die IPv6 wurde jedoch von dedyn.io detektiert. Nun konnte ich mich auch wieder über den DDNS-Service von dedyn.io von meinem Laptop auf meinen PC verbinden. Allerdings nicht, wenn ich einen AccessPoint außerhalb des Vodafone-Netzwerkes gewählt habe (bspw. Telekom-DSL). Bei solchen AccessPoints funktionierte der Verbindungsaufbau nur mit der IPv4 aus dem Router, die von dedyn.io allerdings nicht detektiert wurde. Da der Standard-Router von Vodafone keinen DDNS-Client mitbringt, bin ich sowieso auf lokale Lösungen, wie ddclient angewiesen. Dafür bietet dedyn.io auch eine gute Dokumentation an. Hier habe ich dann unter 'Manual configuration (other systems)' schlussendlich auch die Lösung gefunden. In der ddclient.conf wird zuerst eine REST-Schnittstelle von dedyn.io aufgerufen, die mir meine IPv4 zurück liefert. Und diese IP wird dann dem Update-Server von dedyn.io mitgeteilt.

Was jetzt genau die Fehlerursache war kann ich nicht mit Sicherheit sagen. Ich vermute, dass es sowohl einen Zusammenhang mit dem Hitron-Router hatte, als auch mit den Einwahleinstellungen bei Vodafone. Wichtig ist nur, dass jetzt alles genau so funktioniert wie vorher.

Vielen Dank an lionlizard dass er mich auf den richtigen Weg mit IPv4 und IPv6 gebacht hat und mit TeamViewer eine weitere Lösungsmöglichkeit erläutert hat.

Viele Grüße, Martin

Antworten |