Fritzbox 7590 MyFritz! Funktioniert aber IPv4 Zugang nicht. Telekom MagentaZuhause M

[Teasi]

Liebe Heimnetzwerk-Community,

ich bin noch sehr neu in der Community. Ich hab leider keinen ähnlichen Forumeintrag gesehen und hoffe, dass ich auch nicht übersehen habe.

Ich kann meinen Homeserver per MyFritz! erreichen aber nicht per IPv4. Ich haben einen DSL Telekom MagentaZuhause M Vertrag.

Ich lasse seit 2 Monat über einen Server in meinem Heimnetz eine Matrix Instanz laufen und hab bis jetzt die MyFritz! Addresse ohne Probleme genutzt.

Nun habe ich mir endlich meine erste eigene Domain gekauft, DDNS eingerichtet und siehe da aufm Server erschienen auch die IPv4, die mir bei meiner Fritzbox eingetragen ist.

Mein Matrix Instanz läuft über Port 8448 wenn ich meine MyFritz! Addresse aufrufe: https://????.myfritz.net:8448 klappt alles. Wenn ich aber die IPv4 aus meinem Router nehme (selbe wie durch https://whatismyipaddress.com/ ) https://???.???.???.???:8448 kriege ich nur einen 404 Error.

Ist das eine fehlende Einstellung auf meiner Fritzbox oder irgendwas, was Telekom nicht zu lässt?

Vielen Grüße und danke für eure Hilfe
Teasi

 

[blurrrr]

Moin,

vermutlich hast Du Deine Matrix-Instanz auf den entsprechenden FQDN (....myfritz.net) konfiguriert und somit wird auch "nur" darauf reagiert. Ansonsten scheint es auch recht schlecht auszusehen, wenn man den Server einfach umbenennen möchte:

Why can't I rename my homeserver?
Currently, the homeserver name is assumed never to change.

