Einwahl per PPP (gprs). Wie von außen per SSH zugreifen?

henfri · April 18, 2011 at 8:43 PM

Moin,

ich hab eine Dockstar mit einem GPRS Modem ausgestattet. Die Einwahl klappt, und ping ins Netz geht auch.

Wenn ich jetzt aber von außen per ssh auf die Dockstar zugreifen möchte (die IP sagt ifconfig mir ja, oder?), dann klappt das nicht.

Ist das prinzipiell nicht möglich? Oder muss ich noch etwas an Firewall o.ä. Einstellungen ändern? Nen Router hab ich ja in diesem Setup nicht. So kann das ja nicht an einem nötigen Portforwarding liegen...

Gruß,
Hendrik

oberlon · April 18, 2011 at 9:08 PM

Bei vielen mobilen Internetzugängen wird ein privates Netzwerk aufgebaut und irgendwo NAT verwendet.
Von außen drauf zuzugreifen ist dann nicht möglich.
Schau mal was für eine IP du bekommen hast:

http://de.wikipedia.org/wiki/Private_I…#Adressbereiche

zusätzlich kannst du ja mal schauen mit welcher IP du im INet aufschlägst:

z.B: wget http://checkip.dyndns.com und in der runtergeladenen index.html steht die öffentliche IP drin. Ist aber nicht deine IP sondern der Gateway für viele mobile Nutzer.

jackfritt · April 18, 2011 at 10:41 PM

Kostet extra viereckig Geld bei z.b. T-mobile

henfri · April 18, 2011 at 11:50 PM

Quote from oberlon

Bei vielen mobilen Internetzugängen wird ein privates Netzwerk aufgebaut und irgendwo NAT verwendet.
Von außen drauf zuzugreifen ist dann nicht möglich.

Und wie kann ich das rausfinden?

Code

Schau mal was für eine IP du bekommen hast:

Class A (10.*)

Quote

http://checkip.dyndns.com und in der runtergeladenen index.html steht die öffentliche IP drin. Ist aber nicht deine IP sondern der Gateway für viele mobile Nutzer.

Kann ich erst morgen checken.
Aber mit der IP kann ich dann ja auch garnix anfangen, oder?

Also insgesamt kann ich das vergessen, ja?

Gibt es denn eine Alternative?

Mal ins unreine gesprochen:
Kann ich einfach den per GPRS angebundenen Rechner die SSH Verbindung aufbauen lassen (statt eben umgekehrt)? Das müsste doch auch ohne NAT etc gehen, oder? Hm... Aber dann kann ich ja von zuhause keine Kommandos an den Server schicken, sondern nur umgekehrt.. das bringt nix. Also müsste ich den per GPRS angebundenen Rechner ein VPN aufbauen lassen, oder?
Oh je.

Ganz schlimm aber sicher möglich wäre ja dies:
Eine mit public key verschlüsselte *.sh, die ausgeführt wird, sobald sie auf einem ftp.mein.server gefunden wird. Der output geht an ftp.mein.server/output.txt
Normal wird alle 15 min nach dieser *.sh gesucht. Wenn eine gefunden wurde, wird alle 30s nach der nächsten gesucht.

So würde es ja gehen. Gibt's das schon?

Gruß,
Hendrik

Saxman2k · April 19, 2011 at 9:21 AM

Quote from henfri

Class A (10.*)

Das ist ein privater IP-Bereich. Dein Provider nutzt also definitiv NAT. Direkt von "Außen" kannst Du also nix machen.

Bei der Gelegenheit würde ich aber doch noch über eine Firewall bzw. dringend über IPTables nachdenken!

Gruß,
Saxman2k

3PO · April 19, 2011 at 9:23 PM

Quote from henfri

Also insgesamt kann ich das vergessen, ja?

Ja, das bei GPRS und auch bei UMTS doppeltes NAT benutzt wird.
Es gibt zwar Lösungen, wo man eine statische IP für GPRS oder UMTS bekommen kann, diese sind aber für "normale" User so gut wie unbezahlbar.

sparkie · April 19, 2011 at 9:37 PM

