IPV64.net Adresse nicht mehr erreichbar "...:bad:c0de"

Hallo zusammen,

ich hatte heute testweise versucht CDN zu aktivieren, damit meine NextCloud hinter meiner IPV64.net Adresse auch in einem IPv4-Netz erreichbar ist. Das hat nicht geklappt, also wollte ich zurück bauen. Erst habe ich einen Zertifikat-Fehler (HTTPS) erhalten. Dann habe ich meinen Domain komplett gelöscht und neu angelegt. Er hat nun auch wieder die richtige IPv6-Adresse in der WebGUI von IPV64.net hinterlegt.

Ich kann meine NextCloud aber nicht erreichen. Ein Ping bringt mir:

C:\>nslookup mein-domain.ipv64.de fritz.box
Server:  *****.***
Address:  ***.***.***.***

Name:    mein-domain.ipv64.de
Address:  2a01:4f8:192:1326::bad:c0de

Wieso steht da statt meiner richtigen IPv6-Adresse dieses „…:bad:c0de“ und wie behebe ich den Fehler?

Vielen Dank!

Grüße
Mic.

Also ich kann deine NextCloud aber sehr wohl erreichen :wink:
Wenn du deren Domain schon anonymisieren willst dann bitte nicht nur halb.

(vom Verfasser gelöscht)

Die Frage, oder besser die Fragen, sind eher

Gut, an dem C:\> vor dem nslookup sehe ich, dass du eines dieser gruseligen Betriebssysteme aus Redmond benutzt. Daher habe ich keine Ahnung was die machen, wenn man mit einem nslookup zwei Domains durch Leerzeichen getrennt abfragt. Bei einem richtigen OS, wie Linux eines ist, erhält man dann einen ;; communications error statt einer sinnvollen Ausgabe.

Nachtrag: da du offenkundig in einem Netz hinter einer Fritte bist. informiere dich dringend auch mal über den DNS-Rebind-Schutz der Fritte. Der verhindert nämlich generell jeden Versuch, auf ein Gerät im Heimnetz über dessem Host- bzw. Domainnamen oder CNAME zuzugreifen. Will man das dennoch tun, sind zuvor Ausnahmen für den DNS-Rebind-Schutz einrichten.

Moin moin @The_eagle ,

heute früh ging es dann auf einmal wieder. Ich nehme an, dass ihr dieses „…:bad:c0de“ als Response aus einem bestimmten Grund eingeführt habt. Ich würde gern wissen, was ich gemacht habe, dass ich diese Response bekommen habe. Auch das Ausführen meines Update-Links brachte immer nur dieses „…:bad:c0de“.

Die FritzBox ist mein genereller lokaler DNS (der dann aber an meinen AdGuard Home DNS weiterleitet). Daher der Versuch nslookup über die FritzBox auszuführen (zu „erzwingen“), weil ich mir nicht sicher war, ob die falsche IPv6 mit „…:bad:c0de“ noch in irgendeinem DNS Cache drin stand.

Ja, das Anonymisieren meiner Adresse habe ich halbherzig gemacht. Man sollte solche Experimente nicht kurz vor Mitternacht machen. :man_facepalming: Ich habe es in meinem Post nun anonymisiert. Machts dir was aus, das auch in deinem Posting zu anonymisieren. :folded_hands:

Danke für den Hinweis mit dem DNS-Rebind-Schutz. Ich meine, ich habe mir das am Anfang mal angeschaut und er ist im aktuellen FritzOS standardmäßig immer aktiv. Ein Zugriff über IPV64.net-Adresse (also IPv6) ist ausreichend für mich. Für alles andere kann ich mein VPN zur FritzBox nutzen. Andere Leute sollen da nicht dran rum fummeln (daher keine Ausnahmen). Ich schaue es mir aber nochmal an. Sicher ist sicher.

Nebenfrage: Wenn man IPV64.net CDN Portforwarding nutzen möchte (damit die NextCloud auch von einem IPv4-Netz erreichbar ist), braucht man zwingend auch den IPV64.net Reverse Proxy (oder geht es auch ohne). Ich hatte ja das Problem, dass mein Let’s Encrypt Zertifikat, welches mein Docker Caddy (Reverse Proxy) aushandelt, nicht mehr gültig war als ich alles in CDN Reverse Proxy und CDN Portforwarding auf IPV64.net.

Vielen Dank für deine, für eure Unterstützung und schon mal ein schönes Wochenende. :tropical_drink:

Grüße
Mic.

Nachtrag zum FritzBox Rebind Schutz: Ja, er ist jetzt immer aktiv und man kann ihn auch nicht komplett abstellen, nur Ausnahmen definieren.

Korrekt, siehe oben.

Entweder per Reverse Proxy oder VPN, das per IPv4 erreichbar ist. Ein Wireguard VPN zu deiner Fritte kannst du auch sehr einfach per IPv4 mittels CDN Portmapper erreichbar machen. Dazu ist dann in den Configs der Clients nur der verwendete Port anzupassen, an den Port, den dir der CDN Portmapper zugewiesen hat. Also der Original-Port ist meinetwegen UDP 51820, der CDN Portmapper mappt den auf UDP 54321. Dann müsste eben in den Configs der Clients 51820 geändert werden in 54321.

