by AufAchse » 08 May 2010, 10:17
Hallo,
ich habe vor ein paar Tagen einen TDPS aufgesetzt und habe dabei eine Beobachtung gemacht, die eventuell die Frage beantwortet:
Ich hatte mich bei der IP im Konfig-File vertippt (Zahlendreher). Sprich im Konfig-File hat eine andere IP dringestanden, als die, unter der er erreichbar war.
Der Zugangsschlüssel ließ sich einrichten, jedoch hat der TD-Client sofort gemault, daß die konfickte IP nicht mir der im Client (der richtigen) angegebenen
übereinstimmte.
Laut Doku kann man im Konfig-File auch einen FQDN angeben (also einen Namen). Die Frage ist halt nur, wenn man hier einen Dyndns-Namen o.ä. angibt,
ob das dann Probleme gibt, wenn der Zugriff aus dem lokalen Netz erfolgt. Eventuell muß man in die Trickkiste greifen und bei den lokalen Maschinen den Dyndns-Namen in den jeweiligen lokalen hosts-File einzutragen (kombiniert mit der internen IP und eben nicht der externen).
Falls man im Konfig-File die externe IP direkt angibt (wenn fest vergeben), könnte ich mir vorstellen, daß der ein oder andere WAN-Router Schwierigkeiten macht, wenn der Zugriff auf die WAN-IP von innen kommt. Manche Router verteilen dann lieber per ICMP-Redirect die echte (interne) IP, was dann zu Problemen mit dem TD-Client führen dürfte.
Die Frage ist vor allem, warum diese Angabe im Konfig-File gemacht werden soll. Zur Bindung an eine konkrete lokale Schnittstelle wird sie offenbar nicht herangezogen. Laut netstat -antup ist der tdpsd an die IP 0.0.0.0 gebunden (zumindest unter Linux), was heißt, daß der TDPS auf allen IPs des PCs reagieren würde, unabhängig von der im Konfig-File angegeben. Vielmehr scheint diese Angabe Protokoll-Intern benutzt zu werden (wozu auch immer). Bei mir hat die grundsätzliche Verbindungsaufnahme ja trotz Zahlendreher geklappt. Ob sich das aber auf den realen Betrieb auswirkt, müsste man testen.
Leider schließt dieses Verhalten auch aus, daß man auf der gleichen Maschine mehrere Instanzen des TDPS einsetzt, es sei denn, man verwendet unterschiedliche Ports je Instanz.
Ich habe für mich selbst die Methode per PortForwarding ausgeschlossen. Auch wenn der TDPS auf einem unprivilegiertem Port und auch nicht als root läuft, sollte man dennoch bedenken, daß der TDPS noch eine neue Soft und das Protokoll nicht dokumentiert ist.Inwieweit der TDPS also eventuell eine Sicherheitslücke für das lokale Netz darstellt, ist nur schwer einzuschätzen. ich könnte mir auch vorstellen, daß solche Lösungen in mancher Firma über Sicherheitsrichtlinien verboten ist.
Ich realisiere den Zugriff von Außen per VPN und so löst sich für mich das Problem mit der internen IP und dem externen Zugriff.
Ich hoffe, ich konnte ein wenig helfen.
MfG
AufAchse