Externe IP-Adresse aus dem Heim-Netzwerk nicht erreichbar

psbase2

Cadet 1st Year
Registriert
Okt. 2020
Beiträge
8
Guten Tag,
  • ich habe in meinem Heim-Netzwerk einen Synology NAS stehen den ich von aussen über port 5000 und 5001 erreichbar mache (D.h. Port-Forwarding ist auf dem Router eingerichtet)
  • ich habe von meinem ISP (Unitymedia/Vodafone) einen Full Dual Stack-Anschluss, bei dem ich eine statische IP-Adresse zugewiesen bekommen habe.
  • Wenn aus dem WAN auf diese statische IP zugreife funktioniert alles (z.B. ping auf diese IP geht, und Zugriff auf den NAS mit IP und Port geht)
  • Wenn ich aber aus meinem Heimnetzwerk (über WLAN oder Ethernet) auf diese IP zugreife funktioniert es nicht (auch nicht mal der Ping). Da muss ich dann schon die lokale IP-Adresse des Heimnetzwerkes verwenden, damit das funktioniert.

Das ist für mich deshalb ein Problem, weil ich eine Domaine habe, die auf diese IP-Adresse zeigt (samt SSL-Zertifikat), die ich sowohl für den Zugriff von aussen als auch von Innen nutzen möchte.

Ich habe bereits bei Unitymedia angerufen, aber natürlich kann da keiner weiterhelfen.

Habt ihr noch Ideen, was man hier versuchen kann?

Für Vorschläge bin ich mehr als dankbar. Ich kann zu diesem Problem keine Infos im Netz finden.

Beste Grüße
Nicolas
 
Das wird am Router liegen, der wird kein NAT-Loopback können oder nicht konfiguriert haben. Das gleiche Problem habe ich ebenfalls und so gelöst, das ich einen LAN-internen DNS-Server benutze, der für die Domain auf die interne IP zeigen lässt. Manche Router bieten ebenfalls an manuel DNS-Einträge zu setzen.
 
  • Gefällt mir
Reaktionen: brainDotExe, Raijin, Ebrithil und eine weitere Person
von innen über die externe ip auf eine interne ip zugreifen geht bei vielen allen Routern nicht da sie kein NAT-Loopback können.
Deswegen musst du deinen DNS anpassen so das der eine interne ip adresse für das gerät ausspuckt
 
Man könnte auch einfach die interne IP nehmen ;)
 
  • Gefällt mir
Reaktionen: Nyxor
Ja, normalerweise macht man das so, Verknüpfung auf den Desktop und gut.
 
Hi @KWMM , danke für den Vorschlag. Das Problem ist nur, dass ich einige Apps verwende, die sich mit meinem NAS verbinden. Bei diesen Apps kann ich eben nur einen Host eintragen. Der soll dann funktionieren, egal ob ich unterwegs bin oder zu Hause. Ich will ja nicht immer den Host in meinen ganzen Apps anpassen, nur weil ich jetzt Netz wechsle beim aus dem Haus gehen.

@ All, Danke allen anderen für den NAT-Loopback-Hinweis. Das erklärt natürlich das Problem. Ich dachte schon das hat was mit dem Dual-Stack zu tun.

Ich habe eine Unitymedia-Box. Die ist natürlich extrem rudimentär, da kann ich nichts konfigurieren. Da müsste ich dann ein anderes Gerät davor setzen mit dem sich dann alle Geräte verbinden, was den NAT-Loopback unterstützt. Wie ärgerlich. Das Problem würde ich allerdings schon gerne einmalig an der Quelle beheben. Denn auf allen Endgeräten irgendwie den DNS-Server manuell einzustellen ist nicht praktikabel.
 
Abgesehen vom NAT-Loopback: Aus dem LAN möchtest du üblicherweise deine Pakete nicht erst durch das halbe Internet schicken, um ein Gerät zu erreichen, das in deinem LAN hängt. Dann bist du nämlich auch durch den Upload deines Internetanschlusses beschränkt und kannst nicht das schöne Gigabit vom Switch nutzen.
Ergänzung ()

psbase2 schrieb:
Das Problem ist nur, dass ich einige Apps verwende, die sich mit meinem NAS verbinden. Bei diesen Apps kann ich eben nur einen Host eintragen. Der soll dann funktionieren, egal ob ich unterwegs bin oder zu Hause.