Kleine Ergänzung dazu. Bei nslookup kann man optional als 2. Parameter einen Nameserver mitgeben, den man befragen will, im obigen Fall also fritz.box. Das hat nichts mit einer 2. Domain zu tun und ist unter Linux ebenso.

Übrigens: Ich habe gerade festgestellt, dass der DNS-Server von IPv64 wohl immer diese lustige Adresse 2a01:4f8:192:1326::bad:c0de und 144.76.85.238 (=mail.schroederdennis.de) liefert, wenn er etwas nicht kennt. Was hat sich Dennis denn da schon wieder ausgedacht :thinking:

Entweder per Reverse Proxy oder VPN, das per IPv4 erreichbar ist.
Der Reverse Proxy von IPV54.net oder mein eigener Reverse Proxy im Docker Caddy (mit Caddyfile)?

Das VPN der FritzBox wollte ich erst einmal noch nicht erreichbar machen. Im erste Schritt reicht mir eine IPv4-Erreichbarkein meiner NextCloud. Und die ist in IPv6 mit HTTPS (Port 443) eingebunden.

Aktiviere ich (zusätzlich) Reverse Proxy und Portmapper in IPV64.net, bekomme ich einen Zertifikats-Fehler, wenn ich versuche die Webseite aufzurufen.

Aber einen Nameserver sollte man eigentlich niemals mittels FQDN angeben. Schließlich benötigt man zum Auflösen des FQDN einen Nameserver. Daher gibt man eigentlich überall den Nameserver über dessen IP-Adressen an. Auch ein DHCP-Server übermittelt den Clients die IP-Adressen der oder des Nameservers im LAN und nie den FQDN.

Ganz davon abgesehen:
Auch eine Fritte cached Domain-Namen. Will man also sichergehen, dass in keinem lokalen DNS Cache noch eine falsche IP drin ist sollte man das etwa so

nslookup mein-domain.ipv64.de 8.8.8.8

oder

nslookup mein-domain.ipv64.de 9.9.9.9

testen.

Kann denn jetzt jemand das Rätsel lösen, was „schiefgehen muss“, damit man den „bad:c0de“ angezeigt bekommt? Hatte ich da mit meinen Versuchen mit CDN etwas verbogen? Oder lag es daran, dass ich meinen Domain gelöscht und gleich wieder neu angelegt hatte? Oder? Oder? Oder?

Hallo zusammen,

nur mal kurz als Erfolgsmeldung, ich habe den CDN Portmapper für IPv4 heute erfolgreich zum Laufen gebracht. Es gab keine Zertifikatsfehler und auch keinen …:bad:c0de mehr. Den CDN Proxy habe ich nur für IPv4 aktiviert, da der direkte DynDNS-Zugang für IPv6 mehr als gut genug funktioniert.

Entweder gab es bei IPV64.net am späten Donnerstagabend tatsächlich eine technische Störung oder ich habe das System vielleicht beim Testen und Klicken aus dem Gleichgewicht gebracht. Ich würde nun sagen, die obersten drei Regeln beim Einrichten des CDN auf IPV64.net sind:

  1. Geduld
  2. Geduld
  3. Geduld

So lange sich der „Warten-Kreis“ dreht, sollte man nichts anklicken, nichts aktualisieren und nirgends dran rumfummeln. Dann funktioniert es wohl auch.

Da mein Open Media Vault 7 kein nslookup hat, nutze ich weiterhin das nslookup auf meinem Windows-PC – das müsst ihr jetzt einfach ertragen. :rofl:

C:\>nslookup mein-domain.ipv64.de 9.9.9.9
Server:  dns9.quad9.net
Address:  9.9.9.9

Name:    mein-domain.ipv64.de
Addresses: 1234:5678:90ab:cd12:3456:7890:abcd
          12.34.567.890

Ich bin zwar noch immer neugierig, was den …:bad_:c0de verursacht hat aber es ist erst einmal kein Blocker mehr.

Die nächsten Tage schaue ich mal, wie stabil und dauerhaft das ganze nun läuft.

Danke und Grüße
Mic.

PS.: IPV64.net ist echt eine coole Sache. Danke, dass ihr sowas auf die Beine gestellt habt. :+1:t2:

12.34.567.890 kann aber nicht sein, da hast du etwas übertrieben anonymisiert :wink:

1 „Gefällt mir“

Ganz fehlerfrei scheint das CDN Port-Forwarding (für nur IPv4) aber noch nicht zu sein. Es kommt immer wieder vor, dass ich unter meiner normalen Domain-Adresse (ohne Portangabe, für IPv6) folgende Seite angezeigt bekomme:

Bestätige ich das Risiko drängt sich dann eine CDN-Info-Seite in den Vordergrund:

Einzige Abhilfe ist, das Gerät vom W-LAN zu trennen und neu zu verbinden. Danach geht es wieder.

Hinweis: Ich habe nebenbei heute auch Healthchecks in meinem Profil auf IPV64.net aktiviert. Damit kann es aber nichts zutun haben…?