(Quelle: https://matrix.org/docs/older/faq/)

Mit der Fritz!Box hat das jedenfalls nichts zu tun, das ist ein DNS-Problem bzw. konkreter ein Matrix-Konfigurationsproblem. Wenn sich der hinterlegte FQDN nicht ändern lässt, sieht es ganz danach aus, als dürftest Du alles neu aufsetzen mit dem neuen gewünschten FQDN.

 

[Teasi]

Moin,

vermutlich hast Du Deine Matrix-Instanz auf den entsprechenden FQDN (....myfritz.net) konfiguriert und somit wird auch "nur" darauf reagiert. Ansonsten scheint es auch recht schlecht auszusehen, wenn man den Server einfach umbenennen möchte:

(Quelle: https://matrix.org/docs/older/faq/)

Mit der Fritz!Box hat das jedenfalls nichts zu tun, das ist ein DNS-Problem bzw. konkreter ein Matrix-Konfigurationsproblem. Wenn sich der hinterlegte FQDN nicht ändern lässt, sieht es ganz danach aus, als dürftest Du alles neu aufsetzen mit dem neuen gewünschten FQDN.

Moin blurrr,

Vielen Dank für deine Recherche!! Da ich auch neue Hardware gekauft habt, werde ich sowieso alles neu aufsetzen, das ist also kein Problem. Ach ich freu mich! ^-^

Ich wollte nur irgendwie testen, ob alles mit dem DDNS geklappt, weil ich sowas noch nie gemacht habe, und habe meine Matrix Instanz genutzt. Das war ja ein guter Test...

Kleine Frage noch: Wie würde ich denn richtig testen, ob ich auch wirklich in mein Heimnetz reinkomme? Weil z.b. die klassische MyFritz Anmeldeseite unter dem ?????.myfritz.net ist auch nicht aufgetaucht.

Liebe Grüße
Teasi

 

[blurrrr]

Also grundsätzlich ist DNS ja auch nur eine Art "Wegweiser" in Form von FQDN -> Ziel-IP.

Bei einem normalen A-Record wäre es halt:

FQDN -> A-Record -> Ziel-IP

Bedeutet: FQDN = Ziel-IP. Bei Dir würde sich die Nutzung von CNAME-Records anbieten in Form von:

FQDN -> CNAME-Record -> MyFritz-Adresse -> Ziel-IP

Da kommt schlussendlich das gleiche bei rum: -> FQDN = Ziel-IP

Das war ja ein guter Test...

Naja, so schlecht ist er nicht, denn der Matrix-Server liefert nur den richtigen Inhalt bei Ansprache des richtigen (hinterlegten) FQDN aus. 404. 404 bedeutet, dass der Server die angeforderte Ressource nicht gefunden hat.

Während DNS nur ein Wegweiser ist, gibt es noch Inhalte in den Paket-Headern (im Paket-Kopfteil). Als Beispiel nehmen wir einfach mal einen Webserver. Ein Webserver kann mit mehreren FQDNs umgehen. Somit hätte man z.B. im DNS:

www.domain1.tld = Webserver-IP
www.domain2.tld = Webserver-IP

Es zeigen also beide FQDNs auf den gleichen Server. Dieser ist aber nun in der Lage anhand des HTTP-Headers zu entscheiden, an welche Domain die jeweilige Anfrage gerichtet ist. Das sind dann die sogenannten vhosts. Das könnte auf dem Server z.B. dann so aussehen:

www.domain1.tld = /webverzeichnis1/
www.domain2.tld = /webverzeichnis2/

Obwohl nun - vom DNS her - beide FQDNs auf die gleiche IP zeigen, unterscheidet der Webserver anhand der vhosts-Einträge, welchen Inhalt (aus den entsprechend hinterlegten Verzeichnissen) er an den anfragenden Client ausgibt. Ruft man nun www.domain1.tld im Browser auf, wird der Inhalt aus webverzeichnis1 ausgegeben. Ruft man aber www.domain2.tld auf, wird der Inhalt aus dem Verzeichnis webverzeichnis2 ausgegeben.

Würde DNS-technisch jetzt noch www.domain3.tld auf die Webserver-IP zeigen, der Webserver weiss aber nichts davon, gäbe es entsprechend die Fehlermeldung 404 zurück, da der Webserver diesen FQDN nicht kennt.

Wichtig ist halt, dass alles zusammen passt. Heisst in erster Linie müssen die DNS-Records korrekt konfiguriert sein (das kannst Du bei Dir mit MyFritz dann im DNS aber über CNAME-Records regeln). Dann müssen die Portweiterleitungen korrekt eingerichtet sein und logischerweise müssen auch die Ziele bei Dir im Heimnetz entsprechend konfiguriert sein.

Wie würde ich denn richtig testen, ob ich auch wirklich in mein Heimnetz reinkomme

Das kommt darauf an, welche Mittel Dir zur Verfügung stehen.

Da ich auch neue Hardware gekauft habt

Was genau hast Du denn nun bzw. was hast Du konkret vor?

 

[Teasi]

Also grundsätzlich ist DNS ja auch nur eine Art "Wegweiser" in Form von FQDN -> Ziel-IP.

Bei einem normalen A-Record wäre es halt:

FQDN -> A-Record -> Ziel-IP

Bedeutet: FQDN = Ziel-IP. Bei Dir würde sich die Nutzung von CNAME-Records anbieten in Form von:

FQDN -> CNAME-Record -> MyFritz-Adresse -> Ziel-IP

Da kommt schlussendlich das gleiche bei rum: -> FQDN = Ziel-IP

Also aktuell habe ich (soweit ich das richtig überblicke) ein A-Record bei IONOS. Wieso würde ein Cname-Record sich anbieten? Ich hatte gelesen, dass da dann so https SSL certificate Geschichten nerviger sein könnten und wenn es das das gleiche ist, würde ich doch dann lieber beim A Record bleiben, oder?

Naja, so schlecht ist er nicht, denn der Matrix-Server liefert nur den richtigen Inhalt bei Ansprache des richtigen (hinterlegten) FQDN aus. 404. 404 bedeutet, dass der Server die angeforderte Ressource nicht gefunden hat.

Während DNS nur ein Wegweiser ist, gibt es noch Inhalte in den Paket-Headern (im Paket-Kopfteil). Als Beispiel nehmen wir einfach mal einen Webserver. Ein Webserver kann mit mehreren FQDNs umgehen. Somit hätte man z.B. im DNS:

www.domain1.tld = Webserver-IP
www.domain2.tld = Webserver-IP

Es zeigen also beide FQDNs auf den gleichen Server. Dieser ist aber nun in der Lage anhand des HTTP-Headers zu entscheiden, an welche Domain die jeweilige Anfrage gerichtet ist. Das sind dann die sogenannten vhosts. Das könnte auf dem Server z.B. dann so aussehen:

www.domain1.tld = /webverzeichnis1/
www.domain2.tld = /webverzeichnis2/

Obwohl nun - vom DNS her - beide FQDNs auf die gleiche IP zeigen, unterscheidet der Webserver anhand der vhosts-Einträge, welchen Inhalt (aus den entsprechend hinterlegten Verzeichnissen) er an den anfragenden Client ausgibt. Ruft man nun www.domain1.tld im Browser auf, wird der Inhalt aus webverzeichnis1 ausgegeben. Ruft man aber www.domain2.tld auf, wird der Inhalt aus dem Verzeichnis webverzeichnis2 ausgegeben.

Würde DNS-technisch jetzt noch www.domain3.tld auf die Webserver-IP zeigen, der Webserver weiss aber nichts davon, gäbe es entsprechend die Fehlermeldung 404 zurück, da der Webserver diesen FQDN nicht kennt.

Verstehe, das bedeutet, wenn ich mein neue Domain /ip Addresse direkt nutze, dann steht das im http/https Header und mein Matrix Server ignoriert es, da Matrix nur auf den .myfritz.net domain konfiguriert hört. Das macht ja mega Sinn, danke für die super ausführliche und verständliche Erklärung(!!)

Wichtig ist halt, dass alles zusammen passt. Heisst in erster Linie müssen die DNS-Records korrekt konfiguriert sein (das kannst Du bei Dir mit MyFritz dann im DNS aber über CNAME-Records regeln). Dann müssen die Portweiterleitungen korrekt eingerichtet sein und logischerweise müssen auch die Ziele bei Dir im Heimnetz entsprechend konfiguriert sein.


Das kommt darauf an, welche Mittel Dir zur Verfügung stehen.

Also ich hab vollen Zugriff auf den Router und den Server

Was genau hast Du denn nun bzw. was hast Du konkret vor?

Ich habe jetzt 2 Monate Matrix getestet für Gruppen die über Singal, WhatsApp und Telegram gebridged sind. Jetzt ist zeitgleich mein ProtonCloud Speicher voll gelaufen und dann dachte ich mi: Hey ich nutze seit Ewigkeiten auch Nextcloud, lass das doch selbst hosten!

Dafür hab ich mir jetzt einen Mini PC mit 2x2tb nvme WD Red gekauft, wo ich proxmox laufen lasse mit ZFS mirror und lokalem backup. Wenn der läuft, kommt auch noch ne off-site backup in form eines Raspberry Pi dazu

Der Plan war:
Matrix, Nextcloud, Reverse Proxy und einen Mail Client für Trash Mails über meine Domain von außen zugänglich zu machen. Meine Hauptmail Addresse lasse ich über IONOS laufen, weil ich mit meinem Server keine high availability garantieren kann :/ Der Reverse Proxy ist dafür, um Subdomains zu haben wie z.b. nextcloud.domain.net und matrix.domain.net

Für alles andere nutze ich ein VPN, wie z.b. für Paperless-NGX. Am liebsten hätte ich den nextcloud mit meinen Daten auch nur im lokal im Heimnetzwerk, aber ich hab etwas Angst, dass manche Synchronisation dann schiefgehen/nervig viele Benachrichtigungen produzieren, da ich auch die CalDav Feature sehr viel nutze.

Vielleicht mach ich noch ne zweite nextcloud Instanz, die nur im Heimnetzwerk funktioniert für Dateien und lasse nur die CalDav Geschichte öffentlich laufen

Gib gern deinen Senf dazu, falls sich irgendwas nach ganz groben Unsinn anhört. Das mit dem VPN hab ich vorallem, damit ich nicht so viel exposen muss. Da ich keine IT Expert*in bin, geh ich da lieber nochmal auf Nummer sicher

Liebe Grüße
Teasi

 

[blurrrr]

Also aktuell habe ich (soweit ich das richtig überblicke) ein A-Record bei IONOS. Wieso würde ein Cname-Record sich anbieten? Ich hatte gelesen, dass da dann so https SSL certificate Geschichten nerviger sein könnten und wenn es das das gleiche ist, würde ich doch dann lieber beim A Record bleiben, oder?

Nein, was Du gelesen hast, hast Du evtl. falsch interpretiert. DNS ist wie gesagt nur ein "Wegweiser". Im z.B. HTTP-Header steht dann nochmal drin, welchen FQDN Du eigentlich angesprochen hast. Es sind halt 2 Paar Schuhe: Einmal DNS als Wegweiser und einmal der Paket-Header mit dem angesprochenen FQDN.

das bedeutet, wenn ich mein neue Domain /ip Addresse direkt nutze, dann steht das im http/https Header und mein Matrix Server ignoriert es, da Matrix nur auf den .myfritz.net domain konfiguriert hört.

Korrekt

Matrix, Nextcloud, Reverse Proxy und einen Mail Client für Trash Mails über meine Domain von außen zugänglich zu machen.

Klar, kannste machen. Du musst nur darauf achten, dass Dinge, welche hinter dem Reverse-Proxy laufen auch wissen, dass sie hinter einem Reverse-Proxy laufen. Dazu gibt es etwas namens "x-forwarded-for". Da wirst Du aber in den entsprechenden Dokumentationen (Matrix, Nextcloud, etc.) etwas zu finden. In heimischen Netzen ist es derweil auch üblich, dass die SSL-Terminierung auf dem Reverse-Proxy liegt. Heisst, dass der Reverse-Proxy die Zertifikate anfordert und für die Verschlüsselung sorgt. In der Regel halt nur zwischen Client und Reverse-Proxy. Aus Gründen der Einfachheit bleibt dann die Verbindung zwischen Reverse-Proxy und Zielserver oftmals unverschlüsselt. Das der Zielserver weiss, dass er hinter einem Reverse-Proxy sitzt ist extrem wichtig, denn die Kommunikation läuft nicht einfach "durch" den Reverse-Proxy (wie z.B. bei einer Portweiterleitung), sondern der Client spricht "nur" mit dem Reverse-Proxy und dieser wiederum spricht mit dem Zielserver. Das "Problem" hierbei ist, dass wenn z.B. eine IP am Zielserver aufgrund von zuvielen fehlgeschlagenen Anmeldungen gesperrt wird, wird es die des Reverse-Proxy sein, denn der spricht ja mit dem Zielserver. Wenn der x-forwarded-for-Part (wo die richtige IP des anfragenden Clients drin steht) vom Zielserver korrekt ausgewertet wird, wird eben die Client-IP gesperrt und nicht die, des Reverse-Proxy.

Für alles andere nutze ich ein VPN

Der Reverse Proxy ist dafür, um Subdomains zu haben wie z.b. nextcloud.domain.net und matrix.domain.net

Kann man so machen. Kannst auch hingehen und eine Subdomain mit Wildcard-Record für Deine Sachen Zuhause anlegen (z.B. "*.home.domain.tld"). Somit wird <egal was>.home.domain.tld direkt an Deine MyFritz-Adresse und somit an Deine WAN-IP geschickt. Hat den Nachteil (muss man ja auch mal erwähnen), dass auch z.B. diesisteintest.home.domain.tld bei Dir aufschlägt (wenn der Reverse-Proxy sowas nicht kennt... Ergebnis kennst Du ja bereits schon ), aber den Vorteil, dass Du Dich nicht weiter um die Subdomains kümmern musst, sondern Dich nur noch um die internen Dinge kümmern musst (Reverse-Proxy muss auf den FQDN hören und ggf. auch das Ziel dahinter, im Falle von Nextcloud z.B. die Konfiguration bzgl. der trusted_domains).

Das mit dem VPN hab ich vorallem, damit ich nicht so viel exposen muss.

Alles gut und richtig Was die zweite NC-Instanz angeht, so wäre es ggf. eine Überlegung wert, ob Du evtl. irgendwie ein VPN-on-Demand umgesetzt bekommst (IPSec), oder alternativ einfach Wireguard nutzt (da gab es - glaube ich - eine always-on-Option bei den Client-Einstellungen (z.B. für das Smartphone)).

Dafür hab ich mir jetzt einen Mini PC mit 2x2tb nvme WD Red gekauft, wo ich proxmox laufen lasse mit ZFS mirror und lokalem backup. Wenn der läuft, kommt auch noch ne off-site backup in form eines Raspberry Pi dazu

Ist sicherlich nicht verkehrt