Reverse SSH Tunnel - Schritt für Schritt

Mobile, Netzwerk, Raspberry Pi, , , , , , , ,

Ein Reverse SSH Tunnel ist immer dann hilfreich, wenn man auf einen Raspberry Pi, der hinter einer Firewall läuft, zugreifen will und die Firewall nicht selbst für Zugriffe von außen freischalten kann.
Zum Beispiel, wenn der Pi per Mobilfunk mit dem Internet verbunden ist. Mobilfunkprovider lassen meist keine Zugriffe von außen auf die im Netz vorhandenen Clients zu. Außerdem wird in der Regel eine Network Address Translation (NAT) vorgenommen, um IP Adressen zu sparen. Ganz ähnlich wie bei eurem Router zuhause. 

Dieser Beitrag ist zwar schon ein paar Jahre alt; ich aktualisiere ihn aber laufend nach Erkenntnisfortschritt oder bei Änderungen im Raspberry Pi OS (ehemals Raspbian):

Eingerückte Texte sind zusätzliche Erklärungen und Exkurse. Wenn ihr es eilig habt, dann könnt ihr das auch überlesen.

Begriffsklärung

Für das weitere Verständnis dieses Artikels möchte ich einige Begriffe definieren

  • Remote Pi: Das ist der Raspberry Pi, der im Mobilfunknetz hängt und auf den "von außen" zugegriffen werden soll
  • Gateway Pi: Das ist der Raspberry Pi, mit dem sich der Remote Pi verbindet und über den auf den Remote Pi zugegriffen werden soll
  • SSH: Secure Shell, ein Protokoll bzw. Programm, das auf beiden Rechnern läuft. Normalerweise ist SSH schon aktiviert, andernfalls über sudo raspi-config den Punkt "Advanced Options - SSH" auswählen.
    Achtung:  Bei Raspbian ab ca. Dezember 2016 ist SSH standardmäßig deaktiviert! Bitte die Hinweise in diesem Artikel meines Blogs beachten.
    SSH dürfte jeder kennen, der über Putty oder ein anderes Terminalprogramm auf den Pi zugreift.
  • Dynamische IP Adresse. In der Regel hat ein Privatmensch keine statische IP Adresse sondern bekommt von seinem Provider in regelmäßigen Abständen eine neue IP Adresse verpasst. Damit die gerade aktuelle Adresse überhaupt gefunden wird, sollte man sich eine Dynamische IP Adresse zulegen. Das geht über spezialisierte DynDNS Provider wie Selfhost. Wenn man bereit ist, diese Adresse monatlich zu bestätigen, kostet das dort noch nicht einmal etwas.
  • Hinweis zu IPv6 und DS-Lite: diese Anleitung funktioniert nur, wenn das Gateway über eine öffentlich erreichbare IPv4 Adresse im Internet hängt. Der Zugriff auf Heimnetzwerke, welche nur eine öffentliche IPv6 Adresse haben, ist ungleich schwieriger und funktioniert auch nur, wenn der Remote Client ebenfalls mit IPv6 im Internet ist. Bei Mobilfunknetzen wird bislang (Ende 2017) fast nur mit IPv4 gefunkt.  Betroffen sind Alle, die Zuhause (Gateway) mit DS-Lite (ausschließliche IPv6 Verbindung) am Internet angeschlossen sind. Hier nützt meine Anleitung leider nichts. Ggf. kann man beim Provider aber eine IPv4 Adresse nachbuchen - gegen Aufpreis versteht sich.

Was benötige ich dafür?

Folgende Voraussetzungen sind zu erfüllen:

Allgemein

  • Alle Eingaben etc. erfolgen im Terminalmodus bzw. über ein Terminalfenster vom Raspberry Desktop.
  • Ferner gehe ich davon aus, dass immer der User Pi verwendet wird, Raspbian in einer aktuellen Version installiert ist, und du schon etwas Erfahrung mit dem Terminalmodus des Pi sowie mit Putty oder einem anderen Terminalprogramm hast.

Remote

  • Logischerweise einen Raspberry Pi, sonst macht das alles ja keinen Sinn.
  • Je nach Setup (DSL oder Mobilfunk) einen (mobilfunkfähigen) Router und unbedingt einen Flatrate Tarif, sonst wirds teuer, da der Tunnel immer wieder ein paar Byte durch den Äther jagt. Der Remote Router braucht keine Portfreigabe.

Gateway

  • Einen weiteren Raspberry Pi - oder einen (Linux) Rechner als Gateway, auf dem SSH läuft. Die Gatewayfunktion übernimmt der Pi nur so nebenbei, darauf können problemlos noch zusätzlich und gleichzeitig ein OwnCloud und ein WordPress Server laufen. Der Pi ist ideal für diese Aufgabe, kostet wenig und braucht nur wenig Energie, kann also 7/24 in Betrieb sein. Ob der Pi einen Monitor hat oder headless betrieben wird, ist egal. Wichtig ist nur, dass dieser Raspberry Pi aus dem Internet erreichbar ist.
  • Router am Gateway Pi mit Port Freischaltung für den SSH Port Nummer 22 - oder besser einen alternativ konfigurierten Port z.B. Port 2000. Ggf. kommen noch weitere Portfreigaben hinzu. Wie man einen alternativen SSH Port einstellt, ist in diesem Post hier beschrieben. Dort auch die Möglichkeiten einer Absicherung zu Gemüte führen. Durch die Portfreischaltung hat eure Firewall ein Loch bekommen und euer Netz ist somit angreifbar.
  • Dynamische IP Adresse sollte unbedingt vorliegen, sonst machts keinen Spaß.
    Dann noch den Router so konfigurieren, dass er seine aktuelle IP Adresse an den DynDNS Provider meldet.
  • Nachdem der Router am Gateway Pi konfiguriert ist, muss man am Gateway Pi  initial nur die SSH Konfiguration einstellen.  Du könntest anschließend zu deinem Remote Pi in den Urlaub fahren und alles Weitere dort konfigurieren. Idealerweise hat man beide Pis natürlich zuhause, konfiguriert und testet dort alles und fährt dann mit dem Remote Pi in Urlaub.

Wie funktioniert das überhaupt?

Vereinfacht ausgedrückt, baut der Remote Pi selbständig eine Verbindung zu einem anderen Rechner (Gateway) auf. Diese Verbindung (der Tunnel) wird aufrecht gehalten. Das Gateway kann nun selbst über den Tunnel mit dem Remote Pi Kontakt aufnehmen, oder ein dritter Rechner (z.B. Putty auf einem Windows PC) greift via Gateway Pi und Tunnel auf den Remote Pi zu.

Ein Reverse SSH Tunnel macht überall dort Sinn, wo man wegen eines Firewalls, Network Address Translation oder sonstiger Hemmnisse nicht von außen auf einen Rechner zugreifen kann. Der Tunnel funktioniert, solange der Remote Rechner über das Netzwerk, mit dem er verbunden ist, ins Internet kommt. Ob mit WiFi, Kabel oder Mobilfunk ist völlig egal. Es versteht sich von selbst, dass das hier beschriebenen Verfahren nur dort verwendet werden darf, wo auch die Erlaubnis dafür besteht. Also z.B. im eigenen Netzwerk bzw. im Auftrag eines Kunden in dessen Netzwerk. Die Verwendung des Reverse SSH Tunnels als illegale oder halblegale Hintertür z.B. ins Netzwerk des eigenen Arbeitgebers wird früher oder später entdeckt werden und hat in der Regel arbeits- bzw. strafrechtliche Konsequenzen.

Schritt 1a: SSH Konfiguration auf dem Gateway Pi

Um später für unterschiedliche Anwendungsfälle gewappnet zu sein, sollten folgende Einstellungen am Gateway Pi vorgenommen werden:

