Netzwerk: Knobelaufgabe

[viertakter]

Ein aus meiner Sicht recht simpler Ansatz für die interne Erreichbarkeit ist, für das LAN einen eigenen dns server aufzusetzen (sollte auf dem NAS auch möglich sein) und ist nicht besonders komplex. Die externen hostnamen im DNS auf die LAN adressen auflösen und alle anderen anfragen an externe DNS Server forwarden (8.8.8.8 z.b.). Dann auf allen Geräten im LAN per DHCP den alternativen DNS server setzen oder statisch konfigurieren.

[alexmosel]

Also ich habe sowas wie oben geschrieben mit der Fritzbox und entsprechenden portweiterleitungen gelöst...die Adressen sind intern und extern aufrufbar...

was die verschiedenen Subdomains bringen sollen habe ich noch nicht verstanden, denn eigentlich gehts nur um die ports


Port 81 auf interne ip.....port 80
port 82 auf internet ip....port 80
usw
Das kann man so in der Fritztbox einstellen

und dann eine adresse....wasweißich.dyndns.com

oder so ähnlich

[Chili]

Zitat von viertakter

Ein aus meiner Sicht recht simpler Ansatz für die interne Erreichbarkeit ist, für das LAN einen eigenen dns server aufzusetzen (sollte auf dem NAS auch möglich sein) und ist nicht besonders komplex. Die externen hostnamen im DNS auf die LAN adressen auflösen und alle anderen anfragen an externe DNS Server forwarden (8.8.8.8 z.b.). Dann auf allen Geräten im LAN per DHCP den alternativen DNS server setzen oder statisch konfigurieren.

Du hast aber schon das ganze Thema gelesen??
Im Kern geht es darum, EINE Adresse aufzulösen ("statischer Host" = DNS-Eintrag; das ist nicht das Thema) und trotzdem mit verschiedenen Ports verschiedene Hosts anzusprechen.

Zitat von Alex von der Mosel

Also ich habe sowas wie oben geschrieben mit der Fritzbox und entsprechenden portweiterleitungen gelöst

Hatten wir weiter vorne schon: weil die FrtzBox als "Consumer-Produkt" auch die internen Anfragen quasi nach draussen schickt und als "Schleife" wieder rein bekommt und damit das Regelwerk für externe Verbindungsversuche auch intern anwendet - das nennt sich NAT-Loopback.

[viertakter]

Ja, ich habe das ganze Thema gelesen und dazu verstanden. Meine Antwort bezog sich allein darauf, dass die hosts von intern und extern über dieselben Namen erreichbar sein sollen. Das erreichst du, indem du die Anfragen intern über split-brain-dns auf lokale Adressen auflöst, von extern auf die public IP. Wenn dich dieser Ansatz nicht interessiert, auch ok für mich.

Bzgl mehreren hosts, die auf denselben Ports lauschen und deren Veröffentlichung wurde dir schon zu reverse proxy geraten. Wenn es für dein Protokoll keinen reverse proxy gibt, musst du auf verschiedene Ports natten, Pech jehabt.. Das hat mit meinem Vorschlag aber nix zu tun... Du hast ja schließlich auch nicht nur ein "Problem".

[Chili]

Zitat:

Zitat von viertakter

Ja, ich habe das ganze Thema gelesen und dazu verstanden. Meine Antwort bezog sich allein darauf, dass die hosts von intern und extern über dieselben Namen erreichbar sein sollen. Das erreichst du, indem du die Anfragen intern über split-brain-dns auf lokale Adressen auflöst, von extern auf die public IP. Wenn dich dieser Ansatz nicht interessiert, auch ok für mich.

Ohne dir zu nahe treten zu wollen - aber ich glaube nicht, dass du es wirklich verstanden hast.
(Also das Problem ja, aber nicht die Lösungsmöglichkeiten.)

Ein konkretes Beispiel, wie es bei mir zuhause steht.
Die IPs sind allesamt real.

Eine Synology hat die 192.168.10.10.
Eine Kamera hat die 192.168.10.20.
Die Homematic CCU2 hat die 192.168.10.3.

Es gibt noch viel mehr: IP-Steckdosenleisten, weitere Kameras etc.

Ich könnte - das ist das, was du als "Split-DNS" bezeichnest - statische Hosts einrichten im DNS des Routers:

cloud.medrow.com -> 192.168.10.10
cam1.medrow.com -> 192.168.10.20
home.medrow.com -> 192.168.10.3