Das Problem haben alle mit Geräten, die mal im LAN und mal außerhalb des LANs sind. Du kannst es mit zwei Hostnamen lösen, z. B. NAS-im-LAN und NAS-Unterwegs, die dann einmal auf deine WAN-IP und einmal auf deine LAN-IP zeigen. Je nachdem, wo du gerade unterwegs bist, mußt du den entsprechenden Hostnamen verwenden.
 
Ein NAS sollte NICHT von außen erreichbar sein, wenn man an seinen Daten hängt!
Für solche Zwecke ist VPN gedacht und weitaus geeigneter, würde gleichzeitig auch das Problem mit unterschiedlichen IPs lösen.
 
Afaik musst du in der Fritzbox die öffentliche Adresse des NAS in den Rebind-Schutz eintragen. Befindet sich dein Client im LAN und will auf das NAS zugreifen geht der Client über den DNS Namen, der zeigt auf die WAN-Seite der Fritzbox, dein Client schickt die Anfrage los, die geht zur Fritzbox durch alle Regeln etc bis zum WAN-Port, macht dort eine 180° Wende und geht dann weiter an das NAS.
Nicht schön aber funktioniert.

@GaborDenes Jain. Wenn auf dem NAS ein abgesicherter(!) Webserver oder anderer Dienst läuft unterscheidet das NAS sich wie genau von irgendeinem vServer von denen auch ein Großteil alles aber nicht abgesichert sind^^
Wenn man sich um die Absicherung nicht kümmern kann oder will ist ein VPN natürlich eine gute und absolut sinnvolle Empfehlung aber dann kommt es natürlich auch darauf an wo das VPN läuft, ob das auch nur zeitgemäße und sichere Ciphers verwendet, entsprechend lange/sichere Kennwörter o.ä. nutzt usw. usf.
 
psbase2 schrieb:
Das Problem würde ich allerdings schon gerne einmalig an der Quelle beheben. Denn auf allen Endgeräten irgendwie den DNS-Server manuell einzustellen ist nicht praktikabel.

DHCP kennst? :p Hol dir doch eine RaspberryPi und mach dem zum DHCP (vorher am Router deaktivieren) + DNS (evtl. gleich mit PiHole) und trag am eigenen DHCP die Adresse des internen DNS-Servers eins -> keine weiteren Einstellungen an den Endgeräten notwendig.
BTW.: Die Synology NASe bieten in der Regel auch die Möglichkeit DNS und DHCP zu "spielen". Du brauchst also nicht mal eine Neuanschaffung, lediglich das NAS entsprechend konfigurieren und DHCP am Router deaktiveren.
 
DeusoftheWired schrieb:
Abgesehen vom NAT-Loopback: Aus dem LAN möchtest du üblicherweise deine Pakete nicht erst durch das halbe Internet schicken, um ein Gerät zu erreichen, das in deinem LAN hängt. Dann bist du nämlich auch durch den Upload deines Internetanschlusses beschränkt und kannst nicht das schöne Gigabit vom Switch nutzen.
Fast. Bei NAT-Loopback dreht der Router den Traffic gewissermaßen innerhalb des WAN-Ports um 180°. Der Provider bekommt kein einziges Bit von der Verbindung mit.

/ WAN-Port <--- Router <--- PC
NAT-Loopback
\ WAN-Port ---> Router ---> NAS

Allerdings hast du schon Recht damit, dass die Verbindung zwischen PC und NAS hierbei limitiert werden kann, zwar nicht durch den Internetanschluss, aber durch die WAN<>LAN NAT-Performance des Routers. Wenn der Router am WAN volle 1 Gbit/s kann, wird man auch bei NAT-Loopback kaum etwas merken, auch nicht, wenn man nur VDSL25 hat. Schafft der Router am WAN aber max 100 Mbit/s, weil das Gerät nicht für schnelle Internetzugänge gedacht oder einfach zu alt ist, dann wird die gesamte Verbindung zwischen PC und NAS auf eben diese 100 Mbit/s limitiert.