In früheren Versionen der Anleitung fehlten diese Hinweise auf die Gateway Konfiguration. Während meiner vielen vergeblichen Versuche, so ein Reverse Tunnel hinzubekommen, hatte ich diese Einträge wohl einmal vorgenommen und dann vergessen, dass ich sie hatte... Danke an Hannes für die ensprechende Fehlermeldung und fürs Finden der Lösung! (siehe Kommentare)

Editiert die Datei /etc/ssh/sshd_config als root - z.B. mit dem eingebauten Editor nano:

dort dann am besten folgende Einträge suchen und abändern bzw. die Einträge am Ende vornehmen:

Mit den ersten beiden Zeilen wird sichergestellt, dass die Verbindung nicht einfach wieder abgebaut wird, wenn eine Zeitlang keine Daten über die Leitung flutschen.

GatewayPorts yes erlaubt es, das Gateway quasi als "Durchlauferhitzer" zu nutzen, d.h. von einem anderen Gerät über den Gateway Pi in der Mitte auf den Remote Pi zuzugreifen.

AllowTcpForwarding yes erlaubt es, auch andere Protokolle - z.B. http -  im SSH Tunnel zu verpacken.

Sind die Änderungen eingetragen, nano mit Strg-X beenden, bei der Frage, ob die geänderte Datei gespeichert werden soll, mit "J" antworten und anschließend die Eingabetaste drücken. Anschließend neu booten.

Schritt 1b: Aufbau SSH Tunnel auf dem Remote Pi

Am Remote Pi geben wir folgenden Befehl ein:

Erläuterung der Parameter:
-p2000 (optional) abweichender Port des Gateway Pi über den der Remote Pi den Tunnel aufbaut. Kann auch weggelassen werden dann wird automatisch die Portadresse 22 genommen. In jedem Fall muss die gewählte Portnummer im Router des Gateway Pi freigeschaltet werden. Wie man das anstellt, habe ich im Artikel Dynamische IP Adresse mit Bordmitteln im Kapitel Portfreischaltung (Beispiel Fritz!Box) beschrieben.
-f bedeutet, dass ssh im Hintergrund laufen soll. Anschließend kann das Terminalfenster wieder geschlossen werden, SSH läuft aber im Hintergrund weiter.
N bedeutet, dass lediglich der Tunnel aufgebaut wird, aber keine Remote-Kommandos entgegen genommen werden.
C (optional) komprimiert die über die Strecke laufenden Daten. Achtung, dieser Parameter verschlechtert unter Umständen die Performance - also ausprobieren.
-R besagt, dass ein Reverse Tunnel aufgebaut werden soll.
10011 ist der Ausgangsport (outgoing port address) des Gateway Pi. Startet man dort eine SSH Sitzung über den Port 10011, kommt man beim Remote Pi raus. Im Prinzip kannst du jede Portadresse über 1024 verwenden, die nicht schon von deinem Pi belegt ist. Eine Liste der standardisierten Ports findest du z.B. bei Wikipedia.
localhost ist der Name unter dem ein Rechner sich selbst erkennt; also ein "ich" oder ein "bei mir".
Falls ihr über den Tunnel, der beim Remote Pi ankommt, weitere Geräte im Remote Netzwerk ansprechen wollt, dann kann statt localhost auch die lokale IP Adresse eines Remote Netzwerkgeräts stehen. Siehe weiter unten bei "externe Geräte ansprechen".
22 ist die Standard SSH Portnummer des Remote Pi.
pi@dyn.IP.adresse ist der User- und Servername der auf dem Gateway Pi verwendet wird - dyn.IP.adresse ist die Adresse (URL) des Gateway Pi über den man auf den Remote Pi zugreifen will. Bitte entsprechend deine dynamische IP Adresse eintragen. Anstatt "Pi" kannst du natürlich auch jeden anderen User verwenden, der auf dem Gateway Pi angelegt ist.

Im deutschen Raspberry Pi Forum kam im Dezember 2017 eine interessante Diskussion auf - es drehte sich u.a. um die Frage, welchen User man in das obige Kommando einträgt. Ich habe der Einfachheit halber den User "pi" genommen, da der ja sowieso schon auf dem Raspberry Pi vorhanden ist. Natürlich kann hier jeder beliebige Nutzer genommen werden. Wichtig ist nur, dass dieser User auf dem Gateway angelegt wurde - also ein Konto hat.

Erster Test:
Probiers mal aus, d.h. gebe oben stehendes Kommando am Remote Pi ein. Wenn alles stimmt, wirst du zusätzlich noch das Passwort des Users Pi vom Gateway Pi eingeben müssen.

Hinweis: sollte das nicht funktionieren, kann es sein, dass der Remote Pi den SSH Key vom Gateway noch nicht kennt. In diesem Falle am Remote Pi einfach
ssh pi@dyn.IP.adresse
bzw.
ssh -p2000 pi@dyn.IP.Adresse
und die Abfrage mit yes bestätigen. Es scheint, dass Raspbian Stretch etwas weniger tolerant ist als Jessie oder  Wheezy.

Auf dem Gateway Pi kann man sich nun mit dem Befehl

auf dem Remote Pi einloggen. Das kann man übrigens auch tun, wenn man nicht vor Ort ist. Dazu einfach auf dem Gateway Pi mit Putty einloggen - anstatt der IP Nummer aus dem Heimnetz, die dyn.IP.Adresse in das Adressfeld eingeben und ggf. noch eine abweichende Portnummer eintragen. Das geht natürlich nur, wenn der entsprechende Port im Router zuhause auch freigeschaltet ist. Ihr kommt dann beim Gateway Pi raus und könnt dort den obigen Befehl eingeben.

Hier könnte man fragen, warum man da localhost nimmt und nicht die IP Adresse des Gateway Pi. Theoretisch ginge das, allerdings hat das den Nachteil, dass die Verbindung erst nach draußen zum Router oder Switch im lokalen Netzwerk aufgebaut wird und dann wieder zurück zum Gateway geleitet wird. Das ist umständlich und verlangsamt die Geschichte. Außerdem kann es ja sein, dass die IP Adresse neu vergeben wird - dann führt die angegebene IP ins Leere. Bei Verwendung von "localhost" weiß der Pi, dass er das alles lokal bei sich "zu Hause" abwickeln kann.

Perfekt? Nein, nicht ganz: Das Eingeben des Gateway Passworts beim Aufbau des Tunnels nervt und führt dazu dass der Tunnel nur mit Nutzereingriff d.h. manuell aufgebaut werden kann. Und wir wollen ja eine automatische Löung. Deshalb...

Schritt 2: Login ohne Passwort

Neben der Passworteingabe zum Login kann man einem entfernten Rechner auch seine "Ausweisdaten" d.h. einen RSA Key übermitteln, anhand dessen dann der anrufende Rechner erkannt und akzeptiert wird. Auf unseren Fall übertragen heißt das, wir müssen den öffentlichen RSA Key des Remote Pi auf den Gateway Pi übertragen.
Dazu erst einmal auf dem Remote Pi nachschauen, ob im Verzeichnis /home/pi/.ssh (oder auch ~/.ssh) bereits eine Datei id_rsa.pub existiert. Wenn nein, muss man den Schlüssel erst erzeugen:
Das geschieht mit

Nach Belieben die vom Programm abgefragten Daten eingeben, die Passphrase aber leer lassen, wir wollen uns ja automatisch mit dem Gateway verbinden.
Nun muss man den erzeugten Schlüssel (RSA 2048 Bit) auf das Gateway kopieren. Dazu folgenden Befehl am Remote Pi eingeben:

Hat man auf dem Gateway Pi eine andere SSH Portadresse (z.B. 2000) eingerichtet, lautet der Befehl wie folgt:

Bei älteren Versionen von Raspbian (vor Jessie) musste -p 2000 pi@dyn.IP.adresse  in Anführungszeichen gefasst sein.

Testen kannst du das auf dieselbe Weise wie oben.