"von aussen" per ssh zugreifen ist kein Problem wenn man die Moeglichkeit hat, sich von der Dockstar (A) auf einem vom Internet normal zugaenglichen Server (B) einzuloggen. Das sollte natuerlich am besten automatisiert erfolgen. Mit Mechanismen wie der -R Option der ssh kann man dann auf diese Weise ein Tunnel einrichten, das automatisch einen ssh Zugriff von B nach A forwarded. Und somit die Einschraenkung des direkten Zugriffs auf A umgeht.

eine andere Moeglichkeit waere VPN zu nutzen.

- sparkie

henfri · April 20, 2011 at 12:28 AM

Kann B auch ein Rechner bei mir zuhause sein? Die FritzBox z.B. Oder der Vdr?

sparkie · April 20, 2011 at 12:42 AM

Quote from henfri

Kann B auch ein Rechner bei mir zuhause sein? Die FritzBox z.B. Oder der Vdr?

ja klar. Alles was einen ssh login mit '-R [bind_address: ]port:host:hostport' Funktionalitaet unterstuetzt, funktioniert. Ob die Fritte das kann - keine Ahnung. Mit dem VDR geht es in jedem Fall. Der Firewall (falls vorhanden) auf B muss natuerlich entsprechend konfiguriert sein, damit er neue Verbindungen von aussen auf den getunnelten Port auch zulaesst.

- sparkie

henfri · April 29, 2011 at 6:16 PM

Hm, es klappt noch nicht.

Folgendes Szenario:
HomeServer ist per gprs angebunden.
VDR ist mein SSH-Server
Am Laptop sitze ich

Ich möchte vom HomeServer einen Tunnel mit VDR aufbauen.
Am HomeServer starte ich also:

Code

root@HomeServer:~# ssh -g -N -R 5022:127.0.0.1:22 root@mein.dyndns.org -v


OpenSSH_5.5p1 Debian-5+b1, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to mein.dyndns.org [92.196.123.345] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu6
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-5+b1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'mein.dyndns.org' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: Remote connections from LOCALHOST:5022 forwarded to local address 127.0.0.1:22
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: remote forward success for: listen 5022, connect 127.0.0.1:22
debug1: All remote forwarding requests processed

Display More

Das sieht doch erstmal gut aus.
Jetzt starte ich am Laptop putty und baue eine Verbindung mit vdr:5022 auf. Jetzt würde ich einen Login auf HomeServer erwarten.
Aber ich bekomme nur ein "connection refused".

Was mache ich falsch?

Gruß,
Hendrik

oberlon · April 29, 2011 at 6:59 PM

Aus der Manpage:

-R [bind_address:]port:host:hostport
[...]
By default, the listening socket on the server will be bound to the loopback interface only.

Probier mal den Tunnel mit
-R 0.0.0.0:5022:127.0.0.1:22
aufzubauen.
Vielleicht läuft es damit.

henfri · April 30, 2011 at 9:24 AM