NAT-Loopback ist in der Regel eine Krücke. Bei Anwendungen, die auf Datendurchsatz angewiesen sind, kann sich das massiv negativ auswirken. In solchen Fällen sollte man daher definitiv den lokalen DNS im Netzwerk so konfigurieren, dass er diese Domain direkt mit der lokalen IP-Adresse des Ziels beantwortet. Sobald vom DNS eine lokale IP zurückkommt und nicht mehr die öffentliche, geht die Verbindung direkt PC <Switch> NAS, mit vollen 1 Gbit/s. Ich rate grundsätzlich immer zur lokalen DNS-Lösung, weil ich NAT-Loopback prinzipiell nicht mag und der Traffic je nach Netzwerkgröße daheim quer durch das Haus geht obwohl die Geräte nebeneinander stehen, und weil es in meinen Augen einfach sauberer und vor allem vom Router unabhängig ist. Selbst wenn du an deinem Router jetzt NAT-Loopback - manchmal auch Hairpin-NAT genannt - anschaltest, kann es sein, dass du irgendwann den Provider und damit den Router wechselst und der hat das dann plötzlich überhaupt nicht implementiert......
 
  • Gefällt mir
Reaktionen: snaxilian und cc_aero
Hallo zusammen,

super. Danke zusammen. Ich habe einiges gelernt. Jetzt wollte ich mal in die Umsetzung gehen und schauen, ob ich über einen eigenen DHCP und DNS Server das regeln kann. Mein Internet-Router kann das nicht. Meine Idee ist also dass ich auf dem NAS einen eigenen DNS-Server habe, der den hostname meines NAS auf die lokale IP des NAS umwandeln und für alles andere an einen öffentlichen DNS server weiterleitet.

Allerdings stoss ich da auf Probleme.

Ich habe folgendes Hardware im Spiel:
  1. Eine Unitymedia Connect Box (der Router von Unitymedia)
  2. Ein TP-Link-Router auf dem ich Firmware für DD-WRT eingespielt habe
  3. Eine Synology Diskstation (mein NAS)
Bei Connect Box kann man sogut wie nichts machen. Man kann zwar den DHCP für ipv4 abschalten, aber der DHCP für ipv6 läuft dann trotzdem weiter. NAT-Loopback oder DNS geht schonmal garnicht. Daher habe ich die Connect Box in den Bridge Mode gesetzt, damit diese nur noch ein dummer Router ist. Sie bekommt dadurch dann automatisch die IP 192.168.100.1.

Ich habe dann meinen alten TP-Link Router ausgepackt. Diesem habe ich für das LAN die IP 192.168.1.1 gegeben. Im WAN hat er die 192.168.100.2. Er soll lediglich nur zwischen LAN und WAN routen und DHCP machen. Beim DHCP soll er den DNS meiner Synology Diskstation verteilen (diese ist dann die 192.168.1.2).

Der TP-Link ist mit dem WAN-Port und einem beliebigen Port der Unitymedia Connect Box verbunden.

Im LAN ist dann noch die Synology Diskstation mit der IP 192.168.1.2. Diese übernimmt die Aufgabe des DNS. Am liebsten hätte ich ja (DHCP+DNS) auf dem TP-Link Router gemacht. In der Firmware des DD-WRT habe ich aber keine Option gefunden DNS oder NAT-Loopback einzustellen.

Leider funktioniert mein tolles Setup aber nicht.

Anbei ein paar Screenshots von der Konfiguration des TP-Links. Ich habe zum Testen den DNS auf 8.8.8. gestellt (und nicht auf meinen NAS).

Von meinem lokalen Rechner aus habe ich korrekt eine IP im Bereicht 192.168.1.* erhalten. Gateway und DNS zeigen beide korrekt auf 192.168.1.1.

Dann mache ich einen Ping auf den TP-Link-Router und die Connect Box. Das geht (siehe Screenshot).

Führe ich einen tracert auf eine IP-Adresse von google.com, dann geht der Trace bis zum TP-Link Router, aber nicht mehr bis zur Connect-Box.

Im Grossen und ganzen komme ich also nicht mehr ins WAN.

Habt ihr Vorschläge? Ich habe schon ewig rumgespielt und mir gehen die Ideen aus.

Übrigens: Wenn mir einer bestätigt, dass ich einfach eine Fritzbox kaufen kann, die den NAT-Loopback macht und meine Unitymedia Connect Box ersetzt, dann finde ich diese Option auch Top und würde das machen.
Ergänzung ()

Sieht so aus als unterstützt die FRITZ!Box 6591 den DNS-Rebind. Ich denke, wenn ich das anders nicht hinbekomme, hole ich sie mir.
 

