05.04.2023

1562

App über Externe Ip aus dem LAN erreichen

Hallo allerseits, ich habe mal wieder ein keines Problemchen.

Und zwar:

Es existiert auf einem Tablet eine App die auf einen Server zugreift, der im Internen LAN in der Firma steht.
Der Zugriff funktioniert wunderbar, solange das Tablet über MobileDaten auf den Server zugreift.
Sobald das Tablet aber im WLAN ist, geht das nicht mehr.

Der Server ist in der Tablet-App nur mit IP hinterlegt. Währe ein FQDN Name eingetragen, währe das kein Problem für mich.

Wie löse ich das am besten, ohne die App an allen Tablet auf FQDN umzustellen?

Die App kommuniziert über HTTP/HTTPS

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 6649774352

Url: https://administrator.de/forum/app-ueber-externe-ip-aus-dem-lan-erreichen-6649774352.html

Ausgedruckt am: 22.12.2024 um 08:12 Uhr

18 Kommentare

Neuester Kommentar

Stichwort Hairpin/Loopback NAT oder alternativ Split-DNS.

Cheers briggs

Als Firewall ist eine Securepoint UTM im Einsatz.

Zitat von @Ueba3ba:

Als Firewall ist eine Securepoint UTM im Einsatz.

Auch damit kann du Split DNS oder Loopback NAT umsetzen.

Die einfachere Variante wäre SPLIT DNS, da ihr sicherlich interne DNS Server nutzt.

Daher in der App wird der DNS Name vom Server hinterlegt, intern löst der interne DNS Server die interne LAN Adresse auf.

Über Mobilfunk wird auf die externe IP Adresse aufgelöst. Natürlich müsst ihr den externen A-Record dann für bei eurer DNS Zone beim Provider oder wo auch immer hinterlegen

Ok danke sehr. Ich schau mir das mal an.

Die nächste Krücke bauen ist attraktiver.als es zu lösen und ordentlich zu arbeiten?

Die App kommuniziert über HTTP/HTTPS

Die Frage ist ja letztlich auch WIE das Tablet mit dieser IP kommuniziert?

Direkt, sprich am Ziel mit einer öffentlichen Server IP (DMZ etc.) oder Port Forwarding an der Firewall auf eine lokale LAN IP. Wenn dann wirklich HTTP zum Einsatz kommen sollte wäre das natürlich höchst naiv und fahrlässig, da massiv unsicher.
Über ein VPN. Da stellt sich dann die Frage ob das WLAN IP Netz im VPN Tunnel übertragen wird.

All das ist ja völlig unklar aus der Beschreibung und wenn in der App nur eine nackte Ziel v4 IP definiert ist dann sind DNS Problematiken eigentlich ja raus aus dem Spiel.

Das Tablet kommuniziert über Mobile Daten, der Server wird über die öffentliche IP und Port Forwarding ins lokale LAN erreicht. Es ist eine HTTPS Verbindung.

Es gibt kein VPN.

das Problem konnte mit folgendem Securepoint Artikel gelöst werden:

https://wiki.securepoint.de/UTM/RULE/Portumleitung-Intern

Danke an alle.

Servus, ich nochmal.

Leider ist es so, dass bei fast allen unserer Kunden eine Fritzbox die DSL Einwahl macht.
Die Fritzbox ist leider auch im Router Modus, somit haben wir auch überall doppeltes NAT.

So wie ich das jetzt laut dem Securepoint Wiki eingerichtet habe, funktioniert es leider nicht.
Da kam mir der Gedanke: Könnte es am doppelten NAT liegen??

Die Fritzbox ist leider auch im Router Modus, somit haben wir auch überall doppeltes NAT.

Wieso leider?? Wo ist denn das Problem? Der Verbindung tut das auch mit dreifachem NAT keinen Abbruch. Was willst du uns also sagen mit dem Hinweis??

funktioniert es leider nicht.

Unverständlich?? Simpes HTTPS Port Forwarding für TCP 443. Was sollte daran denn nicht funktionieren? Das macht jede Firewall in 5 Minuten.

War nur ein Gedanke. Bei NAT blick ich nicht richtig durch.

Firewall ist, wie im Wiki beschrieben konfiguriert worden.

Das komplette Netzwerk Design ist mehr als grusselig.

Ich behaupte nicht die meiste Ahnung zu haben. Nur kommen dann Leute, die Netzwerktechnisch
nicht auf dem laufendem sind an, und verwirren einfach nur.

Am liebsten würde ich die Finger davon lassen und das komplette Netz neu designen.
Da stoß ich auf taube Ohren.

Bei NAT blick ich nicht richtig durch.

Warum nicht, ist doch kinderleicht. Alles was an RFC1918 IP Netzen hinter dem Router/Firewall liegt wird als Absender IP per Source NAT auf die WAN IP übersetzt. So "denken" Endgeräte im Internet deine lokalen Absender haben eine öffentliche Internet IP.

https://de.wikipedia.org/wiki/Netzwerkadressübersetzung
Das ist kein Hexenwerk...

Das komplette Netzwerk Design ist mehr als grusselig.

Du meinst sicher gruselig, aber das können wir leider ja nicht wirklich beurteilen weil du leider keine Topologieskizze mitgeliefert hast.

Leute, die Netzwerktechnisch nicht auf dem laufendem sind an, und verwirren einfach nur.

Das ist leider häufig richtig aber die darf man halt nicht an sich ranlassen. Das ist aber kein technisches sondern ein politisches Problem.

Am liebsten würde ich die Finger davon lassen

Dann halte dich auch besser daran. Oder wenn du dennoch nicht davon lassen kannst... schicke mal eine kleine Toposkizze damit alle hier wissen worum es wirklich geht.

Schöne Ostern!

Ohne zu übertreiben. So schaut es aus.

Alle Mobilen Geräte rufen ihre Mails vom David Server(192.168.100.10) ab.
Als Server IP ist in den Mobilen Geräten die Externe IP(als Beispiel hier die 217.217.217.217) eingetragen. Funktioniert, solange das Mobile Gerät sich nicht im internen LAN befindet.

Sobald sich die Mobilen Geräte ins Wlan einloggen, funktioniert es nicht mehr.

Daraufhin wurde Hairpinning NAT wie im Wiki von Securepoint beschrieben eingerichtet.
Leider ohne Erfolg. Es muss ich natürlich Troubleshooten.

Warum werden IPs in dieser Ebene in konfigs eingetragen?
Suche dir doch einfach Hilfe.

Externe IP(als Beispiel hier die 217.217.217.217)

OK, und diese macht dann ein TCP 443 Port Forwarding auf die 192.168.100.10, richtig?
Sprich Emails werden dann nur per HTTPS, TCP 443 abgefragt

Wenn die Ziel IP immer auf die externen IP zeigt rennst du beim Zugriff von einem internen IP Netz immer in ein Hairpin NAT Problem, weil du dann aus einem internen LAN auf die externe IP gehst und die dann wieder nach intern muss. An diesem NAT Hairpinning scheitern die meisten Router oder Firewalls wenn man das nicht explizit customized im Setup das sowas erlaubt!
Du musst dann also mit dem o.g. "Split-DNS" arbeiten oder Hairpinnig erlauben.

Du kannst das ja ganz einfach mal testen mit einem Gerät.
Setze dort den Zielserver der App oder Browser auf die 192.168.100.10. Dann sollte es auch immer aus dem WLAN klappen.