Danke für deine Antwort.
Aber, leider funktioniert das auch nicht :-((

ABER:
Wenn ich vom VDR aus

Code

ssh 127.0.0.1 -p 5022

ausführe, bekomme ich die shell von HomeServer

Es scheint nur, als ließe der VDR keine Verbindungen von außen auf 5022 zu.
Das ist erstmal nich soo schlimm. Aber wie kann ich das beheben?

Davon abgesehen, scheint das ganze bisher nicht über die GPRS Verbindung gelaufen zu sein. Wenn ich nämlich vorher ifdown eth0 eingebe, funktioniert das ganze nimmer.

Da "Homeserver" eine Dockstar -also ohne Monitor- ist, hab ich so meine Probleme, das zu debuggen, wenn ich keine ssh-Verbindung hab.
Ich nutze zur Zeit dieses Skript:

Code

cat ppptest.sh
pon ppp_simyo_k750i
sleep 20
ifconfig
ifdown eth0
ssh -g -N -R 0.0.0.0:5022:127.0.0.1:22 root@mein.dyndns.org -v > sshlog.txt &
sleep 180
ifup eth0
poff ppp_simyo_k750i

leider bleibt die sshlog.txt leer -und zwar auch, wenn ich das an der Kommandozeile probiere. Wie kommt das?

Gruß,
Hendrik

henfri · April 30, 2011 at 11:42 PM

Hallo,

ich habe obiges Skript nochmal erweitert:

Code

cat ppptest.sh
pon ppp_simyo_k750i
sleep 60
echo -------ifconfig-----
ifconfig
echo -------ping via eth0-----
ping www.web.de -c3 -I eth0
echo -------ifdown------
ifdown eth0
echo -------ping via ppp0-----
ping www.web.de -c3 -I ppp0
echo ----------ssh------------
ssh -g -N -R 0.0.0.0:5022:127.0.0.1:22 root@mein.dyndns.org -v > sshlog.txt &
sleep 180
ifup eth0
poff ppp_simyo_k750i

Display More

Das Ergebnis:

Code

-------ifconfig-----
eth0      Link encap:Ethernet  HWaddr 00:10:75:1a:ca:99
...


ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.166.138.64  P-t-P:10.64.64.64  Mask:255.255.255.255
...


-------ping via eth0-----
PING www.web.de (213.165.64.75) from 192.168.178.2 eth0: 56(84) bytes of data.
64 bytes from web.de (213.165.64.75): icmp_req=1 ttl=55 time=32.8 ms
64 bytes from web.de (213.165.64.75): icmp_req=2 ttl=55 time=32.4 ms
64 bytes from web.de (213.165.64.75): icmp_req=3 ttl=55 time=31.9 ms


--- www.web.de ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 31.902/32.408/32.872/0.397 ms
PING julehen.dyndns.org (92.196.126.198) from 192.168.178.2 eth0: 56(84) bytes of data.
64 bytes from port-92-196-126-198.dynamic.qsc.de (92.196.126.198): icmp_req=1 ttl=63 time=0.423 ms
64 bytes from port-92-196-126-198.dynamic.qsc.de (92.196.126.198): icmp_req=2 ttl=63 time=0.341 ms
64 bytes from port-92-196-126-198.dynamic.qsc.de (92.196.126.198): icmp_req=3 ttl=63 time=0.343 ms


--- julehen.dyndns.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.341/0.369/0.423/0.038 ms
-------ifdown------
-------ping via ppp0-----
----------ssh------------

Display More

Man sieht also, dass nach dem ifdown eth0 kein ping mehr über ppp0 funktioniert.
Das ist doch total komisch, oder?
Zuvor hat der ping ja funktioniert, und zwar explizit über das Interface ppp0 (über den -I Parameter vom Ping).

Wie kann das kommen?

Gruß,
Hendrik

oberlon · May 1, 2011 at 10:38 AM

Lass dir mal das Routing vor und nach der Einwahl anzeigen

route -n

Vielleicht liegt die default route auf eth0 und der ppp ersetzt diese nicht.
Nach der Einwahl schau mal mit

netstat -ltnp

welche Daemons auf welchen Port lauschen.
Ggf. vor der Einwahl die default route löschen.

henfri · May 1, 2011 at 2:17 PM

Hallo,

so sieht's aus:

Code

-------route -n vor Einwahl -----
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eth0


-------route -n vor beenden von eth0 -----
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eth0


-------route -n nach beenden von eth0 -----
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0




-----netstat---------
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1073/mysqld
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      810/smbd
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      580/portmap
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      826/apache2
tcp        0      0 0.0.0.0:4949            0.0.0.0:*               LISTEN      1324/munin-node
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      17213/sshd
tcp        0      0 0.0.0.0:3483            0.0.0.0:*               LISTEN      1320/perl
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      826/apache2
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      810/smbd
tcp        0      0 0.0.0.0:56509           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:57921           0.0.0.0:*               LISTEN      1320/perl
tcp        0      0 0.0.0.0:2049            0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:9090            0.0.0.0:*               LISTEN      1320/perl
tcp        0      0 0.0.0.0:56647           0.0.0.0:*               LISTEN      802/rpc.mountd
tcp        0      0 0.0.0.0:53319           0.0.0.0:*               LISTEN      609/rpc.statd
tcp        0      0 0.0.0.0:9000            0.0.0.0:*               LISTEN      1320/perl

Display More

SSH sagt auch "ssh: Could not resolve hostname julehen.dyndns.org: Name or service not known"

Mit den Ausgaben von Route kann ich nix anfangen

Gruß,
Hendrik

oberlon · May 1, 2011 at 2:50 PM

Lösche mal die default route bevor du dich einwählst.

route del default

Danach müsste bei route -n nur noch eine zeile erscheinen. Bevor du den default gateway rausnimmst sei dir bitte sicher das du dich mit deinem Client Rechner im gleichen Netzwerk(192.168.178.0/24) befindest. Ansonsten ist deine Verbindung weg:)
Danach wähle dich per gprs ein und schaue ob er eine neue default Route eingetragen hat. Es müssten bei route -n jetzt drei einträge vorhanden sein:
So ähnlich:

10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 10.x.x.x 0.0.0.0 UG 0 0 0 ppp0

Danach müssten deine eingehenden und ausgehenden Verbindungen, die nicht nach 192.168.178.x gehen alle über ppp0 rausgehen.

Habe mich vorhin falsch ausgedrückt. Nachdem der ssh tunnel oben ist, schaue mal auf den Server, der dann auf Port 5022 lauschen soll (netstat -ltnp) nach, ob der Port offen ist und auf welcher IP er lauscht.

edit:
das löschen der default route war falsch und wurde oben geändert
setzten der default route nach der einwahl:
route add default dev ppp0
Bitte nur einen default route verwenden.

henfri · May 1, 2011 at 7:17 PM

Wunderbar, das funktioniert!! Herzlichen Dank für deine Hilfe!

Kann mir jemand sagen, wie lange der Tunnel jetzt funktionieren wird?

oberlon · May 1, 2011 at 7:56 PM

Bei ssh gibt es eine Option TCPKeepAlive die du setzten solltest wenn der Tunnel länger offen bleiben sollte. Mehr dazu steht in der Manpage.
Ich würde dir aber raten mal einen Blick auf OpenVPN zu werfen. Gibt es für die Fritzbox (freetz) und bestimmt auch für die Dockstar. Die Konfiguration ist nicht kompliziert und du könntest die Dockstar in dein Netz integrieren (voller Zugriff auf alle Ports). Vorallem wird nach einem Disconnect usw. die Verbindung automatisch wieder aufgebaut.
In deinem Fall, mit nur zwei "Clients", müsstest du noch nicht mal Zertifikate erstellen und könntest es über einen PSK machen.

Habe das bei mir (mit PKI) schon ein paar Jahre laufen und bin voll zufrieden.

HFlor · May 8, 2011 at 3:33 PM

Quote from sparkie

Mit Mechanismen wie der -R Option der ssh

Kann mir einer mal erklären, was ich falsch mache:

- Mein VDR ist z.Z. per UMTS ans Internet angebunden
- der VDR startet ssh mit der -R Option zu einem Rechner hinter einer Firewall (ssh-Port wird weitergeleitet)
- eine weitere Port-Weiterleitung der Firewall zu dem Remote-Port des ssh-Tunnels ist eingerichtet, ich bekomme aber keine Verbindung von außen.
- die Tunnel funktioniert, wenn ich es direkt auf dem Rechner der ssh-Verbindung versuche

Mit und ohne '-g' bei ssh wird auf dem Ziel-Rechner immer nur die netstat-Zeile:

Code

tcp        0      0 127.0.0.1:18008         0.0.0.0:*               LISTEN      29817/sshd: sshvdr

angezeigt.

die -R Option habe ich schon mit:
-R 18008:192.168.72.99:8008
-R 192.168.61.1:18008:192.168.72.99:8008
-R *:18008:192.168.72.99:8008

versucht.

Hardy

oberlon · May 8, 2011 at 7:11 PM

Um das nochmal nachzuvollziehen.
Du hast:

VDR inkl. UMTS (Intern 192.168.72.99 ?)
Rechner im LAN inkl. ssh server (192.168.61.x ?)
Firewall inkl. DSL mit 2x Portforwarding für (Intern 192.168.61.1?)
- Port x1 vom VDR zum Rechner
- Port x2 von FW auf Rechner zum VDR zu kommen
?

Einwahl per PPP (gprs). Wie von außen per SSH zugreifen?

Participate now!

Users Viewing This Thread