Von intern - wenn also der Router als DNS befragt wird - funktioniert das, klar. So habe ich es auch.

Und jetzt erklär DU mir, wie ich das von extern erreichbar mache.

[viertakter]

Also nochmal... Du hattest mehrere Probleme:

1) Die Erreichbarkeit der lokalen Geräte über dieselben Namen, egal ob von intern oder extern - die Lösung hierfür ist Dir ja bereits bekannt. Split-Brain-DNS steht einfach ausgedrückt dafür, eine öffentliche Domain sowohl extern, als auch intern zu verwenden. Das interne DNS löst die (Sub)Domains auf lokale Adressen auf, das öffentliche DNS auf öffentliche Adressen bzw. Deine WAN IP des Routers. Wenn die Namen oben zutreffen, würde cloud.medrow.com z.B. von einem Gerät im LAN über den Router auf 192.168.10.10 aufgelöst, von einem Gerät, das einen öffentlichen DNS Server verwendet auf die Public IP Deines Routers (sofern Du die Domain medrow.com z.B. über einen DynDNS Dienst "pflegst"). Für alle anderen Subdomains werden intern andere LAN-Adressen zurückgegeben, extern dieselbe WAN-Adresse. Das bringt Dich zu Punkt 2.

2) Da von extern alle Anfragen auf alle Subdomains auf dieselbe WAN-IP aufgelöst werden und alle Endgeräte auf demselben Port lauschen, kannst Du hier kein reines NATing verwenden, wie Dir ja bereits bekannt. Demnach brauchst Du ein "intelligentes Gateway", das abhängig vom aufgerufenen DNS Namen (bzw. der aufgerufenen URL) an unterschiedliche interne IP-Adressen weiterleitet... mit einer handelsüblichen Fritzbox ist das (meines Wissens) nicht möglich. Deshalb der oben genannte Hinweis:

Bzgl mehreren hosts, die auf denselben Ports lauschen und deren Veröffentlichung wurde dir schon zu reverse proxy geraten.

Sofern die Endgeräte im LAN alle einen Dienst auf Port 80/443 laufen haben, müssten auf der Fritzbox alle Anfragen für Port 80/443 auf den Reverse Proxy weitergeleitet werden, der dann anhand des Domainnamens bzw. der URL lokal weiter verteilt. Für HTTP/HTTPS gibt es zahlreiche kostenlose Produkte für Reverse Proxies (Squid z.B.) - ich verwende hierfür Sophos UTM Home, welche als Firewall eine "Webserver Protection" gleich mitliefert, die diesen Zweck erfüllt.

Sofern die Hosts im LAN allerdings Protokolle verwenden, die von außen auf demselben Port erreichbar sein sollen, aber für die es keinen Reverse Proxy gibt, sieht es schlecht aus.

Die Kommentare dazu, ob ich Dein Problem verstanden habe oder nicht würde ich mir übrigens sparen... Du kannst mir ruhig glauben, dass ich Dich verstehe, aber es motiviert nicht unbedingt, Dir behilflich sein zu wollen.

[Chili]

Zitat von viertakter

... sofern Du die Domain medrow.com z.B. über einen DynDNS Dienst "pflegst"). Für alle anderen Subdomains werden intern andere LAN-Adressen zurückgegeben, extern dieselbe WAN-Adresse. Das bringt Dich zu Punkt 2.

Extern die gleiche Adresse: jepp, okay.
Intern - damit meinst du Aufrufe von intern: jepp, löst intern verschieden auf.

2) Da von extern alle Anfragen auf alle Subdomains auf dieselbe WAN-IP aufgelöst werden und alle Endgeräte auf demselben Port lauschen, kannst Du hier kein reines NATing verwenden, wie Dir ja bereits bekannt. Demnach brauchst Du ein "intelligentes Gateway", das abhängig vom aufgerufenen DNS Namen (bzw. der aufgerufenen URL) an unterschiedliche interne IP-Adressen weiterleitet...

Ja, soweit korrekt.

mit einer handelsüblichen Fritzbox ist das (meines Wissens) nicht möglich.

Mit jedem anderen Router auch nicht, weil auf der OSI-Ebene, wo das Routing stattfindet, keine Header-Informationen bekannt sind.

