DerSucker
Anmeldungsdatum: 2. Mai 2016
Beiträge: Zähle...
|
Moin Moin, da ich die Dinge ausprobiert habe, die ich über Google gefunden habe und es nicht funtioniert hat, kommt hier mein Verzweiflungsversuch...vlt kann mir ja jemand helfen. Mein Szenario sieht wie folgt aus:
1. Raspberry Pi (raspbian) zu hause im LAN
2. vServer WAN
3. Windows-Client irgendwo auf der Welt Mein Pi macht einen SSH-Tunnel zum vServer im WAN auf und öffnet dort einen Port (10080) der auf den Pi (Port 80) zeigt.
Das klappt soweit auch. Ich habe auf meinem vServer also lokal den Port 10080 und wenn ich mich dorthin connecte lande ich auf dem apache auf dem Pi.
Diese Port ist leider nur lokal vom vServer aus erreichbar. Ich muss jetzt z.B. auf meinem Windows-Client Putty starten und dann einen SSH Tunnel aufbauen wenn ich direkt vom Client auf den Pi will.
Diesen Schritt über Putty würde ich gerne umgehen und den Port auf dem vServer auch remote verfügbar machen. Jetzt habe ich probiert das mit netcat zu lösen.
Hat auch geklappt, bekomme die Webseite angezeigt, aber netcat schließt sich nach ca 5sek wieder und der Port ist zu (nc.traditional -k -l -p 8888 -c "nc 127.0.0.1 10080 " -vvv). Dann dachte ich mir, dass dies doch auch mit iptables gehen muss. Aber alles was ich im Netz finde, hat irgendwie nicht geklappt. Also nochmal:
Windows → vServer:8888 → vServer:10080 (bzw. 127.0.0.1:10080) → Pi:80 Jemand eine Idee:
- Warum Netcat sich nach 5sek schließt?
- Wie ich das mit iptables mache?
- ob es eine andere Lösung gibt? Oder gibt es bei dem SSH Befehl den ich auf dem Pi ausführe noch einen Parameter, dass der Port auf dem vServer auch Remote verfügbar ist?
Falls sich jemand Fragt warum ich das so kompliziert mache: Bin bei Unitymedia mit IPv6 und kann auf meinem Router kein NAT machen.
Wollte über den Pi mein Netzwerk zu Hause von außen erreichbar machen (was ja auch über Umwege klappt) (Komme eigentlich aus der Windows bzw. Citrix Welt und bin nicht 100% fit unter Linux) Gruß
DerSucker
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
DerSucker schrieb: Dann dachte ich mir, dass dies doch auch mit iptables gehen muss. Aber alles was ich im Netz finde, hat irgendwie nicht geklappt.
Hier stehts beschrieben. Wenn es nicht wie gewünscht funktioniert, bräuchten wie mehr Infos, was genau nicht funktioniert.
- ob es eine andere Lösung gibt?
Dein Provider bietet IPv6. Wäre es eine Idee den PI IPv6-only zu betreiben? An vielen Stellen sollte das schon kein großes Problem mehr darstellen. Man könnte auch den vServer als Proxy dazwischen schalten. Der wäre dann per IPv4 und IPv6 erreichbar und würde den PI per IPv6 ansprechen. Dann musst du keine Tunnel bauen (ist immer mit Performanceeinbußen für Verschlüsselung verbunden). Noch eine Alternative wäre ein VPN. Dazu muss jedes teilnehmende Gerät dafür konfiguriert werden, was aber kein Problem sein sollte. Windows und Linux können das, genau wie die meisten Smartphones.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
DerSucker schrieb: Jetzt habe ich probiert das mit netcat zu lösen.
Hat auch geklappt, bekomme die Webseite angezeigt, aber netcat schließt sich nach ca 5sek wieder und der Port ist zu (nc.traditional -k -l -p 8888 -c "nc 127.0.0.1 10080 " -vvv).
Versuch mal mit:
nc.traditional -k -l -p 8888 -c "while true; do nc 127.0.0.1 10080; done" -vvv
|
DerSucker
(Themenstarter)
Anmeldungsdatum: 2. Mai 2016
Beiträge: 9
|
Morgen, erstmal vielen Dank für die Antworten! @Misterunknown:
Die Anleitung die du gepostet hast, habe ich schon vorher erfolglos getestet. So sieht mein Script aus:
1
2
3
4
5
6
7
8
9
10
11
12
13 | #!/bin/bash
IPT=/sbin/iptables
IF_DSL=venet0:0
IP_USER_1=127.0.0.1
PORT_IN=8888
PORT_OUT=10080
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
$IPT -A FORWARD -j ACCEPT -p udp --dport $PORT_IN --sport 1024:65535 -d $IP_USER_1 -m state --state NEW
$IPT -A FORWARD -j ACCEPT -p tcp --dport $PORT_IN --sport 1024:65535 -d $IP_USER_1 -m state --state NEW
$IPT -t nat -A PREROUTING -i $IF_DSL -p udp --dport $PORT_IN -j DNAT --to-destination ${IP_USER_1}:${PORT_OUT}
$IPT -t nat -A PREROUTING -i $IF_DSL -p tcp --dport $PORT_IN -j DNAT --to-destination ${IP_USER_1}:${PORT_OUT}
|
Wenn ich danach ein nmap auf den Port 8888 mache, ist der closed.
Oder hab ich da was versaubeutelt? Zu IPv6:
Unitymedia will generell nicht, dass NAT gemacht wird, weil dann die Leute zu Hause Server betreiben, die wiederrum das Netz auslasten.
Also liefern die keine Router aus, die NAT können.So hat mir das zumindest das wenig kompetente Personal von Unitymedia an der Hotline gesagt. Zu VPN:
Mein Ziel ist es, dass Freunde und Familie auf meine Server zugreifen können. Da wissen viele einfach nicht wie man einen VPN-Client installiert oder denen wird es gleich zu viel wenn die das hören.
Ich will ein einfaches Webinterface bauen mit den Buttons "Port öffnen" und "Port schließen" (Die Ports müssen ja nicht rund um die Uhr offen sein)...Damit kommen die Leute klar. @lubux
TOP ! Das Läuft ! Zumindest mit HTTP...wenn ich eine FTP Connection versuche, dann klappts leider nicht.
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | root@vServer:/home/username# ftp localhost 8888
ftp: connect to address ::1: Connection refused
Trying 127.0.0.1...
ftp: connect: Connection refused
ftp> exit
root@vServer:/home/username# ftp localhost 10021
Connected to localhost.
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-You are user number 2 of 50 allowed.
220-Local time is now 08:25. Server port: 21.
220-This is a private system - No anonymous login
220 You will be disconnected after 15 minutes of inactivity.
Name (localhost:username):
|
Kriegt man das noch hin?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
DerSucker schrieb: Wollte über den Pi mein Netzwerk zu Hause von außen erreichbar machen (was ja auch über Umwege klappt)
Du könntest auch einen VPN-Tunnel zwischen deinem vServer und deinem PI herstellen, und so den PI bzw. dein Heimnetz von außen erreichbar machen. Ein VPN-Client ist auf den Geräten im Internet, dann nicht erforderlich. BTW: M. E. müssen für ftp, mehrere/zusätzliche Ports offen sein bzw. zur Verfügung stehen. EDIT: DerSucker schrieb: Unitymedia will generell nicht, dass NAT gemacht wird, weil dann die Leute zu Hause Server betreiben, die wiederrum das Netz auslasten.
Also liefern die keine Router aus, die NAT können.So hat mir das zumindest das wenig kompetente Personal von Unitymedia an der Hotline gesagt.
BTW: Es sind nicht die Server die das Netz auslasten (überfordern). Das Problem ist die Segmentauslastung (... in bestimmten Gegenden, wo diese auch noch unterdimensioniert sind), abends und am Wochenende, wenn die UM-Kunden über das Internet fernsehen (und gleichwertig).
|
DerSucker
(Themenstarter)
Anmeldungsdatum: 2. Mai 2016
Beiträge: 9
|
Wenn ich einen VPN-Tunnel zwischen Pi und vServer aufmache, dann komme ich vom vServer vlt auf die Dienste die auf dem Pi oder auf anderen Geräten laufen...keine Frage.
Trotzdem habe ich dann das Problem, dass PersonX irgendwo auf der Welt von seinem Windowsclient (ohne VPN) nicht in mein Netzwerk kommt. Dazu müsste ich dann wieder auf meinem vServer Ports öffnen die dann z.B. auf 192.168.0.20:21 (LAN) zeigen. Dadurch habe ich also genau das gleiche Problem wie mit meinen SSH-Tunneln jetzt.
Oder habe ich da jetzt einen Gedankenfehler? Zu FTP:
Ja, es wird noch Port 20 benötigt. Trotzdem klappt es mit dem vorhandenen SSH-Tunnel der nur auf Port 21 zeigt. Kann mich über Kommandozeile anmelden. Erklären kann ich das gerade auch nicht. Vlt nochmal zu Iptables:
Wenn ich die Regeln so wie in meinem geposteten Script eintrage und dann ein nmap auf den Port 8888 mache, dann ist der Status "closed"...sollte der nicht "open" oder "forwarded" sein?
Mit einem geschlossenem Port kann man sich halt nicht verbinden.
|
DerSucker
(Themenstarter)
Anmeldungsdatum: 2. Mai 2016
Beiträge: 9
|
Ich habe noch mal gegoogelt.
Bei FTP im active mode wird Port 20 benötigt. Im Passive Mode Ports über 1024. Dies nur zur Datenübertragung.
Daher hat auch nur die Anmeldung funktioniert, aber Datenübertragung geht nicht
Dann muss ich zum Filetransfer halt SCP nehmen...geht ja auch. Wäre aber schön wenn noch jemand eine Idee zu Iptables hätte ☺
Zur not muss ich dann netcat nehmen
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
DerSucker schrieb: Wenn ich die Regeln so wie in meinem geposteten Script eintrage und dann ein nmap auf den Port 8888 mache, dann ist der Status "closed"...sollte der nicht "open" oder "forwarded" sein?
nmap ist nicht ausschlaggebend. Versuche dich mit telnet zu verbinden, dann weißt du, obs funktioniert oder nicht. nmap kann nicht immer den korrekten Status eines Ports wiedergeben.
|
DerSucker
(Themenstarter)
Anmeldungsdatum: 2. Mai 2016
Beiträge: 9
|
Die Verbindung geht nicht.
Wenn bis morgen Keiner eine Lösung für iptables hat, schließe ich den Thread trotzdem mal als gelöst, da ich mit netcat eine Lösung habe die funktioniert.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
DerSucker schrieb: Dadurch habe ich also genau das gleiche Problem wie mit meinen SSH-Tunneln jetzt.
Oder habe ich da jetzt einen Gedankenfehler?
Nein, diese "Probleme" hast Du nicht, denn auf dem vServer hast Du mit VPN, schon eine definierte Route in das LAN deines PI (mit dem tun-device des vServers als gateway). Was Du auf dem vServer dann noch brauchst, sind DNAT-iptables-Regeln.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
DerSucker schrieb: Die Verbindung geht nicht.
Wenn bis morgen Keiner eine Lösung für iptables hat, schließe ich den Thread trotzdem mal als gelöst, da ich mit netcat eine Lösung habe die funktioniert.
Ich habs mal nachgebaut. Der Teufel steckt wie immer im Detail:
| sysctl -w net.ipv4.conf.all.route_localnet=1
iptables -t nat -I PREROUTING -p tcp --dport 80 -j DNAT --to 127.0.0.1:8080
|
Edit: Ich habe mal die Anleitung um NAT und den Hinweis auf lo-Routing erweitert.
|
DerSucker
(Themenstarter)
Anmeldungsdatum: 2. Mai 2016
Beiträge: 9
|
TOP !
So funktioniert es ! Vielen Dank 👍 und nmap zeigt trotzdem, dass der Port "closed" ist...das wollte ich vorher nicht glauben ☺
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
DerSucker schrieb: und nmap zeigt trotzdem, dass der Port "closed" ist...das wollte ich vorher nicht glauben ☺
Versuch mal einen TCP-Ping mit nping:
sudo nping -c 3 --tcp --flags syn --delay 1s -g 5678 -p <Port> <IP-Adresse>
Au dem PI kannst Du vor dem nping, tcpdump starten:
sudo tcpdump -c 20 -vvveni <Interface> tcp port <lauschender-Port> EDIT: BTW: <lauschender-Port> muss nicht identisch sein mit <Port>.
|
qwerpoiz
Anmeldungsdatum: 22. Juli 2016
Beiträge: Zähle...
|
Mein Pi macht einen SSH-Tunnel zum vServer im WAN auf und öffnet dort einen Port (10080) der auf den Pi (Port 80) zeigt. Das klappt soweit auch. Ich habe auf meinem vServer also lokal den Port 10080 und wenn ich mich dorthin connecte lande ich auf dem apache auf dem Pi. Diese Port ist leider nur lokal vom vServer aus erreichbar.
Laut Dokumentation (http://www.debianadmin.com/howto-use-ssh-local-and-remote-port-forwarding.html) lässt sich die Portfreigabe vom lokalen Rechner auf das gesamte Subnetz durch setzen der folgenden Option in /etc/ssh/sshd_conf erweitern: GatewayPorts yes Zumindest bei mir war danach folgendes Schema möglich:
Windows → vServer:10080 → Pi:80
|