Anhänge

  • Ping.png
    Ping.png
    56,1 KB · Aufrufe: 291
  • TP-Link LAN Setup.png
    TP-Link LAN Setup.png
    46,9 KB · Aufrufe: 300
  • TP-Link Status im LAN.png
    TP-Link Status im LAN.png
    67,2 KB · Aufrufe: 287
  • TP-Link Status im WAN.png
    TP-Link Status im WAN.png
    48,6 KB · Aufrufe: 295
  • TP-Link WAN Setup.png
    TP-Link WAN Setup.png
    66,3 KB · Aufrufe: 308
Zuletzt bearbeitet:
Bevor du jetzt groß anfängst zu basteln oder einen anderen Router kaufst, warum nutzt du nicht zusätzlich IPv6 bei deiner Domain?
Dann kannst du auch weiterhin deine Connect Box als Router nutzen und musst nicht den TP-Link dazwischen schalten.
 
Zuletzt bearbeitet:
psbase2 schrieb:
TP-Link Router ausgepackt. Diesem habe ich für das LAN die IP 192.168.1.1 gegeben. Im WAN hat er die 192.168.100.2
Erster Fehler. WAN-Config auf DHCP belassen. Die Connectbox ist ja jetzt im bridge modus und daher nur noch Modem. (Das die ConnectBox zusätzlich eine eigene IP hat an ihrem LAN-Interface ignorieren wir hier mal, ist für das Thema Internet nämlich nicht relevant).
psbase2 schrieb:
Am liebsten hätte ich ja (DHCP+DNS) auf dem TP-Link Router gemacht. In der Firmware des DD-WRT habe ich aber keine Option gefunden DNS
Zweiter Fehler. Oder du hast nicht gründlich oder falsch gesucht: https://wiki.dd-wrt.com/wiki/index.php/DNSMasq_-_DNS_for_your_local_network_-_HOWTO
psbase2 schrieb:
Führe ich einen tracert auf eine IP-Adresse von google.com, dann geht der Trace bis zum TP-Link Router, aber nicht mehr bis zur Connect-Box.

Im Grossen und ganzen komme ich also nicht mehr ins WAN.
System funktioniert, wie von dir eingerichtet und daher nicht korrekt. Der TP-Link Router hängt mit seinem WAN-Port auch lediglich im "Konfigurationsnetz" des Modems, siehe weiter oben. Den Teil wollten wir ja vorerst ignorieren. Der TP-Link Router kennt somit genau zwei Netzwerke: Das 192.168.100.0/24 an seinem WAN-Interface und das 192.168.1.0/24 an seinen LAN-Interfaces.

Des Weiteren hat der TP-Link auf der LAN-Seite ja eine IP aus dem 192.168.1.0/24 Subnetz aber der DHCP-Server des TP-Link soll Adressen im 192.168.100.0/24 verteilen? Somit Fehler Nummer drei.