Sofern die Endgeräte im LAN alle einen Dienst auf Port 80/443 laufen haben, müssten auf der Fritzbox alle Anfragen für Port 80/443 auf den Reverse Proxy weitergeleitet werden, der dann anhand des Domainnamens bzw. der URL lokal weiter verteilt. Für HTTP/HTTPS gibt es zahlreiche kostenlose Produkte für Reverse Proxies (Squid z.B.) - ich verwende hierfür Sophos UTM Home, welche als Firewall eine "Webserver Protection" gleich mitliefert, die diesen Zweck erfüllt.

Jetzt die ABERs:
Das bedeutet aber separate Maschine = Mehrkosten.
Und jetzt geh mal einen Gedanken weiter: für HTTP gibt's Headerinformationen, speziell den Host Header.
Was ist mit den anderen Protokollen? FTP zum Beispiel kennt sowas nicht, RDP und RTP auch nicht.
Und insbesondere RTP - was bei Netzwerkkameras Verwendung findet - ist hier bei mir gefragt.
Das hatten wir auf der ersten Seite bereits.

Sofern die Hosts im LAN allerdings Protokolle verwenden, die von außen auf demselben Port erreichbar sein sollen, aber für die es keinen Reverse Proxy gibt, sieht es schlecht aus.

Kann es nicht geben, weil es - wie gesagt - die auswertbaren Informationen wie bei HTTP nicht gibt.

Die Kommentare dazu, ob ich Dein Problem verstanden habe oder nicht würde ich mir übrigens sparen... Du kannst mir ruhig glauben, dass ich Dich verstehe, aber es motiviert nicht unbedingt, Dir behilflich sein zu wollen.

Das liegt daran, dass deine Beiträge schlicht nicht hilfreich waren.
Nachdem ich es dir erklärt habe erläuterst du mir, dass ich da vor einem Problem stehe. Toller Mehrwert - wo ich doch das Problem genau kannte.
Immerhin hatte ich bereits eine Lösungsvariante für diese Problemstellung, bevor ich es hier eröffnet habe.

Du hättest Berater werden sollen...
Die erzählen einem auch für teuer Geld, was man ohnehin schon wusste.
Und für noch mehr Geld lösen sie die Probleme, die man ohne sie nie gehabt hätte.

Nix für ungut und nimm es bitte nicht persönlich.
Meinen Respekt kannst du dann haben, wenn du mir eine weitere Lösungsvariante gibst.

[viertakter]

Dann such mal fleißig weiter... ein Berater stellt die Beratung gerne ein, wenn sie nicht gewünscht ist, nicht dass Du damit Recht hättest. Dein Respekt ist jedoch kein Motivator für mich - es hätte auch ein konstruktiver Austausch werden können, auch wenn er die offenbar von Dir erwarteten Ergebnisse noch nicht geliefert hat. Den brauchst Du ja aber auch nicht, da Du die Lösung schon hast.

Den spendiere ich Dir noch.

Ein Mann in einem Heissluftballon hat sich verirrt. Er geht tiefer und sichtet einen Mann am Boden. Er sinkt noch weiter ab und ruft:
"Entschuldigung, können Sie mir helfen ? Ich habe einem Freund versprochen, ihn vor einer Stunde zu treffen und ich weiss nicht wo ich bin."

Der Mann am Boden antwortet: "Sie sind in einem Heissluftballon in ungefähr 10 m Höhe über Grund. Sie befinden sich zwischen 40 und 41 Grad nördlicher Breite und zwischen 59 und 60 Grad westlicher Länge."

"Sie müssen Informatiker sein" sagt der Ballonfahrer.
"Bin ich", antwortet der Mann, "woher wussten sie das?"
"Nun," sagt der Ballonfahrer, "alles was sie mir sagten ist technisch korrekt, aber ich habe keine Ahnung, was ich mit ihren Informationen anfangen soll, und Fakt ist, dass ich immer noch nicht weiss, wo ich bin. Offen gesagt waren Sie keine grosse Hilfe. Sie haben höchstens meine Reise noch weiter verzögert."

Der Mann antwortet: "Sie müssen im Management tätig sein."
"Ja," antwortet der Ballonfahrer, "aber woher wussten sie das?"
"Nun," sagt der Mann, "sie wissen weder wo sie sind noch wohin sie fahren. Sie sind aufgrund einer grossen Menge heisser Luft in Ihre jetzige Position gekommen. Sie haben ein Versprechen gemacht, von dem Sie keine Ahnung haben wie sie es einhalten können und erwarten von den Leuten unter Ihnen, dass sie Ihre Probleme lösen. Tatsache ist, dass Sie in exakt der gleichen Lage sind wie vor unserem Treffen, aber jetzt bin irgendwie ich schuld!"