Mobilfunkstrecken und Zugriff auf beliebige Ports
Hallo allerseits,
über 30 aufeinanderfolgende "Non-Standard-Ports" sollen ca. 30 Kleingeräte (Raspi, IP-Kameras, Temp.-Sensoren, Schaltrelais) von aussen per Port-Weiterleitung adressiert werden, wobei das jeweilige Ziel der HTTP-Port 80 des Kleingeräts mit einer individuellen IP-Adresse ist.
Das funktioniert soweit problemlos, wenn die jeweilige IP-Strecke die Ports 1:1 durchlässt, was im DSL wohl meist auch der Fall ist.
Nun wurde die gleiche Aktion über eine Mobilfunk-Einwahl ins Internet getetest. Damit werden offenbar nur die Standard-Ports zugelassen und unbekannte Ports blockiert.
Gibt es eine Möglichkeit, trotz Datenverbindung über 3G/4G vom Smartphone aus auf beliebige Zielports zuzugreifen?
MfG
mannid
über 30 aufeinanderfolgende "Non-Standard-Ports" sollen ca. 30 Kleingeräte (Raspi, IP-Kameras, Temp.-Sensoren, Schaltrelais) von aussen per Port-Weiterleitung adressiert werden, wobei das jeweilige Ziel der HTTP-Port 80 des Kleingeräts mit einer individuellen IP-Adresse ist.
Das funktioniert soweit problemlos, wenn die jeweilige IP-Strecke die Ports 1:1 durchlässt, was im DSL wohl meist auch der Fall ist.
Nun wurde die gleiche Aktion über eine Mobilfunk-Einwahl ins Internet getetest. Damit werden offenbar nur die Standard-Ports zugelassen und unbekannte Ports blockiert.
Gibt es eine Möglichkeit, trotz Datenverbindung über 3G/4G vom Smartphone aus auf beliebige Zielports zuzugreifen?
MfG
mannid
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2265118631
Url: https://administrator.de/contentid/2265118631
Ausgedruckt am: 24.11.2024 um 15:11 Uhr
17 Kommentare
Neuester Kommentar
Zitat von @mannid:
.
Gibt es eine Möglichkeit, trotz Datenverbindung über 3G/4G vom Smartphone aus auf beliebige Zielports zuzugreifen?
.
Gibt es eine Möglichkeit, trotz Datenverbindung über 3G/4G vom Smartphone aus auf beliebige Zielports zuzugreifen?
Mach dir den Aufwand erst gar nicht : Ihr spielt eh schon russisch Roulette, auf unverschlüsselte HTP:80 durchzuleiten...
.lDie Verwendung von "Non-Standard-Ports" extern ist sowas von NULL-Schutz!!
Wie Epixc0re schon schreibt, VPN!
Immer und überall, wo es auch nur geht, VPN!
Klar verlierst du damit die Möglichkeit dich von jedem beliebigen Gerät Mal eben so einzuwählen ( bsp. Internetcafe (gibt's die eigentlich noch?) oder wenn beim Kumpel zu Besuch ), aber du hast die Gewissheit, dass du genau weißt, welche Geräte sich einwählen dürfen.
Immer und überall, wo es auch nur geht, VPN!
Klar verlierst du damit die Möglichkeit dich von jedem beliebigen Gerät Mal eben so einzuwählen ( bsp. Internetcafe (gibt's die eigentlich noch?) oder wenn beim Kumpel zu Besuch ), aber du hast die Gewissheit, dass du genau weißt, welche Geräte sich einwählen dürfen.
Moin...
ja..mit dem richtigen tarif schon!
ich löse sowas mit mdex
Frank
Nun wurde die gleiche Aktion über eine Mobilfunk-Einwahl ins Internet getetest. Damit werden offenbar nur die Standard-Ports zugelassen und unbekannte Ports blockiert.
nee nee... das liegt am Carrier Grade NAT (CGN) was die Betreiber in den Netzen haben...Gibt es eine Möglichkeit, trotz Datenverbindung über 3G/4G vom Smartphone aus auf beliebige Zielports zuzugreifen?
ja..mit dem richtigen tarif schon!
ich löse sowas mit mdex
Frank
das liegt am Carrier Grade NAT (CGN) was die Betreiber in den Netzen haben...
Wenn der TO nur einmal etwas nachgedacht hätte und sich die im Mobilfunknetz vergebene IP Adresse angesehen hätte wäre diese Frage überflüssig gewesen.Fast alle Provider machen CGNAT im Mobilnetz. Ganz besonders die Billigheimer.
Wenn du dort also RFC 1918 oder RFC 6598 IP Adressen hast hast du ein CGNAT Mobilnetz.
Zumindestens für IPv4 ist damit dann Port Forwarding technisch unmöglich.
Mit IPv6 klappt es aber fehlerlos !
Fazit: IPv6 nutzen !
Sowas mit dummem und ungeschütztem Port Forwarding zu lösen machen heute ja nicht mal mehr Noobs. Damit exponiert man diese Geräte völlig ungeschützt im Internet.
Wie oben schon gesagt ist VPN das Mittel der Wahl. Damit entfällt dann auch die Frickelei mit Port Forwarding.
Zitat von @mannid:
Man kann ja nach gleichem Schema auch verschlüsselten Zugriff benutzen - HTTPS mit Port 443
Zitat von @MirkoKR:
Mach dir den Aufwand erst gar nicht : Ihr spielt eh schon russisch Roulette, auf unverschlüsselte HTP:80 durchzuleiten...
Mach dir den Aufwand erst gar nicht : Ihr spielt eh schon russisch Roulette, auf unverschlüsselte HTP:80 durchzuleiten...
Man kann ja nach gleichem Schema auch verschlüsselten Zugriff benutzen - HTTPS mit Port 443
Prinzipiell wäre das möglich - aber viele IoTs bieten NUR HTTP an.
Also, was bis hier schon deutlich geworden sein sollte:
Statt eurer Durchleitungen sollte der Initiator ein VPN nutzen. Einmal durch das VPN mit dem Intranet verbunden, kann er ja alle IoTs mit ihren jeweiligen IP:Port Services ansprechen, ohne das Ihr etwas kritisches ins Internet veröffentlichen müsst.
Das erledigt zugleich auch die Port-Problematik im Mobilfunk.
.
Zitat von @mannid:
Im wesentlichen wird erstmal eine Möglichkeit gesucht, eine Reihe von Ports über IPv4 von aussen via Mobilfunk-Datenzugriff anzusteuern, wenn Mobilfunkanbieter solche Portanfragen nicht durchlassen.
Im wesentlichen wird erstmal eine Möglichkeit gesucht, eine Reihe von Ports über IPv4 von aussen via Mobilfunk-Datenzugriff anzusteuern, wenn Mobilfunkanbieter solche Portanfragen nicht durchlassen.
Das hat eigentlich nichts mit Mobilfunk oder Fernzugriff und VPN zu tun, sondern gilt genauso für den containerisierten cloud-nativen DevOps-Zoo, in dem sowas heute typischerweise zu finden ist:
Wenn du ein Protokoll wie HTTP/HTTPS ohne zwingenden Grund vom Standardport runter nimmst oder gar noch unterschiedliche Ports auf unterschiedlichen Servern verwendest, ist das ein deutliches Indiz für Pfusch.
Das machst du vielleicht jetzt auf einem Router, aber wie sollen in skalierten sicheren Umgebungen die zig Firewall-Konfigurationen aussehen, mit den Dienstobjekten "http01" bis "http30"?
Es ist immer vermeidbar, in dem Fall mit VPN, wie schon geschrieben, oder du machst zwei Portweiterleitungen 80 und 443 auf einen Reverse-Proxy, der 80 auf 443 umleitet, das dann schön authentifziert und per Host- oder Pfadregel die jeweiligen Geräte im Backend anspricht.
Grüße
Richard
Ok, also abgesehen von dem grundsätzlichen Problem, allerlei IoT-Kleingetier über verschiedene Ports mit der Außenwelt sprechen zu lassen und gerade die IoT-Welt nicht dafür bekannt ist, besondere Sorgfalt bei der Implementierung von sicherer Software walten zu lassen:
Es müsste mit einem globalen IP-Proxy funktionieren, wie z.B. "ngrok". Damit kann man u.a. irgendwelche IP-basierte Dienste auf andere Ports tunneln. Nach Außen ist dann eine Domain wie z.B. "blabla1234.eu.nrgok.io" bekannt. Dort wird dann immer ein Duo von HTTP und HTTPS eingerichtet.
ngrok kann auch bel. andere Ports weiterleiten, dann ändert sich das Aussehen der URL leicht. Damit kannst Du eventuell Portnummer so umsetzen, dass es den Mobilfunkanbietern genehm ist, z.B. von "12345" auf "8080" oder so.
Nutzt man unterschiedliche Hosts mit einem ngrok-Account, dann wird es allerdings kostenpflichtig.
Ausprobieren und die Nutzung von einem Host mit einer Weiterleitung, deren URL sich immer wieder ändert, kann man allerdings kostenlos und auf Dauer: ngrok.io.
Es müsste mit einem globalen IP-Proxy funktionieren, wie z.B. "ngrok". Damit kann man u.a. irgendwelche IP-basierte Dienste auf andere Ports tunneln. Nach Außen ist dann eine Domain wie z.B. "blabla1234.eu.nrgok.io" bekannt. Dort wird dann immer ein Duo von HTTP und HTTPS eingerichtet.
ngrok kann auch bel. andere Ports weiterleiten, dann ändert sich das Aussehen der URL leicht. Damit kannst Du eventuell Portnummer so umsetzen, dass es den Mobilfunkanbietern genehm ist, z.B. von "12345" auf "8080" oder so.
Nutzt man unterschiedliche Hosts mit einem ngrok-Account, dann wird es allerdings kostenpflichtig.
Ausprobieren und die Nutzung von einem Host mit einer Weiterleitung, deren URL sich immer wieder ändert, kann man allerdings kostenlos und auf Dauer: ngrok.io.
Fast
Wo ngrok läuft, ist egal. Es kann auf dem Host laufen, auf dem die "freizugebende" Software läuft. Dann bräuchte man halt auf jedem Rechner einen ngrok-Prozess. Vorteil: Fällt ein Rechner aus, dann fällt nur der eine Dienst und der eine ngrok aus.
Oder Du packst den ngrok-Prozess auf einen Rechner, der von vielen der Geräte im Netzwerk erreichbar ist, d.h. innerhalb der DMZ. Vorteil hier: eine Konfigurationsdatei für ngrok und ein Prozess. Nachteil: geht ngrok baden, ist kein Gerät mehr erreichbar. nrgok arbeitet wie ein normaler SSH-Tunnel mit beliebigen Ziel-Adressen und -Ports. Wenn Du im internen Netz für HTTP/HTTPS-Verbindungen noch einen HAproxy zwischenschaltest, kannst Du die HTTP-Anfragen sogar noch nach Query aufteilen, also z.B. "https://blablabla.eu.nrgok.io/soso" geht an "Rechner X" im Netzwerk und "https://blablablabla.eu.ngrok.io/hurra" geht an einen "Rechner Y" im Netzwerk.
Die kostenlose ngrok-Version hat einige Einschränkungen - Du kannst es zumindest aber so weit ausprobieren, als dass Du dann feststellen könntest, ob es technisch überhaupt machbar ist.
Lange Rede, kurzer Sinn: probier's aus ;)
Wo ngrok läuft, ist egal. Es kann auf dem Host laufen, auf dem die "freizugebende" Software läuft. Dann bräuchte man halt auf jedem Rechner einen ngrok-Prozess. Vorteil: Fällt ein Rechner aus, dann fällt nur der eine Dienst und der eine ngrok aus.
Oder Du packst den ngrok-Prozess auf einen Rechner, der von vielen der Geräte im Netzwerk erreichbar ist, d.h. innerhalb der DMZ. Vorteil hier: eine Konfigurationsdatei für ngrok und ein Prozess. Nachteil: geht ngrok baden, ist kein Gerät mehr erreichbar. nrgok arbeitet wie ein normaler SSH-Tunnel mit beliebigen Ziel-Adressen und -Ports. Wenn Du im internen Netz für HTTP/HTTPS-Verbindungen noch einen HAproxy zwischenschaltest, kannst Du die HTTP-Anfragen sogar noch nach Query aufteilen, also z.B. "https://blablabla.eu.nrgok.io/soso" geht an "Rechner X" im Netzwerk und "https://blablablabla.eu.ngrok.io/hurra" geht an einen "Rechner Y" im Netzwerk.
Die kostenlose ngrok-Version hat einige Einschränkungen - Du kannst es zumindest aber so weit ausprobieren, als dass Du dann feststellen könntest, ob es technisch überhaupt machbar ist.
Lange Rede, kurzer Sinn: probier's aus ;)
Wenn du schon einen Raspberry Pi im Einsatz hast, dann nimm den auch sinnvoll her und spiele Apache2 drauf.
Reverse Proxy mit Certbot und HTTPS und dann alle auf :443. Dann nimmst du dir haufenweise Subdomains und dann hast du es ein Stück sicherer als alles unverschlüsselt in den Jordan zu gehen.
Reverse Proxy mit Certbot und HTTPS und dann alle auf :443. Dann nimmst du dir haufenweise Subdomains und dann hast du es ein Stück sicherer als alles unverschlüsselt in den Jordan zu gehen.
Mit Nginx wäre er auf einem RasPi deutlich besser beraten. Mehr Performance bei weniger Resourcen Verbrauch !
Zitat von @148523:
Mit Nginx wäre er auf einem RasPi deutlich besser beraten. Mehr Performance bei weniger Resourcen Verbrauch !
Mit Nginx wäre er auf einem RasPi deutlich besser beraten. Mehr Performance bei weniger Resourcen Verbrauch !
Ja, das Prinzip ist dasselbe.
Zeit das der TO seinen Thread hier nun auch als erledigt schliesst !
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?