Ich bekomme meinen Heimserver nicht sauber ins Internet. Irgendwo ist noch ein Verständnissproblem oder eine Fehleinstellung.
Folgende Ausgangslage:
- Glasfaser über Komflat mit CG-NAT an FritzBox7590 (V8.03)
- DynDNS update über das Prefix-Script auf IPv6 Adresse der Fritte, IPv4 wird ignoriert
- CDN nur IPv4 umsetzen, Reverse Proxy: Level 2 → Level 2
- Zuhause Reverse Proxy über Zoraxy, Portforwarding in Fritte gesetzt
Wenn ich von einem Anschluss aus zugreife der sowohl IPv4 als auch IPv6 hat, dann funktioniert alles wunderbar.
Greife ich von einem Anschluss aus zu der nur IPv4 hat, dann lande ich auf der IPv64.net CDN Service Seite.
Wenn ich zusätzlich ein Portforwarding in IPv64 setze und diesen Port mit angebe, dann klappt es auch mit IPv4 only Clients.
Ist es von IPv4 only Clients aus nicht möglich ohne diesen zusätzlichen Port zurechtzukommen?
Also nutzt du einen doppelten Reverse Proxy!?
- den Reverse Proxy von ipv64,net und
- bei dir Zuhause den Zoraxy Reverse Proxy
Wozu soll das gut sein? Erschließt sich mir nicht und bedeutet doppelte Fehlerquelle. Umgehe zunächst den Zoraxy Reverse Proxy und leite die Anfragen via CDN Reverse Proxy direkt an den Webserver weiter, der im Endeffekt erreicht werden soll.
Klappt das dann weißt du dass das CDN richtig konfiguriert ist.
Den Zoraxy habe ich, weil ich zuhause mehrere Dienste/Programme habe die ich ansprechen möchte. Das geht nicht einfach auf einen Webserver.
Mag sein, dass es dafür bessere Lösungen gibt. Ich bin offen für Vorschläge.
Habe jetzt mal testweise eine neue Domain angelegt und über den CDN Reverse Proxy direkt auf einen Dienst geroutet.
Selbes Bild. Über einen IPv4 only Client bekomme ich keinen Zugang. Allerdings lande ich jetzt nicht auf der CDN Seite sondern bekomme „Die Website ist nicht erreichbar“ mit dem Zusatz „DNS_PROBE_FINISHED_NXDOMAIN“.
Da du CG-NAT hast, ist die bessere Lösung faktisch default-mäßig in deiner Fritte eingebaut. Die bessere Lösung ist:
- Nutze statt IPv4 einfach IPv6
- damit entfällt dann auch das Problem, dass du via IPv4 (wegen NAT) nur einmal die Ports 80 und 443 an Server im LAN weiterleiten kannst
- IPv6 braucht schlicht kein NAT.
Solltest du dann doch mal aus einem Netz ohne IPv6 (Hotel, Gastronomie, etc.) auf diese Server in deinem LAN zugreifen müssen, kannst du dafür dann Wireguard nutzen. Um Wireguard per IPv4 nutzen zu können muss nur der Portmapper im CDN konfiguriert werden. Ein Reverse Proxy ist überflüssig wie ein Kropf.
Danke für den Vorschlag und vermutlich ist er für 99% auch richtig.
Aber, auf meinem Firmenrechner (darf und wird auch privat genutzt) ist nur IPv4 verfügbar und Wireguard (oder ein anderer VPN) kann/darf nicht genutzt werden.
Daher bin ich scheinbar auf eine Umsetzung von IPv4 auf IPv6 angewiesen und ein nachgelagerter Reverse Proxy sollte zumindest die einfachste Lösung sein.
Vielleicht findet sich ja doch noch jemand der Unterstützen kann.
Ich habe jetzt testweise eine neue DynDNS Adresse angelegt. Die verweist (erstmal) fest mittels IPv6-Adresse auf einen Dienst in meinem Netzwerk. Von einem IPv6-Gerät kann ich den Dienst auch erreichen. Von IPv4 natürlich nicht.
Jetzt gehe ich in den CDN-Service und aktiviere für diese DynDNS „Enable only IPv4 Proxy“. Sonst nichts weiter. Kein Reverse Proxy, kein Port Mapper.
Vom IPv6-Gerät geht es immer noch, vom IPv4-Gerät bekomme ich jetzt die " IPv64.net CDN Service" Seite mit Fehler 50x.
Habe ich einen Gedankenfehler, fehlt mir eine Freigabe? Jemand eine Idee?
Ja, hast du. Der Denkfehler ist der hier:
Eins von beidem musst du natürlich konfigurieren und zwar abhängig davon, was du da für einen Dienst in deinem Netzwerk erreichen willst,
PS: vielleicht solltest du weniger trinken. Bestimmte Getränke schaden der Denkleistung 
Hab das gleiche Problem/Frage.
Ich habe den Proxy so interpretiert, dass er IPv4 auf IPv6 mapped. Ein Proxy leitet ja in der Regel den Traffic von a nach b durch, hier geht IPv4 an CDN rein und es kommt IPv6 an meine IP auf den entsprechenden Port raus.
Dann wären Portmapper und reverse proxy zusätzliche, additive Features.
So wie du es beschreibst, macht dass Setting etwas anderes, speziell weniger. Scheinbar macht es nur das Mapping auf die CDN IPs.
IMHO ist der Name der Option dann aber „schwierig“ und ich würde dann ein Hinweis in der UI erwarten, dass das so nicht funktionieren kann.
Es ist doch so. Der
- Reverse Proxy wirkt nur bei den TCP-Ports 80 und 443, also http und https, während der
- Port Mapper fürs Mapping auf alle anderen Ports (TCP und UDP) verwendet werden kann.
Da muss man sich also schon mal entscheiden, was man braucht / haben will und das dann entsprechend konfigurieren
Meine Erwartung ist, das bei setzten des Schalters ein
curl - v - 4 https://… als auch das gleich mit - 6 funktioniert.
Bei mir funktioniert es in den letzten zwei Wochen nur mit - 6, bei - 4 bekomme ich das genannte Fehlerbild.
Sollte beides gehen, ist aber ggf. nicht stabil oder sollte das nicht gehen.
@Framstag CDN stellt dir doch erst einmal nur eine IPv4-Adresse zur Verfügung, obwohl du nur IPv6 hast (wegen DS-Lite oder CG-NAT). ABER:
- diese IPv4-Adresse steht dir NICHT exklusiv zur Verfügung. Du teilst sie dir mit anderen.
Damit das geht braucht es entweder
- einen Portmapper, der dir z.B. exklusiv den Port UDP 54321 zuteikt und diesen dann auf UDP 51820 (Wireguard) mappt oder aber
- den Reverse Proxy für TCP 80/443
So generell wie du CDN interpretierst würde es nur klappen können, wenn du eine exklusive IOv4-Adresse hättest, das also selbst z.B. auf eine angemieteten V-Server mit eigener IPv4-Adresse alles eigenhändig konfigurieren würdest.
OK, Verstanden. Danke.
Hab den Reverse Proxy zugeschaltet, allerdings ohne Erfolg.
Ich denke, der Fehler liegt schon vorher oder tiefer.
Ich kann die DynDNS über IPv6 nur erreichen wenn ich http:// davor setze. Mit https:// funktioniert es nicht.
Sowohl Port 80 als auch 443 sind in der Fritte freigeschaltet für den Dienst.
CDN zeigt mir wohl nur das Problem auf, lösen muss ich das woanders.
Was erhälst du denn als Ausgabe von
curl -v -6 https://deine.domain.de
ohne aktives CDN und Reverse Proxy?
Nur mal schnell angemerkt:
da scheint bei dir alles zu fehlen, was mit den SSL Zertifikaten zu tun hat. Auch TLS handshake seh ich bei dem was du gesendet hast nicht. Stattdessen einen TLS alert. Da stimmt offenbar so einiges nicht in deiner SSL-Konfiguration.
Kann das damit zusammenhängen das es in einem LXC unter Proxmox läuft?
Ob bare Metal oder VM sollte da keinen Einfluss haben. Meine Server sind auch alle VM’s. Nur nicht LXC unter Proxmox sondern auf DebianHost mit QEMU/KVM
Von allein bekommste keine Zertifikate. Muss man schon konfigurieren und z.B. auch bei Let’s Encrypt anfordern und regelmäßíg erneuern.
Ich habe da einen Verdacht. Ich probiere morgen Abend mal was aus.
So, hat etwas länger gedauert als gedacht.
curl -v -6 https://deine.domain.de
gibt jetzt gültige Daten zurück. Sowohl ohne CDN als auch mit „IPv4 only“ CDN und Reverse Proxy.
Zumindest vom IPv6 Rechner.
Vom IPv4 only Rechner lande ich immer noch auf der „IPv64.net CDN Service“ Seite mit Fehler 50x.
Wenn ich im CDN auf „Full Proxy“ stelle, dann geht es auch mit IPv6 nicht mehr.
Das
curl -v -6 https://deine.domain.de
am IPv4 only Rechner nicht funktionieren kann, ist dir hoffentlich bewusst!?