Posts by webster

    SSH und HTTPS kann man prinzipiell auf einem Port zur selben Zeit laufen lassen, da SSH ein "Server-sends-first"-Protokoll, und HTTPS ein "Client-sends-first"-Protokoll ist. An dem Port muss ein Programm lauschen, welches anhand des Client-Verhaltens in den ersten X Millisekunden (kommt da was oder nicht?) entscheidet, ob es sich um SSH oder HTTPS Daten handelt. Die Pakete werden dann an den echten lokalen Port vom sshd bzw. httpd umgeleitet.

    Es gibt mindestens zwei solcher Multiplexer:
    - sslh gibt es bereits als Debian/Raspbian Paket.
    - sshttp gibt es nur zum selbst kompilieren, hat aber den Vorteil, dass die Quell-IP der umgebogenen IP-Pakete nicht verlorengeht.

    Code
    PING 178.26.xxx(178.26.xxx) 56(84) bytes of data.
    64 bytes from 178.26.xxx: icmp_seq=1 ttl=63 time=3.78 ms

    Öhm, moment mal. Ich glaube, Du sabotierst mich und Dich selbst. Du hast nie und nimmer eine Latenz von 3 Millisekunden über 3G und eine Hop-Distanz von 1!
    Die Pings sind doch garantiert über WLAN gegangen, aber die Routing-Tabelle passt dazu überhaupt nicht:

    Code
    Kernel IP routing table
     Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
     0.0.0.0         10.64.64.64     0.0.0.0         UG    0      0        0 ppp0
     10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
     192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0


    Hast Du hier aus zwei unterschiedlichen Szenarien gecopypasted??

    Quote from druckgott pid=11133 dateline=1366403349


    Ping vom Pi auf Externe IP:

    Code
    ping 178.26.x.xx
    PING 178.26.x.xx (178.26.x.xx) 56(84) bytes of data.
    64 bytes from 178.26.x.xx: icmp_req=1 ttl=63 time=4.26 ms
    64 bytes from 178.26.x.xx: icmp_req=2 ttl=63 time=10.2 ms
    64 bytes from 178.26.x.xx: icmp_req=3 ttl=63 time=9.91 ms


    SSH von PI auf externe IP: (dauert erst mal ewig)

    Code
    ssh 178.26.x.xx
    ssh: connect to host 178.26.x.xx port 22: Network is unreachable

    Kannst Du das "network unreachable" reproduzieren während gleichzeitig pings durchkommen? Wenn ja, dann ist das eine Firewall-Geschichte. Hat die Fritzbox eine eingebaut? Dass KD Port 22 sperrt, glaube ich nicht. Du könntest ja mal versuchshalber einen anderen Port als 22 durchleiten. Z.b. die bereits bekannte 2222 auf ubuntu:22.
    Vom Pi führst Du danach

    Code
    ssh -R 2222:localhost:22 178.26.x.xx -p 2222


    aus.

    Ich hatte eigentlich gehofft die Ausgabe zu sehen während der Surfstick aktiv ist. Aber egal, ich frage mal anders. Was ist die Meldung auf dem Pi wenn Du "ssh externefritzboxIP" eingibst? Was ist mit ping statt ssh?

    Und was meinst Du mit "schon gar nicht"? Das ist doch jetzt das Ziel.

    Im Prinzip wäre es das. Regeln SSH2-SSH4 brauchst Du nicht.

    Lass mal bitte die Ausgabe von "ifconfig", "route -n" auf dem Pi sehen, sicherheitshalber auch noch "iptables -L -n" auf Ubuntu. Es könnten auch Firewallregeln auf der Fritzbox sein.
    Ich frag nochmal um sicherzugehen: Du nimmst die externe IP der Fritzbox, also das, was Dir http://www.wieistmeineip.de bei Aufruf über Ubuntu sagt, richtig?

    Code
    ssh -R 2222:localhost:22 meineaktuelleexterneip

    Den Befehl setzt Du auf dem Pi ab (später automatisch). Über die externe IP muss ein SSH Server erreichbar sein. Willst Du, dass der SSH-Server auf Ubuntu angesprochen wird, und nicht der SSH Server auf der Fritzbox (falls dort einer läuft), dann musst Du in der Fritzbox ein NAT für TCP Port 22 auf die interne Ubuntu-IP einrichten. Die rote 22 ist übrigens nur zufällig gleich mit der 22 aus dem ssh -R Aufruf. Falls Du über den obigen Aufruf keine Verbindung aufbauen kannst, dann stimmt das Fritzbox-NATing noch nicht, oder der SSH-Server auf Ubuntu läuft noch nicht.

    Auf dem Pi muss auf localhost:22 ebenfalls ein SSH-Server lauschen. Das ist diesmal genau die Angabe aus dem ssh -R Aufruf. Ein "netstat -ltn | grep :22" sollte Dir ein "0.0.0.0:22" in der dritten Spalte ausgeben, dann ist das ok. Hast Du also den ssh -R Aufruf auf dem Pi erfolgreich durchgeführt, sollte auf Ubuntu ein Aufruf von "ssh localhost -p 2222" im Pi münden.

    Es ist unerheblich, ob VPN oder SSH. Der Verbindungsaufbau muss zu einem System gehen, das eine öffentliche IP-Adresse hat und welches Du kontrollierst. Ein VPN/SSH Server (für den Tunnel) auf dem Pi über 3G fällt daher flach, da 3G-Provider NATen.

    Der Pi auf dem Flugplatz muss die Verbindung aufbauen, z.B. in Richtung Deiner Fritzbox, und z.B. wie in Deinem autossh-Bloglink. DynDNS-Client muss auf der Fritzbox laufen, damit der Flugplatz-Pi stets weiss, wohin er verbinden soll. Der Pi selbst braucht kein DynDNS.

    Hast Du vi oder vim schonmal bedient? Das ist für Neulinge nicht ohne. Ich persönlich komme mit dem abgespeckten vim.tiny überhaupt nicht klar, sondern nutze den richtigen vim.

    Code
    sudo apt-get install vim
    sudo rm /etc/network/.interfaces.swp
    sudo vim /etc/network/interfaces

    Innerhalb von vim die Taste i drücken, dann steht in der Ecke "Einfügen". Jetzt kannst Du nach belieben Text editieren.
    Wenn du fertig bist, ESC, :x (Doppelpunkt x), Enter

    Alternativ kannst Du mal nano installieren, ist für Anfänger intuitiver.