Sollte das Kopieren der ID mit einem Berechtigungsfehler scheitern, musst du dich mit SSH vom Remote aus einmal beim Gateway einloggen. Damit kennt der Remote das Gateway und akzeptiert auch den Copy Befehl.

Wichtig:
Hat der User Pi den Schlüssel erzeugt, muss der User Pi auch den Tunnel
starten. Wenn du nachher (Schritt 4) die Crontab zum automatischen Start nach Reboot verwendest, dann muss es die Crontab vom User Pi sein. Diese erzeugst/editierst du indem du dich als "pi" enloggst und dann crontab -e eingibst.
Merke: Außer für Schritt 1a brauchst du den superuser sudo nicht!! Alle Eingaben erfolgen als User Pi bzw. mit dem User, den du für deinen Tunnel verwenden willst.

Für Spezialisten: Wollt ihr irgendwann später ein neues/anderes Gateway installieren, z.B. wg. HW-Tausch, dann könnt ihr das auch ohne Zugriff auf den Remote Pi durchführen. Dazu die Dateien in ~/.ssh an dieselbe Stelle des neuen Rechners kopieren – damit erkennt das Gateway den Remote Pi. Außerdem noch alle Dateien in /etc/ssh auch in das Verzeichnis /etc/ssh des neuen Gateways – damit erkennt der Remote Pi das Gateway als alten Bekannten. Dabei beachten, dass die Permissions und Besitzer mitkopiert bzw. hinterher entsprechend auf identische Werte umgestellt werden müssen.

Gut, aber immer noch nicht perfekt!

Schritt 3: Stabilisieren

Gerade wenn der Remote Pi über Mobilfunk im Internet hängt, kann es vorkommen, dass die Verbindung hin und wieder kurz unterbrochen wird. (Das passiert übrigens auch bei den meisten DSL Providern. Irgendwann nachts setzt der Provider die Verbindung zurück.) In diesem Falle bricht der Tunnel geräuschlos aber unerbittlich zusammen. Man könnte jetzt ein Skript schreiben, das die Verbindung laufend überprüft und bei Bedarf neu aufbaut. Das ist zum Glück überflüssig, denn es gibt mit autossh eine Erweiterung (eigentlich einen Wrapper) für SSH. Einfach autossh anstatt ssh verwenden und schon haben wir ein stabiles System. Perfekt? Leider immer noch nicht, denn autossh hilft nichts, wenn der Remote Pi z.B. wegen eines Stromausfalls neu startet.

Möglicherweise ist autossh noch nicht auf dem Pi installiert. Dem kann man ganz einfach mit
sudo apt-get install autossh
abhelfen.

Schritt 4: Autostart

Wir erstellen ein Script mit Namen tunnel.sh, in das wir den Reverse SSH Tunnel Befehl eintragen:

Dieses Script legen wir im Homeverzeichnis ab. Mit

machen wir es ausführbar.

Alles was automatisch beim Start oder in regelmäßigen Abständen laufen soll, wird per Crontab aufgerufen. Dazu folgender Befehl:

Es erscheint die Crontab im Editor - ganz nach unten scrollen und folgende Zeile eingeben

mit Strg+X speichern wir die Crontab und verlassen den Editor.

In einer früheren Version dieser Anleitung hatte ich die Crontab als Superuser mit sudo crontab -e editiert. Das hatte zur Folge, dass der Tunnel beim Start vom Superuser bzw. Root und nicht vom User Pi aufgebaut wurde. Wenn nun der Root seine ID noch nicht im Gateway Pi hinterlegt hat, dann baut sich der Tunnel nicht auf, da der passwortlose Login nicht funktioniert; es sei denn, du hast vorher den Schlüssel mit "sudo ssh-keygen" erzeugt und mit "sudo ssh-copy-id" übertragen. Dieses Problem ist bei mir lange nicht aufgefallen, da ich wohl bei Basteleien irgendwann vorher die ID vom Root des Remote Pi auf den Gateway Pi kopiert hatte.

So! jetzt ist es annähernd perfekt. Der SSH Tunnel startet nach jedem Reboot und ist nun komplett, stabil und betriebssicher. Bitte beachtet, dass der Tunnel unter Umständen nicht sofort nach dem Reboot steht, sondern einige Minuten braucht, um die Verbindung zum Gateway herzustellen. Ich vermute, dass die WLAN Verbindung noch nicht sauber steht, wenn das autossh Kommando das erste mal abgearbeitet wird. Mit autossh stellen wir aber sicher, dass die Verbindung anschließend automatisch hergestellt wird.

Ich habe allerdings festgestellt, dass sich der Gateway Pi hin und wieder, d.h. alle paar Wochen, zu verabschieden schien. Das lag aber dann meist daran, dass meine Fritz!Box ihren Aufgaben nicht vollständig nachkam und die Portweiterleitung bestreikte. Nach einem Reboot der Fritz!Box (auch per Fernzugriff möglich) gings dann wieder.

Nochwas: Auch der Router am Remote Pi scheint manchmal seine Probleme zu haben. Unter Umständen ist das Mobilfunknetz so stark überlastet, dass der Router, bzw. der Internet Stick daran sich einfach nicht verbinden will. Nach zu vielen Fehlversuchen streikt der Router dann - zumindest der von mir verwendete TP-Link Mobilfunk Router TL-MR3420. Dann hilft nur ein physikalischer Reset des Routers. Auch dafür gibts eine Lösung mittels Fernschalt-Steckdosen und 433MHz Sender am Pi. Dazu habe ich einen eigenen Artikel geschrieben.

Schritt 5: Browsen im Tunnel

Bisher haben wir lediglich reines SSH Protokoll durch den Tunnel geschickt. Unser Remote Pi kann ja auch als Webserver laufen, z.B. um Temperaturen vor Ort anzuzeigen oder Bilder einer Webcam. Damit wir auch http d.h. Browserdaten durchs Tunnel schicken können, passen wir unser Skript bzw. den Befehl darin wie folgt an:

8000 ist die Portnummer mit der die http Daten vom Gateway zum Remote Pi umgelenkt werden.
80 ist der Standardport für http. Schickt man beim Gateway etwas an Port 8000, kommt es beim Remote Pi an Port 80 wieder an. Und 80 ist der Port, mit dem der Webserver normalerweise kommuniziert.
Will man nur aus dem eigenen lokalen Netzwerk auf den Remote Pi zugreifen, gibt man in den Browser die IP Adresse des Gateway Pi ein, gefolgt von einem Doppelpunkt und der Ausgangsportnummer für http. Also zum Beispiel:

Damit das funktioniert, braucht man logischerweise einen installierten Webserver auf dem Pi - z.B.  Apache oder Lighttpd.