Ebenso vermute ich, dass du die Funktionsweise von DNS nicht ganz verstehst (was auch bei vielen IT'lern der Fall ist also nicht ärgern oder schlimmeres). Daher ein kleiner Exkurs:
In der Regel, sprich den allermeisten Privathaushalten, laufen DNS und DHCP auf einem Gerät und die zwei Dienste sprechen zusammen. Wenn dein NAS den Hostname tolles-nas hat und dein Pc den Hostname toller-pc und beide Geräte ihre IP per DHCP beziehen so hat das zur Folge, dass du am PC sitzt und auf dein NAS im Explorer über \\tolles-nas\ zugreifen kannst und niemand muss sich irgendwelche IPs merken.
Trennt man jetzt DNS und DHCP muss man selbst dafür sorgen, dass diese Dienste untereinander Informationen austauschen oder muss diese Infos von Hand verteilen. Wenn du jetzt aber in deinem Client als DNS fest die 8.8.8.8 (oder andere frei nutzbare DNS-Server im Internet) dann gehen alle deine Anfragen dort hin. Das Ergebnis ist: \\tolles-nas\ funktioniert nicht mehr weil der öffentliche DNS davon keine Ahnung hat. Bei einem lokalen DNS hingegen klappt das und alle andere Anfragen, z.B. nach computerbase.de leitet der interne DNS dann an den DNS-Server weiter, der für alles andere eingetragen ist.</Exkurs Ende>

Keine Ahnung ob dir da elementares Grundlagenverständnis fehlt oder ob es alles nur Flüchtigkeitsfehler sind aber falls ersteres ersparst du dir mit dem Kauf einer passenden Fritzbox eine Menge Frust und Zeit. Wenn du an dem Setup auch etwas lernen willst dann kannst die bestehende Lösung natürlich korrigieren und früher oder später mit genug Eigeninitiative und gezielten Fragen und Suchen in Foren, Wikis etc kommst auch zu einem Ergebnis.
 
@brainDotExe : Leider unterstützt mein Domain-Provider (OVH) nur ipv4 für "A" oder "CNAME". DynDNS ist für mich nicht relevant, da würde aber auch nur ipv4 gehen. Dennoch danke für den Tipp.

@snaxilian, danke dass du dir Zeit für die ausführlichen Erläuterungen genommen hast. Ich habs mehrmals durchgelesen, bin mir aber nicht sicher ob ich alles gut verstanden habe. Ich habe mich jetzt dennoch entschlossen einfach eine Fritzbox zu holen, dann spar ich mir die Mühe. Dennoch würde ich dir wenigstens gerne noch antworten.

Zu Fehler 1: Bei der WAN-Konfiguration kann ich DHCP auswählen. Das heisst aber dass der TP-Link aber eine IP im WAN zugewiesen bekommt und nicht dass er als DHCP-Server fungiert. War das so gemeint gewesen?

Zu Fehler 2: Oh, das habe ich in der Tat nicht gut recherchiert. Ich war nur im UI des DD-WRT. In die commando-zeile wollte ich dafür eigentlich nicht wechseln :-/

Zu Fehler 3 (mit dem DNS): Ich hatte ja geschrieben dass ich 8.8.8.8 erstmal nur temporär eingetragen habe, damit DNS generell erstmal funktioniert. Wollte damit die möglichen Fehlerquellen einschränken. Später sollte da der DNS von meinem NAS eingetragen werden, der für meine domain ds.meindomainname.com die lokale IP auflösen soll. Der DHCP des Router sollte dann hoffentlich diesen DNS-Server nutzen, wenn DNS-Anfragen von Geräten meines Heimnetzes an den Router gehen. Davon bin ich jedenfalls mal ausgegangen. Im Internet (mit öffentlichen DNS-Servern) würde ds.meindomainname.com natürlich auf meine externe statische IP-Adresse zeigen.

Njun gut. Danke an alle für die tollen Tipps :-) Vielleicht können wir ja den Thread dann hier als schliessen. Weiss nicht ob da jetzt sofort ein "RESOLVED" in den Titel soll. Resolved ist es jetzt dann mit einem anderem Router :D
 
psbase2 schrieb:
Leider unterstützt mein Domain-Provider (OVH) nur ipv4 für "A" oder "CNAME". DynDNS ist für mich nicht relevant, da würde aber auch nur ipv4 gehen. Dennoch danke für den Tipp.
Sicher das OVH keinen "AAAA" Record unterstützt? Das ist heutzutage eigentlich Standard.
OVH erwähnt es zumindest in der Doku:
https://docs.ovh.com/de/domains/webhosting_bearbeiten_der_dns_zone/

Ansonsten, das wäre für mich ein Grund den Anbieter zu wechseln.
 
  • Gefällt mir
Reaktionen: snaxilian
psbase2 schrieb:
ipv4 für "A" oder "CNAME"
Der werte @brainDotExe sprach ja auch von IPv6 und nicht von IPv4 und da wäre ein Host-Record entsprechend ein AAAA Record ;)
psbase2 schrieb:
Das heisst aber dass der TP-Link aber eine IP im WAN zugewiesen bekommt und nicht dass er als DHCP-Server fungiert.
Korrekt, am WAN Port weist dir ja auch dein ISP entsprechend eine IPv4 Adresse zu, bei einem statischen Anschluss dann halt immer die gleiche Adresse aber ändert nix an der Tatsache, dass hier DHCP zum Einsatz kommt. Du kannst bei einer statischen Adresse auch alternativ natürlich 'static' verwenden aber dann sollte man wissen was man da tut und zwar die eigene statische öffentliche IPv4 mit korrekter Subnetmask und Gateway verwenden ;)
psbase2 schrieb:
In die commando-zeile wollte ich dafür eigentlich nicht wechseln
Du stellst ja schon wieder Vermutungen an und phantasierst dir etwas zusammen, vielleicht ist ein Esoterik- oder Religionsforum eher geeignet dafür?^^:stock:
Wenn du die verlinkte Seite aus dem dd-wrt Wiki gelesen hättest dann wäre dir aufgefallen, dass es auch problemlos Wege gibt solche Einstellungen über das Webinterface zu setzen.
 
Zurück
Oben