Im Zuge des allgemeinen Trends, den User für unmüdig zu halten, hat Firefox spätestens ab Version 75 geruht,  den Zugriff auf http Seiten (also ohne SSL Verschlüsselung) zu erschweren. Will man "von außen" mit Firefox für Windows über Router Portfreischaltung und das Gateway einen auf dem Remote gehosteten Webserver erreichen, (sinngemäß http://deine Website.net:7555) kann es passieren, dass die Remote Website nicht funktioniert. Das passiert dann, wenn man unter deineWebsite.net auch noch eine SSL verschlüsselte Website (z.B. auf dem Gateway) betreibt.
Abhilfe geht wie folgt: Im Firefox Profilordner die Datei

sitesecurityservicestate.txt

editieren und die Zeile, welche deineWebsite.net enthält, rauslöschen. Dumerweise wird Firefox beim nächsten Zugriff auf die SSL verschlüsselte Seite diesen Eintrag wiederherstellen. Falls das zu sehr nervt,

sitesecurityservicestate.txt

als Readonly einstellen (Rechtsklick auf Dateinamen - Eigenschaften - schreibgeschützt).  Wie man das mit FF für iOS hinbekommt, habe ich noch nicht herausgefunden.

Firefox hat noch ein paar andere Schweinereien auf Lager, die künftig https erzwingen und unverschlüsselte Seiten ins Abseits stellen. Infos hierzu z.B. bei Heise.de

Externe Geräte ansprechen

Extern bedeutet in diesem Kontext andere Geräte im Remote Netzwerk. Wenn ihr also eine IP Cam mit einem Browser über den Tunnel ansprechen wollt, dann einfach anstatt localhost die IP Adresse des externen Geräts verwenden.

Hat die Cam z.B. die lokale Adresse 192.168.178.120 dann wird das Tunnelskript von oben wie folgt erweitert:

über die Parameter -R 8889:192.168.178.120:80 wird alles was auf Port 8889 ankommt, auf den http Port 80 des externen Geräts, z.B. einer Cam umgeleitet.
Auf einem PC im Netz des Gateway Pi gebt ihr im Browser die IP des Gateway Pi ein, gefolgt von einem Doppelpunkt und dem Port 8889. Wenn alles klappt, kommt ihr bei der Remote Cam - oder was auch immer ihr ansprechen wollt  - heraus. Ihr könnt  auf diese Weise auch euren remoten Router ansprechen und administrieren.

Herzlichen Dank an Reto Huber für diesen genialen Tipp!

Mehr darüber in einem eigenen Beitrag .

Zugriff von "Außen"

Will man auch von "außen", also außerhalb des Heimnetzwerks, auf eine beim Remote Pi gehostete Website zugreifen, muss man im Router des Heimnetzwerks zusätzlich die Portadresse 8000 (oder was immer du gewählt hast) freischalten. Der Aufruf erfolgt dann so:

Auch hier braucht ihr natürlich einen Webserver auf dem Remote Pi.

196 Gedanken zu „Reverse SSH Tunnel - Schritt für Schritt“

  1. Hallo Chris

    Danke für die Rückantwort.
    Die WEBCam hängt am USB HUB des RemotePI und wie erwähnt habe ich ja ein Bild wenn ich die WEB Seite im RemotPI Netzwerk aufrufe.
    Das hier ist mein Aufruf im Browser um meine Seite aufzurufen:
    http://myDynDNSAdresse:8000/gpio.php?S02_ALLE_AUS=Alle+AUS
    Hier habe ich gerade ALLE Funkschalter ausgeschaltet.
    Diese Adresse habe ich fest bei mir im Internetbrouwser gespeichert.
    Unter W7 wähle ich mich dann in eines von meinen beiden WLAN Netzen ein und rufe diese Seite dann auf. Beim RemotePI Netz habe ich dann ein Bild, aber im GatewayPI Netz an der Stelle des Bildes ein "kein Video" stehen. Das hier ist die aktuelle Zeile für das Video:

    ich hatte auch an der Stelle der IP Adresse "192.168.0.4" die "DynDNS" stehen aber ohne Erfolg.

    Gruß Herbert

    Antworten

  2. Hallo Chris

    Ich habe eine erste WEBSeite auf dem RemotPI erstellt im Verzeichnis /var/www/.
    Diese kann ich nun von meinem Heimnetz vom Laptop, Tablet oder von meinem Handy aus aufrufen. Dort sind dann auch meine Schalter aufgebaut und diese Schalter können nun die vorhanden Funksteckdosen beim entfernten RemotePI über die GPIO und einem Funksendemodul ein und aus schalten.
    Auch ein Bild meiner Enkelkinder ist auf der WEBseite eingefügt zu sehen.
    Nur das Bild der Webcam wird nicht angezeigt.

    Gruß Herbert

    Antworten

    1. Hallo,
      na wenn du deinen Pi Remote über den Tunnel bedienen kannst, dann ist ja fast alles in Butter 🙂
      Wie bindest du denn die Webcam ein? Welches Programm verwendest du dafür?
      Ich habe mich als blutiger Anfänger seinerzeit an diese Anleitung gehalten: http://www.laub-home.de/wiki/Webcam_Snapshot_Skript
      Bei nicht bewegten Bildern besteht der Trick darin, die Webcam dazu zu veranlassen, ein Bild als JPG oder ähnliches zu erzeugen und auf der Karte abzulegen.
      Dieses wird dann über das html Tag img in die Website eingebunden. z.B. so: img src="bild.jpg" width="800" style="border:5px solid #ffffff". Das ist dann nicht anders, als bei dem Bild von deinen Enkelkindern.
      Du kannst mir den Code auch an folgende (Wegwerf-)Email Adresse schicken: 15e4d75b@opayq.com
      N.B. Diese Adresse existiert so lange ich es will und wird in dem Augenblick blockiert, wenn ich darüber zugespammt werde. Ich bin mit in Blogs veröffentlichten Adressen inzwischen sehr vorsichtig. Der von mir verwendete "Blur" Dienst von abine.com ist übrigens ausgesprochen empfehlenswert.
      Grüße
      Chris

      Antworten

  3. Hallo Rustimator

    Das mit dem LM Rechner hatte ich nach kurzer Überlegung nicht versucht da Du recht hast. Ich bin soweit das ich die Verbindung stehen habe und den RemotePI jetzt entfernt stehen habe. Mein GatewayPI steht am Arbeitsplatz auf dem ich über SSH zugreife und von da wie von Dir erklärt auf den RemotPI. Wenn ich es richtig verstanden habe wäre es ja eigentlich umgekehrt das de RemotePI die Verbindung zum GatewayPI hält. Ich habe aber folgendes nicht verstanden. Wenn ich auf den RemotePI zugreifen will verbinde ich mich zuerst von meinem Laptop über Putty mit dem Gateway PI und von dort aus zum RemotePI. Möchte ich aber z.B. Daten austauschen mit dem RemotPI kann ich direkt bei FileZilla mich auf dem RemotPI einlogen. Warum brauche ich da nicht den GatewayPI?

    Grüße aus Dorsten Herbert

    Antworten

    1. Hallo Herbert,
      Weihnachtszeit, Bastelzeit...
      Bei einem Reverse Tunnel geht die Verbindungsaufnahme immer vom entfernten (Remote) Partner aus. Der legt gewissermaßen einen Klingeldraht zum Gateway. Dort muss man sich nur aufschalten, indem der richtige Port angesprochen wird.
      Brauchen tust du das nur, wenn du nicht direkt auf den Remote Pi draufkommst, z.B. weil er hinter einer Firewall liegt oder per Network Address Translation (NAT) verschattet wird. Da Remote ja normalerweise ohne weiteres ins Internet kommt, wird so die Firewall etc. einfach "durchbohrt" bzw. "untertunnelt".
      Liegen Remote und Gateway im selben Netzwerk, brauchst du das natürlich nicht; ebensowenig, wenn der Remote Pi aus dem Internet erreichbar ist. Bei Mobilfunk ist das aber i.d.R. nicht der Fall.
      Du kannst auch direkt via Putty auf den Remote Pi zugreifen, ohne erst eine Sitzung auf dem Gateway aufzumachen. Im Feld IP Adresse die (dyn)IP Adresse des Gateways eintragen und bei Port nicht die 22 sondern die vom Remote Pi definierte Portnummer eingeben. Das geht auch bei Verwendung von WinSCP oder FileZilla. Die Verbindung landet dann zwar erst auf dem Gateway, wird aber sofort weitergeroutet, ohne dass dort eine sichtbare Session läuft.
      So kannst du auch Webseiten auf dem Remote Pi direkt aus dem Browser ansprechen, indem du in die URL Zeile die (dyn)IP des Gateways einträgst gefolgt von einem Doppelpunkt und die definierte Portnummer für den Remote Pi Port 80. Das sähe dann ungefähr so aus:
      /usr/bin/autossh -p 2222 -fN -R 8888:localhost:80 pi@deine.dyn.IP Wenn du das von unterwegs aus dem Internet heraus über das Gateway zuhause machen willst, musst du logischerweise noch die entsprechende IP Adresse in deinem Router durchlassen. Für die Fritzbox hab' ich das in meinem Blog beschrieben.
      und im Browser die URL http://deine.dyn.IP:8888
      Lange Rede, kurzer Sinn: Dass du mit FileZilla direkt auf den Remote Pi kommst, liegt entweder daran, dass Remote und Gateway im selben Netz sind oder dass du in FileZilla (aus Versehen?) die passende Portnummer eingetragen hast. Mehr fällt mir momentan dazu nicht ein.

      Antworten

      1. Hallo Rustimator

        Danke für die Antwort.
        Zu meinem vorletzten Satz: "Möchte ich aber z.B. Daten austauschen mit dem RemotPI kann ich direkt bei FileZilla mich auf dem RemotPI einlogen" diese Aussage von mir stimmt nicht. Wenn ich den GatewayPI ausgeschaltet habe klappt eine direkt Verbindung nicht. Ich weiss nicht wie ich dazu kam das zu meinen. Tut mir leid das ich etwas falsches verbreitet habe aber es ist so das ich bei FileZilla nicht ohne das der GatewayPI eine Verbindung bekomme.
        Jetzt werde ich aber einmal Deine Antwort in Ruhe nachgehen und versuchen das zu verstehen.

        Gruß aus Dorsten
        Herbert

        Antworten

        1. Hallo Herbert,
          denk' dir nichts. Ich habe auch einige Zeit gebraucht, das zu verstehen. Dann ging es mir wie dem "tapferen Schneiderlein": Das war so stolz darauf, sieben Fliegen mit einem Streich erschlagen zu haben, dass er sich "7 auf einen Streich" auf das Wams stickte.
          Auf heutige Zeiten übertragen, war ich so stolz darauf den Reverse Tunnel endlich kapiert zu haben, dass ich mein Blog damit angefangen habe.

          Gruß aus Oberbayern.
          Chris

          Antworten

          1. Hallo Chris

            Leider muss ich nochmals um Hilfe bitten da ich das mit der WEBCAM einfach nicht hinbekomme.
            Meine Installation sieht z.Z. so aus.
            1. Seite
            Mein GatewayPI ist direkt mit der FRitzbox 7490 verbunden. Mit meinen Laptop bin ich über SSH und Filezilla mit diesem verbunden.
            2. Seite
            Mein RemotePI ist über ein Netzwerkkabel mit dem TP Link 3020 verbunden. An diesem Router ist der UMTS Stick angeschlossen.
            An dem RemotPI ist zudem ein USB HUB mit der WEBCAM.
            Bis hier habe ich ja Deine Anweisung abgearbeitet und es klapp ja auch prima mit der Verbindung. Ich kann von meinem Laptop über den GatewayPI zum RemotPI zugreifen und die Schaltungen am GPIO Port schalten. Auch meine erste HTML/PHP Seite habe ich in Angriff genommen. Diese Seite hat z.B. sechs Button um zwei Funkschalter alleine und zusammen EIN und AUS zuschalten. Dort ist auch das WEBCAM-Bild eingefügt welches aber nicht angezeigt wird.
            Da ich mich aber auch mit meinem Laptop mich über das Netz des TPLINK 3020(RemotePI) einwählen kann sehe ich dann das WEBCAM Bild. Melde ich mich wieder in das FritzBox7490(GatewayPI)Netz habe ich ein Bildrand ohne Bild in dem kein Bild steht. Ich lasse also im Browser die Selbe Adresse, drücke auf "Aktuelle Seite neu laden" und wechsel nur von GatewayPI Netz ins RemotePI Netz.

            Entschuldige, nachträglich wünsche ich allen noch ein gesundes erfolgreiches Jahr 2016

            Gruß Herbert

            Antworten

            1. Hallo Herbert,
              kein Problem... und keine Angst, das Thema scheint anfänglich etwas verworren, wenn mans dann aber kapiert hat, ist es eigentlich ganz einfach.
              Ich versuche das mal über eine Fallunterscheidung zu erklären, wobei für dich der zweite Fall am interessantesten sein dürfte.
              1. Im Netzwerk des Remote Pi TP Link Router möchte ich über einen im seben Netzwerk befindlichen Rechner auf den Webserver des remote Pi zugreifen.
              Remote Pi hat IP 192.168.0.50
              URL Eingabe in Browser auf Laptop http://192.168.0.50 ruft Website im Remote Pi auf. alles okay.

              2. Im Netzwerk des Gateway Pi möchte ich über einen im selben Netz befindlichen Laptop auf den Webserver bzw. eine dort liegende Website im Remote Pi zugreifen.
              Voraussetzung: Reverse Tunnel steht, Portadresse 80 (für http) des Remote Pi wird auf einen beliebigen Port (größer 1024 - hier z.B. 8000) des Gateway Pi getunnelt. Siehe auch Kapitel "Browsen im Tunnel" meines Beitrags. z.B. durch /usr/bin/autossh -fN -R 8000:localhost:80 pi@dieDyn.IP.adresseDesGatewayNetzwerks. Außerdem ist der Port 22 im Router freigeschaltet und auf den Gateway Pi geroutet.
              Gateway Pi hat IP Adresse 192.168.178.20
              URL Eingabe in Browser auf Laptop http://192.168.178.20:8000 ruft Website im Remote Pi auf. alles okay. Wichtig ist es hier die Portnummer für den http Tunnel anzugeben, nicht etwa die Portnummer für den SSH/Putty Kanal.

              3. von Unterwegs möchte ich über das "freie" Internet via Gateway Pi eine Website auf dem Remote Pi anzeigen.
              Voraussetzungen wie unter 2.
              Zusätzlich muss im Router noch die Portadresse 8000 freigeschaltet und auf den Gateway Pi umgerouted werden.
              URL Eingabe im Browser eines Smartphones: http://dieDyn.IP.adresseDesGatewayNetzwerks:8000 ruft Website im Remote Pi auf.

              Versuch anfänglich doch erst einmal eine ganz einfache "hello World" Seite auf dem Remote Pi zum Laufen zu bringen. Wenn das funktioniert, den nächsten Schritt mit php und Webcam gehen. Was auch hilft, ist (wenn du einen Firefox Browser hast) ein Plugin namens Firebug, mit dem du deine html und PHP Seiten debuggen kannst. So kannst du schnell erkennen, ob irgend ein Link o.ä. nicht richtig funktioniert.

              Wenn ich mir mal deinen Code von der html/php Seite auf dem Remote Pi ansehen soll, gib mir Bescheid ich teile dir dann eine Email Adresse mit, an die du das schicken kannst.
              Gruß
              Chris

              Antworten

  4. Hello Tunnelbauer,
    Super Anleitung, danke vielmals! nach ein bisschen rumpröbeln hab
    ichs geschafft einen Reverse-Tunnel mit einem usb-getethertem Iphone
    hinzubekommen, soweit super!
    jetzt ist aber das problem aufgetaucht, dass wenn sich der Remote-Pi
    aus dem Ausland anmeldet kein Tunnel zustande kommt. ich vermute
    dass die Ports beim ausländischen Telco-Provider gesperrt sind.....
    habe dann Versucht einen Tunnel auf Port 443 oder Port 80 (die müssten sicher
    durchgeleitet werden) aufzubauen, macht aber ne fehlermeldung
    sudo ssh -o StrictHostKeyChecking=no -o "ServerAliveInterval 300" -o UserKnownHostsFile=/dev/null -N -R 443:localhost:22 user@server
    Warning: remote port forwarding failed for listen port 443
    gibts eine Möglichkeit den Tunnel auf diese Ports zu legen?
    Keep up the good work!
    marcel

    Antworten

    1. Hallo Marcel,
      eigentlich sperren die Mobilfunk Provider wenn überhaupt nur VoIP Ports. In Italien nutze ich WIND (da geht sogar VoIP), aber auch TIM klappt wunderbar. Probier doch mal andere Portnummern. z.B. im Bereich 30000 bis 50000. Oder 8000, 8001, 8080 oder 8081 oder 8888. Von den standardisierten Ports von 0 bis 1024 würde ich die Finger lassen. Die darfst du eh nur als Superuser verwenden. Linux braucht eine ganze Reihe von denen für interne Funktionen und es kommt leicht zu Konflikten.
      Natürlich muss die verwendete Portnummer unbedingt in deinem Router freigeschaltet und auf den Gateway Pi geroutet sein (Port forwarding).
      Wenn du bei deinem Remote Pi im Ausland bist, kannst du das Setup auch ganz einfach testen: Dazu brauchst du einen Rechner, bzw. das Iphone mit dem du eine ssh Session (App dafür wird benötigt) zu deinem Gateway Pi zuhause aufmachst. Portadresse muss im Router auch noch zusätzlich durchgeroutet werden. Wenn du dich in deinen Gateway Pi eingewählt hast, kannst du so tun, als wärst du zu Hause. d.h. auf dem Pi eine SSH Tunnelsitzung mit dem gewählten Reverse Tunnel Port starten. Wenn alles klappt, kommst du auf dem Remote Pi raus.
      Generell ist das Iphone zu schade, um als permanent installierter Router beim Remote Pi zu dienen. Ein mobilfunkfähiger Router samt Internet Surfstick kostet nicht die Welt.
      Grüße und eine schöne Zeit

      Antworten

      1. Hi Rustimator,
        danke für Deine Ausführungen, hatte das ganze schon im betrieb, zuhause (schweizer gsm netz/lebara sim) gings wunderbar, und als das Ding in Italien war (gleiche sim, roaming eingeschaltet) wollts nicht. Das blöde ist halt dass ich nicht beim remote pi sein kann wenn er wieder unterwegs ist um ev. Netztwerksachen zu ändern.... (das Ganze ist im Rahmen eines Kunstprojektes manchmal unterwegs und leider sind Künstler meist nicht besonders Sysadmin-Affine 🙂 und muss darum DAU-Tauglich sein)
        Zum Iphone, musste ich nehmen, altes (4)Telephon vom Auftraggeber, war extrem nervend das usb-tethermässig zum laufen zu bringen (ich hätte ein billigen androiden genommen). Das Gute am Telephon, jeder kanns bedienen
        und am Hörerausgang hab ich Microcontroller der auf das richtige Klingelzeichen hört und dann ein Power-Cycle beim Remote-Pi macht. (falls sich das Teil mal hart aufhängt (könnte man natürlich mit einem Watchdog machen...)).

        Antworten

  5. Hallo Chris

    Auch ich habe es nach Deiner Anleitung versucht aufzubauen.
    Da ich ein Anfänger bin freue ich mich umso mehr das ich eine Verbindung herstellen konnte.
    Bei mir sieht es Hardwaremäßig so aus:
    Ausserhalb
    TP-Link 3020 mit UMTS, Stick daran ein Raspberry PI als RemotePI.
    Daran eine Relaiskarte und WEBCAM sowie ein Versuchsboard für Basteleien.

    Zuhause
    Fritzbox 7490
    RaspberryPi als GatewayPI
    Laptop mit WIN7 und LM17

    Über den Win7 Rechner und Putty habe ich jetzt zugriff zum GatewayPI.
    Bin ich auf diesem eingeloggt kann ich mich auf dem RemotePI einlogen und dort z.B meine Relaiskarte steuern.
    Nun hatte ich heute morgen LinuxMint17 gestartet und von dort mich über das Terminal zum GatewayPI verbunden. Von dort dann am RmotePI weiter.
    Jetzt meine Frage:
    Ist es möglich direkt von LinuxMint eine Verbindung zum RemotePI aufzubauen?
    In Deiner Anleitung erklärst Du:
    "Einen weiteren Raspberry Pi – oder einen (Linux) Rechner als Gateway, auf dem SSH läuft"
    SSH läuft ja sonst könnte ich mich ja nicht über das Terminal vom LM auf dem GatewayPI einloggen.
    Der Sinn ist ja einfach: Einen PI sparen und einen Linux Rechner habe ich ja.

    Danke und Gruß aus Dorsten
    Herbert

    Antworten

    1. Hallo! Freut mich, wenn meine Anleitung dir geholfen hat.
      In Anbetracht des supergünstigen Preises für den RaspberryPi (der brandneue RaspberryPi Zero kostet keine 15€ - bald bei Watterott). Braucht fast keinen Strom und behindert nicht das normale Arbeiten am PC. Außerdem kannst du ihn, da er dauernd laufen kann, auch als "von außen" erreichbares Gateway verwenden. Überlegs dir... :-). Wie ich geschrieben habe, kannst auf dem Gateway Pi auch noch WordPress oder Owncloud installieren oder sonst irgend welche Applikationen. Der Gateway Pi langweilt sich sonst nur. Mein Blog hier läuft unter WordPress auf meinem Gateway Pi (ein Raspberry Pi 2 mit externer SSHD Festplatte) völlig problemlos.
      Ich bin kein Linux Experte...Trotzdem müsste es gehen, einen PC mit Linux Mint (nennen wir ihn LM) zum Gateway umzufunktionieren. Ich habe zwar einem Uralt Laptop mit Mint zu einem zweiten Leben verholfen, nur steht der jetzt im Ferienhaus und ich kanns nicht ausprobieren.
      Als erstes würde ich checken, ob LM überhaupt von einem anderen Rechner aus ansprechbar ist oder ob da ggf. noch ein Firewall im LM Zugriffe von außen verhindert. Das müsste man einstellen. Ferner weiß ich nicht ob auf LM auch der SSH Server läuft, das wäre im LM Terminal z.B. über top herauszufinden. Wenn in der Liste sshd steht, dann ja.
      Dann LM als Gateway genau so konfigurieren, wie in der Anleitung beschrieben. Raspbian und Linux Mint sind sich sehr ähnlich, ich weiß aber nicht, ob sshd_config auch unter /etc zu finden ist.
      Dann gemäß Anleitung weitermachen aber in deiner Fritzbox für Port 22 Weiterleitung (bzw. den Port, den du für den Pi verwendest) die IP Adresse des LM verwenden. In der Fritzbox auch bei der Netzwerkkonfiguration für den LM den Haken bei "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen." machen.
      Das müsste dann funktionieren.
      Ich nehme an, du willst den LM immer nur anschalten, wenn du auch den Remote Pi zugreifen willst. So lange der LM ausgeschaltet ist, versucht der Remote Pi bzw. autossh immer wieder vergeblich eine Verbindung aufzubauen. Das gibt halt immer ein Paar Byte auf der Leitung. Ob es dadurch noch weitere Seiteneffekte gibt, kann ich nicht sagen.
      Ein zweiter Pi als Gateway wäre IMHO die bessere Lösung, wenn du über ein Bastelstadium hinausgehen willst.
      Grüße und viel Spaß
      Chris

      Antworten

      1. Hallo Chris

        Ich habe z.Z. Urlaub und mich in mein neu eingerichtetes Zimmer ehm. Kinderzimmer verschanzt. Dort steht jetzt alles aufgebaut rum.
        ...
        Somit kam der PI mir schon recht endlich etwas zu lernen was Spass macht.
        Das mit dem Preis ist nicht der Grund es auf dem Linux PC zu machen sonndern mehr als Lernspass und falls mal der GatewayPI keine Verbindung aufbaut einen zweiten Eingang zum PI. Da ich ja den RemotePI an einem TP3020 habe, bekomme ich von diesem Router z.Z. alle Stunde ein E-Mail das er noch Verbindung hat.
        Heute werde ich Versuchen das mit dem LM Rechner hinzubekommen.
        SDKarten habe ich genug und ich lege immer ein erweitertes Images des PI auf eine externe Platte so das ich immer zurückgreifen kann auf den letzten erfolgreichen Stand.

        Ich Danke Dir nochmals für die Zeilen und wünsche auch allen Lesern noch ein erfolgreichen Tag.

        Gruß aus Dorsten
        Herbert

        Antworten

  7. Vielen Dank, Super Beschreibung.

    Ich nutzte das an mein Kabel ipv6 Anschluss,
    um gleich mehrere reverse ipv4 Tunnel von mein V-Server zu mein interne PI auf zu bauen.
    Perfekt ! jetzt ist mein PI mit ipv4 (Handy, etc) wieder von außen erreichbar

    Danke für die Anleitung
    Gruß Michael

    Antworten

  8. Hallo,

    ist es möglich mit einem Befehl am RemotePI den ssh Tunnel wieder abzubauen.
    Da der Tunnel ja mit dem Kommando -fNC im Hintergrund gestartet wurde, kommt man nicht so einfach dran.

    Wie kann ich diesen Tunnel wieder beenden?

    Würde mich über einen Hinweis sehr freuen.
    Gruß
    Christian

    Antworten

    1. Hallo, spontan fällt mir dazu nur "killall " ein.

      D.h. mit killall autossh und anschließend mit killall ssh den Tunnel abwürgen. Wenn du das über den Tunnel machst - also nicht direkt am Remote Pi - dann unbedingt erst autossh und dann ssh beenden.
      Ich bin mir ehrlich gesagt nicht ganz sicher ob man autossh überhaupt killen muss. Käme auf einen Versuch an.
      Gruß Chris

      Antworten

        1. Ah, okay. Ich dachte, dass ein noch aktives autossh vielleicht den Tunnel neu aufbaut. Freut mich, wenn ich dir helfen konnte.
          Chris

          Antworten

  9. Hallo zusammen, ich kann auch deutsch, bin aus der Schweiz

    Hi there
    i have a Huawei E303 and a Raspi B+ board powered with a samsung 2 Amp usb adapter.
    Everything works like charm. After the pi is it is automatically connected to internet. I need it to to a time lapse of my house build.
    Nowadays i had troubles with my autossh connection. Well it is establishing after the reboot and this is fine. I can connect with ssh -p 9091 pi@localhost without any problem.

    But sometimes it hangs to connect i do not know why. It is probably reestablishing. But in the last 6 days it workes very good and today i had several that i couldn't connect to and had to wait for minutes to connect again...

    Even this morning when i want to connect to it it says:
    xxxxx@xxxxx-virtual-machine:~$ ssh -p 9091 pi@localhost
    ssh: connect to host localhost port 9091: Connection refused

    Somehow the autossh is not really reliable for me

    In messages i found the following:
    Can it be a power problem or what? Any clues?
    This is my sh script which will be executed after each reboot:

    #!/bin/bash
    sleep 20
    /usr/bin/autossh -fN -R 9091:localhost:22 -R 8080:localhost:80 username@host

    messages log:
    Jun 22 13:53:41 raspberrypi autossh[2715]: port down, restarting ssh
    Jun 22 13:53:41 raspberrypi autossh[2715]: starting ssh (count 8)
    Jun 22 13:53:41 raspberrypi autossh[2715]: ssh child pid is 6148
    Jun 22 13:57:44 raspberrypi kernel: [21436.669147] usb 1-1: USB disconnect, device number 32
    Jun 22 13:57:44 raspberrypi kernel: [21436.669171] usb 1-1.1: USB disconnect, device number 33
    Jun 22 13:57:44 raspberrypi kernel: [21436.669457] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet
    Jun 22 13:57:44 raspberrypi kernel: [21436.669540] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
    Jun 22 13:57:44 raspberrypi kernel: [21436.710226] usb 1-1.2: USB disconnect, device number 36
    Jun 22 13:57:44 raspberrypi kernel: [21436.710425] cdc_ether 1-1.2:1.0 eth1: unregister 'cdc_ether' usb-bcm2708_usb-1.2, CDC Ethernet Device
    Jun 22 13:57:44 raspberrypi kernel: [21436.820820] usb 1-1.3: USB disconnect, device number 34
    Jun 22 13:57:44 raspberrypi kernel: [21436.989091] Indeed it is in host mode hprt0 = 00001501
    Jun 22 13:57:45 raspberrypi kernel: [21437.319109] usb 1-1: new high-speed USB device number 37 using dwc_otg
    Jun 22 13:57:45 raspberrypi kernel: [21437.319375] Indeed it is in host mode hprt0 = 00001101
    Jun 22 13:57:45 raspberrypi kernel: [21437.719452] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
    Jun 22 13:57:45 raspberrypi kernel: [21437.719493] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    Jun 22 13:57:45 raspberrypi kernel: [21437.720736] hub 1-1:1.0: USB hub found
    Jun 22 13:57:45 raspberrypi kernel: [21437.720961] hub 1-1:1.0: 5 ports detected
    Jun 22 13:57:45 raspberrypi kernel: [21438.009132] usb 1-1.1: new high-speed USB device number 38 using dwc_otg
    Jun 22 13:57:45 raspberrypi kernel: [21438.109498] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
    Jun 22 13:57:45 raspberrypi kernel: [21438.109541] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    Jun 22 13:57:45 raspberrypi kernel: [21438.112813] smsc95xx v1.0.4
    Jun 22 13:57:45 raspberrypi kernel: [21438.181386] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:84:c5:7c
    Jun 22 13:57:46 raspberrypi kernel: [21438.259156] usb 1-1.3: new high-speed USB device number 39 using dwc_otg
    Jun 22 13:57:46 raspberrypi kernel: [21438.365310] usb 1-1.3: New USB device found, idVendor=0951, idProduct=1665
    Jun 22 13:57:46 raspberrypi kernel: [21438.365351] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    Jun 22 13:57:46 raspberrypi kernel: [21438.365374] usb 1-1.3: Product: DataTraveler 2.0
    Jun 22 13:57:46 raspberrypi kernel: [21438.365392] usb 1-1.3: Manufacturer: Kingston
    Jun 22 13:57:46 raspberrypi kernel: [21438.365410] usb 1-1.3: SerialNumber: 00241D8CE480BF20A930289C
    Jun 22 13:57:46 raspberrypi kernel: [21438.366655] usb-storage 1-1.3:1.0: USB Mass Storage device detected
    Jun 22 13:57:46 raspberrypi kernel: [21438.368030] scsi host21: usb-storage 1-1.3:1.0
    Jun 22 13:57:46 raspberrypi kernel: [21438.764632] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
    Jun 22 13:57:47 raspberrypi kernel: [21439.382114] scsi 21:0:0:0: Direct-Access Kingston DataTraveler 2
    Log gekürzt

    Antworten

    1. Hi,
      Könnte auch daran liegen, dass sich dein wlan dongle schlafen legt. Hast das edimax dongle? Goggle mal nach edimax raspberry standby...
      Testweise den pi mit dem router über kabel verbinden, sofern möglich.
      Wenns dann stabil läuft, wars genau das standby problem. Deine Log kopie hab ich etwas gekürzt. Gruß Rustimator

      Antworten

      1. thx, aber ich habe einen Huawei E303 Stick. Es hat schon mal 6 Tage am Stück funktioniert. Aber jetzt macht es echt probleme. Auch auf dem Server sehe ich:
        tgdabfa1@tgdabfa1-virtual-machine:~$ netstat -an | grep "LISTEN "
        tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN
        tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
        tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
        tcp6 0 0 :::22 :::* LISTEN
        tcp6 0 0 ::1:631 :::* LISTEN
        tgdabfa1@tgdabfa1-virtual-machine:~$ ps -ef | grep ssh
        root 1662 1 0 11:46 ? 00:00:00 sshd: tgdabfa1 [priv]
        tgdabfa1 1703 1662 0 11:46 ? 00:00:00 sshd: tgdabfa1@pts/6
        root 1816 1 0 11:57 ? 00:00:00 /usr/sbin/sshd -D
        tgdabfa1 1880 1704 0 12:01 pts/6 00:00:00 grep --color=auto ssh

        obwohl ich den tunnel so aufmache wie du:
        /usr/bin/autossh -p2000 -fNC -R 10011:localhost:22 pi@dyn.IP.adresse

        Antworten

          1. Hi,
            ich dachte das Huawei Teil wäre dein Router...

            Versuch mal folgendes:
            sudo nano /etc/network/interfaces
            Dort ans Ende schreiben: wireless-power off

            ggf hilft das ja. Ansonsten würde ich mir den Edimax Dongle EW-7811UN zulegen. Kostet keine 10€, zum Beispiel bei Amazon.
            dann wie in folgendem Artikel von RaspberryPi Spy vorgehen. Die Anleitung dort funktioniert für alle WiFi dongles mit Realtek RTL8192 Chipset. Vielleicht ist das auch in deinem Huawei Stick verbaut...
            Ich hatte mal ähnliche Probleme mit einem TP-Link Dongle, dass wahlfrei ein paar Stunden oder auch Tage lief um sich dann sang und klanglos zu verabschieden. Ich hab es dann gegen ein Edimax Teil getauscht.
            Gruß Chris

            Antworten

  10. Liebe Tunnelgemeinde !
    Ein "Newbie" dankt herzlich für die tolle Gebrauchsanweisung zum Aufbau eines Reverse-SSH-Tunnels. Funktioniert wunderbar, allerdings kommen nach dem ersten Erfolg meine neuen "Begehrlichkeiten" - ein SSH-Tunnel-Router:
    Was will ich: Ich möchte von Zu Hause aus über mein Netzwerk und dem angeschlossenen Gateway-Raspi (GPi) über den externen Remote-Raspi (RPi) mit 3G USB-Stick eine Beckhoff-SPS fernwarten: Folgende Topologie liegt vor:
    Laptop mit TwinCat im Heimnetzwerk - GPI - DSL-Router - RPi mit 3G-USB-Stick - Beckhoff SPS (CX8090).
    Den SSH-Tunnel habe ich mittels Port 2000 errichtet.
    Für TwinCAT (SPS-Verbindung) werden (angeblich) die Ports 48898(TCP), 48899(UDP) und 987(TCP) benötigt.
    Kann mir jemand mit dem atossh-Befehl beim Router (RPi) und dem ssh-Verbindungsaufbau am Gateway (GPi) helfen ?
    Muss die Gateway Adresse meines Laptops auf die des GPi gestellt werden ?
    Ich hab' schon einiges probiert, bisher ohne Erfolg.
    Danke im Vorhinein für Eure Tipps.

    Antworten

    1. Hallo Reinhold,
      erst einmal Danke für dein Lob. Freut mich, wenn meine Anleitung weiterhelfen konnte.
      Ich kenne mich mit SPS, TwinCat etc. nicht aus. Vielleicht kreist du die Lösung einmal wie folgt ein:
      Kommst du direkt mit dem Remote Pi auf die SPS drauf? Wenn ja, könntest du in einem ersten Schritt über das Reverse Tunnel auf den Remote Pi zugreifen und von dort aus (per Browser?) auf die SPS zugreifen.
      Der Remote Pi ist ein Endgerät. D.h. du kannst dich via Remote Tunnel drauf einloggen und dann Programme laufen lassen, Seiten von einem dort installierten Webserver abrufen oder per rdp auf dem Remote Pi einen Browser starten, der dann auf Komponenten innerhalb des Remote Netzwerks zugreift. Ich mache das, um z.B. auf den Router im Remote Netzwerk zuzugreifen.
      Es gibt sicher auch eine Möglichkeit ein "Doppel Tunnel" aufzubauen (PC-GatewayPi-RemotePi-SPS) wobei die Pis eigentlich nur dazu dienen, Protokolle durchzureichen. Das übersteigt aber meine Möglichkeiten.
      Vielleicht beschreibst du das, was du vorhast noch etwas genauer. Ggf. gibt es ja einen unter den täglich 60-100 oder so Besuchern auf meinem Blog, der weiß, wie man so etwas bewerkstelligt.
      Grüße
      Chris

      Antworten

      1. Hallo Chris !
        Danke für Deine schnelle Antwort und Deine Tipps.
        Also bei meiner Anforderung sollen die beiden Pis rein zum "durchtunneln" des Dienstes TwinCAT (es ist eine ADS-Kommunikation) sein.
        Am Desktop-PC zu Hause (IP 192.168.1.55, ADS 192.168.1.55.1.1) läuft TwinCAT.
        Die Verbindung sollte über den Gateway-Pi GPi (IP 192.168.1.81)
        per SSH-Reverse-Tunnel
        über den Heimrouter mit fester externer IP-Adresse zum entfernt liegenden
        Remote-Pi (interne IP 192.168.1.83) mit Internet-USB-Stick zur
        dort per Eth-Kabel angeschlossenen SPS (IP 192.168.1.58, ADS 192.168.1.58.1.1)
        gelangen.
        Es sind dafür nur 2 Ports zuständig:
        48898 TCP (für die Kommunikation)
        48899 UDP (für den ADS-Broadcastsearch).
        Wenn ich mich am Desktop-PC mittels Putty zum RPi anmelde, kann ich erfolgreich einen Ping an die SPS absetzen.
        Es wird wohl nur Deine 2. Möglichkeit des reinen Durchreichens der Protokolle funktionieren. Mir fehlt allerdings auch das Wissen und die Erfahrung für den Aufbau dieser Kommunikation.
        Ich denke, dass
        1. Auf der Seite des Gateways GPi (zu Hause) ich eventuell über Putty am Desktop-PC TwinCat dazu bwegen kann, die richtige (Broadcast-)Route zu beginnen.
        2. Auf der Remote-Seite glaube ich, dass ich den RPi zu einem Port-Forwarding zur SPS bewegen müsste, weiss aber nicht wie....
        Danke im Vorhinein für Eure wertvolle Zeit
        Reinhold

        Antworten

        1. Hallo Reinhold,
          ich kann dir momentan nur ein paar Tipps geben, wie du dein Problem lösen kannst.
          du brauchst in jedem Fall eine Tunnel Lösung, da du ja weder auf dem Gateway noch auf dem Remote Pi irgendwelche Eingaben machen kannst/willst.
          1. die von dir benötigten Portadressen solltest du gemäß Anleitung im Remote SSH Tunnel angeben.
          2. dann suche mal bei DuckDuckGo (oder meinetwegen bei Tante Google) nach dem Begriff "multitunnel ssh" oder auch "multi hop ssh"
          3. ich habe das hier gefunden, was recht schlüssig und nicht zu kompliziert klingt: http://blog.remibergsma.com/2013/05/28/creating-a-multi-hop-ssh-tunnel-by-chaining-ssh-commands-and-using-a-jump-host/

          Ich werde mal auf meiner Seite versuchen, über eine solche verkettete SSH Verbindung direkt auf den Webserver im Remote Router zuzugreifen. Das kann ich aber erst kommendes Wochenende ausprobieren, wenn mich die Familie lässt.
          Gruß
          Chris

          Antworten

Schreibe einen Kommentar

Ich freue mich über Lob und Kritik.
Falls du Probleme mit der hier vorgestellten Anleitung hast und nicht weiter kommst:
Bitte das Problem oder die Fehlermeldung(en) möglichst genau beschreiben, auch an welcher Stelle (z.B. in welchem Node oder Befehl) und unter welchen Umständen der Fehler auftritt.
Gerne kannst du mir auch ein Mail schreiben. Die Adresse findest du im Impressum.
Ich gebe mir viel Mühe, meinen Lesern weiterzuhelfen. Je konkreter du bist, desto einfacher und schneller kann ich versuchen zu helfen.
Deine E-Mail-Adresse wird nicht veröffentlicht.
 Erforderliche Felder sind mit * markiert