7690 und IPV6 - Externer/Globaler Zugriff auf interne Server

[HartCh]

Ich bin kaum der einzige mit dieser Problematik:

• Mein Setup: eigene Domain ("meineDomain"), fritzbox 7690, nginx server in proxmox lxc.
• Mein Fernziel: Interne Server über IPV6 ansprechen.
• Mein Nahziel: Schrittweiser Übergang von IPv4 zu IPV6.

Für meine Domain habe ich einen cname angelegt, der über die myfritz Adresse meinen nginx Server ansprechen kann, der wiederum auf einen Server, nennen wir ihn mal 'server1', verweist. Das funktioniert, ich kann ihn über server1.meineDomain.de erreichen.

Nun möchte ich einen weiteren Server, 'server2', über eine ipv6 Adresse ansprechen. Hierzu habe ich in meiner Domain einen aaaa Record angelegt, der auf die ipv6 Adresse meines nginx verweist. Die Adresse ist sowas wie 2a00:12d0:...

Ich gehe mal davon aus, dass in der 7690 IPV6 in den Zugangsdaten - IPV6 aktiviert sein muss. WENN ich das aber mache, kommt es spontan zu Problemen bei server1. server2 ist nach wie vor nicht erreichbar. Letzteres wird vermutlich an unvollständiger Konfiguration in der Box liegen. Aber das ist dann der nächste Schritt.

Wie kann ich hier am besten feststellen, wo es klemmt?

 

[Barungar]

Dein Server2 hat also eine IPv6-Adresse. Wie kann er die haben, wenn IPv6 nicht in Deiner FritzBox aktiv ist?
Hast Du noch einen zweiten Router mit Internet-Zugang in Deinem Netzwerk?
Oder läuft alles über die FritzBox?

Bitte mach im Zweifel einen Screenshot von der FritzBox-Seite "Internet / Online-Monitor / Verbindungsdetails"... die letzten Stellen der IP-Adressen darfst/solltest (bis zu 3/4) Du natürlich anonymisieren.

 

[HartCh]

Nein. Soweit bin ich ja noch gar nicht. Vergessen wir für den Augenblick Server2. Wenn ich IPV6 in der Box aktiviere, egal ob es bereits einen Server2 gibt, oder nicht, ist server1 nicht mehr erreichbar. Wenn das geht, kommen wir zu server2.

 

[Barungar]

Mach doch bitte erst einmal den Screenshot... Worauf ich mit meiner Eingangsfrage hinaus wollte... wahrscheinlich hat Dein Server2 einen IPv6, weil es schon aktiv ist auf der FritzBox.

 

[Fusion]

Dann solltest du beschreiben was du wo aktivierst in der Fritzbox, damit man mutmaßen kann wo ein Fehler liegen könnte.

Nachdem ipv6 sauber aktiv ist intern/extern.

Wenn du dann über den nginx proxy Geräte erreichen willst wäre die erste Aufgabe dass ipv4/v6 Portweiterleitung und Portfreigabe auf den proxy steht mit korrekter ipv4 und ipv6 host identifier.

Danach kann man dann DNS angehen.

 

[HartCh]

Sorry, dass ich mich so verworren ausdrücke.
Also noch mal anders:
Schritt 1:
Ich habe bei IONOS eine Domain registriert. In dieser Domain habe ich unter DNS einen cname record angelegt, der ungefähr so aussieht:
server1.meineDomain.de -> asdfsdfasdfaefdw.myfritz.net
In der Box ist IPV6 NICHT aktiv.
Fazit: server1.meineDomain.de funktioniert.

Schritt 2;
Ich lasse alles, wie es ist, ich aktiviere lediglich IPV6 in der Box. (vergesst server2...)
Fazit: server1.meineDomain.de funktioniert nicht mehr.

Das muss doch erst mal funktionieren. Oder?

 

[Barungar]

Ich habe Dich zweimal um einen Screenshot gebeten. Du möchtest meine Hilfe scheinbar nicht. Wünsche noch viel Erfolg.

 

[HartCh]

Vielleicht kann mir ja jemand anderes einen Tipp geben.

@Barungar : Der Screenschot bezog sich doch auf server2. Der spielt aber noch gar keine Rolle. Ich habe ihn zwar prophylaktisch bei IONIS bereits angelegt, den rufe ich aber (zunächst) gar nicht auf. Ich aktiviere lediglich IPV6 In den Zugangsdaten meinen Box. Wolltest Du hierzu einen Screenshot?

 

[Fusion]

Es gibt mehrere Stellen mit IPv6. Die genannte ist eine davon für die Verbindung nach draußen.
Die sieht für sich ok aus.
Dann die Frage, ob im Online Monitor oder der Übersicht dann öffentliche IPs für beide Protokolle vorhanden sind.

Dann gibt es noch IPv6 unter Heimnetz Netzwerkeinstellungen.

Nach Aktivierung der IPv6 kann vieles schief gehen. Angefangen dass eine "falsche" IPv6 im dyndns liegt auf die ein client zugreifen will, oder noch keine ipv6 Freigabe dazu existiert, oder eine mit falscher Host ID.

Daher wäre vielleicht der erste Schritt den nginx proxy sauber per ipv4 und ipv6 zu erreichen.

 

[HartCh]

Ich habe kürzlich von Kabel auf Glasfaser umgerüstet.
Dass die Problematik komplex ist, ist klar: angefangen damit, dass der Cache des Browsers einen permanent anlügt, bis dahin, dass erst ein Anruf beim Glasfaser-Provider, inspiriert durch einen Hinweis in irgendeinem Forum, nach vielen Stunden/wenigen Tagen suchen und destruktivem Probieren, ans Licht brachte, dass IPV4 von außen, also die ganze Portweiterleitung, erst aktiviert werden muss....
Sowas weiß man entweder, oder man kommt nicht drauf. - Da fällt es schwer, ruhig zu bleiben.
Meine Hoffnung ist eigentlich, dass irgendwer so etwas schon mal durchlitten hat, und mir mit einer Strategie zur Eingrenzung und dann Lösung helfen kann. Ich suche kein 'Klickrezept'.

Noch mal: Ich vermute, dass mein Domain-Provider erkennt, dass mein Router IPV6 irgendwie kennt, und darum meine ganze ehemalige Portweiterleitung gar nicht mehr in Betracht gezogen wird.
WENN dem so wäre, wäre interessant, ob man das durch irgendein Häkchen/Eintrag lösen kann....

 

[blurrrr]

Wenn es via IPv4 funktioniert und via IPv6 nicht, bevorzugt das System (Client) evtl. einfach die IPv6-Verbindung.

server1.meineDomain.de -> asdfsdfasdfaefdw.myfritz.net
In der Box ist IPV6 NICHT aktiv.
Fazit: server1.meineDomain.de funktioniert.

Schritt 2;
Ich lasse alles, wie es ist, ich aktiviere lediglich IPV6 in der Box. (vergesst server2...)
Fazit: server1.meineDomain.de funktioniert nicht mehr.

Hier wäre die Frage, welche IPv6 dann hinter "server1.meineDomain.de" steht.

Grunsätzlich verhält es sich wie folgt:

IPv4:
server1.meineDomain.de "muss" auf die öffentliche IPv4 vom Router zeigen. Am Router muss eine entsprechende Portweiterleitung auf die interne private IP von Server1 eingerichtet sein. Somit kommen Anfragen am Router an, dieser schreibt die Ziel-IP im Paket auf die IP von Server1 um. Somit erreichen die Pakete Server1.

IPv6:
server1.meineDomain.de "muss" auf die öffentliche IPv6 von Server1 zeigen. Am Router muss eine Portfreigabe (für IPv6) für Server1 eingerichtet werden, damit die Pakete durch die Firewall vom Router komen. Die Pakete werden nicht umgeschrieben, da direkt die öffentliche IPv6 von Server1 angesprochen wird.

Kurzum heisst es also, dass Dein DynDNS-Eintrag (server1.meineDomain.de) auf einmal auf die IPv4 vom Router zeigen muss, zum anderen aber auch auf die IPv6 vom Server.

Wenn Du nun IPv6 zusätzlich aktivierst, wäre die Frage, wo der DynDNS-Client läuft. Läuft er auf dem Router selbst, wird der Router erstmal hingehen und seine eigene öffentliche IPv6 im DynDNS-Record hinterlegen (also seine IPv4+IPv6). Vielleicht überprüfst Du das erstmal, indem Du in der Windows-Eingabeaufforderung mal ein nslookup server1.meineDomain.de ausführst und die IP-Adressen (v4 und v6) mit Deinen lokal vorhandenen abgleichst.

 

[HartCh]

Danke. Das hört sich nach analytischem Vorgehen an. (Ich bin übrigens rein mit Linux unterwegs. Aber das soll mal egal sein...)

Wenn IPv6 im Router NICHT aktiv ist, erhalte ich folgendes:

@g1406:~$ nslookup server1.meineDomain.de
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
server1.meineDomain.de  canonical name = asdfsdfasdfaefdw.myfritz.net.
Name:   asdfsdfasdfaefdw.myfritz.net
Address: 86.xxx.xx.xxx (Das ist die öffentliche IP meines Routers...)

Wie gesagt: Bei meinem ISP habe ich für meineDomain.de einen CNAME Record angelegt. Und hier habe ich asdfsdfasdfaefdw.myfritz.net angegeben, was ja, wenn ich das richtig verstehe, so was ist, wie DynDNS. Nämlich, dass bei Aufruf von server1.meineDomain.de eben diese Anfrage weitergeleitet wird, an die öffentliche IPv4 Adresse, die zu asdfsdfasdfaefdw.myfritz.net gehört. Und die kennt myfritz.net natürlich.
Letztendlich wird mein Router über eine IPv4 Adresse angesprochen, hier habe ich die Portweiterleitung auf einen nginx-Server, der die Anfrage dann meinen server1 weiterleitet.

Nun aktiviere ich IPv6 in meinem Router. Ich mache nichts anderes.
Nun erhalte ich:

@g1406:~$ nslookup server1.meineDomain.de
;; Got SERVFAIL reply from 127.0.0.53
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find server1.meineDomain.de: SERVFAIL

Hier tue ich mich mit einer Deutung schwer. Meinem ISP dürfte das eigentlich egal sein, der leitet meine Anfrage nach wie vor an asdfsdfasdfaefdw.myfritz.net weiter. Hier passiert dann vermutlich irgendwas.

Nun habe ich bei meinem ISP den CNAME gelöscht und statt dessen einen A-Record mit der öffentlichen IP meines Routers angelegt. Die kann sich natürlich mal ändern, zum Testen ist mir das aber egal:

@g1406:~$ nslookup server1.meineDomain.de
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   server1.meineDomain.de
Address: 86.xxx.xx.xxx

Das sieht für mich erst mal ganz gut aus. Allerdings wird meine Portweiterleitung ignoriert: Wenn ich die Seite im Browser aufrufe, wird sie nicht gefunden.
Meine Deutung ist, dass der Router, wenn IPv6 aktiviert ist, die Portweiterleitung bei den Freigaben ignoriert und davon ausgeht, dass auch nur IPv6 Anfragen kommen, die er pflichtgemäß weiterleitet. (... 'wohin' ist mir noch nicht ganz klar ... aber vermutlich an den, dem die IPv6 gehört. In Zukunft also an meine nginx.
AKTUELL kommt aber noch gar keine IPv6.

 

[Fusion]

Musste gerade schmunzeln... "suche kein Klickrezept .... wenn dem so wäre, gibt es irgendwo ein Häkchen".... also wieder Klickrezept.

Dein Domain-Provider erkennt Null. Der macht einfach was du ihm in der Konfig oder DNS Einstellungen einstellst (A/AAAA records, CNAME, etc).
Egal was du an deinem Anschluss anstellst an Portweiterleitungen oder IPvX-Zugängen des Internet-Providers.
Nur deine dynDNS / myfritz config wird von den Versuchen beeinflusst.
Am Ende muss alles zusammen passen. Wenn die Einstellungen beim Domain-Provider nur für IPv4 funktionieren musst du diese selbst anpassen, automatisch macht der nix.

Frage: nginx server ... ist das nginx proxy manager, oder ein webserver mit Webseite und URL zum Server 1? Also bitte mal präzise durch welche Kette die Kommunikation laufen soll.

Im Fall eines Proxy ist IPv4 vom Router und IPv6 vom Proxy das Ziel.

Denke aber wir sind immer noch bei den Basics und erstmal zu klären welche IPv6 Einstellungen in der Kette existieren, wie die Kette aussieht und welche Geräte welche IPv4/v6 Adressen haben und welche Portweiterleitungen / Portfreigaben aktiv sind.

Es gibt sicher Leute die schon eine Umstellung auf Glasfaser durchgemacht haben. Wir wollen es ja aber in deinem Setup lösen und nicht woanders. Soll natürlich niemand davon abhalten Stichpunkte in Raum zu werfen die dir dann vielleicht helfen. Zielführender finde ich persönlich aber immer am konkreten Beispiel zu arbeiten.
Ohne Details bleibt nur der Allgemeine Ratschlag sich mit IPv4/IPv6, Routing und DNS (und dynDNS) zu beschäftigen / einzulesen und zu verstehen.

Musst jetzt auf meinen Post nicht antworten. Denke wir verfolgen das jetzt anhand des Triggers von @blurrr, dass nicht zu viele Geschichten parallel laufen.

 

[blurrrr]

Okay, bei dem "Rumgebastel" muss ich doch auf einen kleinen Umstand hinweisen:

DNS-Records haben einen TTL-Wert (Time-To-Live). Dieser Wert gibt eine Gültigkeitsdauer in Sekunden an. Hast Du nun einen A-Record mit einer TTL von z.B. 3600 oder 86400 (Sekunden), entspräche das einer Gültigkeitsdauer von 1 Stunde (oder eben 24 Stunden). Es wäre erstmal zu klären, welche TTL der DynDNS-Record nutzt. Es "sollten" im besten Fall irgendwas zwischen 60 und 300 Sekunden sein (also 1-5 Minuten).

Dazu kommt, dass die Resolver auf dem Weg (die Software, welche für Dich die IP zum FQDN bei externen authoritativen DNS-Servern erfragt) i.d.R. auch alle einen lokalen Cache haben. Hast Du nun z.B. erst einen A-Record gehabt (TTL 3600) und änderst diesen Record ein paar Minuten später, ist es durchaus denkbar, dass noch immer die "alte" Antwort aus dem Cache von einem Resolver auf dem Weg ausgeliefert wird.

Bei einem CNAME-Record sieht das nochmal anders aus, da dieser ja "nur" auf einen anderen FQDN (und somit DNS-Record) verweist. Insofern würde ich vorschlagen, dass Du Dich zuerst mal schlau machst, wie genau die TTL für Deinen DynDNS-Record bei IONOS überhaupt aussieht. Damit hast Du dann schon mal verwertbare Fakten. Die TTL von DynDNS-Records würde ich übrigens immer so gering wie möglich halten (meist sind 60-300 Sekunden auch das Minimum).

Um auch lokale Problemchen diesbezüglich auszuschliessen, ist es ratsam auch immer nochmal einen externen Resolver zur Gegenprüfung zu befragen. Dazu kann man einfach die IP des gewünschten Resolvers an den o.g. Befehl anhängen, z.B. nslookup server1.meineDomain.de 8.8.8.8 (in diesem Fall wird der Google-Resolver befragt).

Es kann halt durchaus sein, dass Du bei Deinen ganzen Tests ggf. irgendwelchen veralteten Ergebnissen aufgesessen bist

Noch ganz kurz zu diesem Teil...

Nun aktiviere ich IPv6 in meinem Router. Ich mache nichts anderes.
Nun erhalte ich:
@g1406:~$ nslookup server1.meineDomain.de ;; Got SERVFAIL reply from 127.0.0.53 Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find server1.meineDomain.de: SERVFAILHier tue ich mich mit einer Deutung schwer. Meinem ISP dürfte das eigentlich egal sein, der leitet meine Anfrage nach wie vor an asdfsdfasdfaefdw.myfritz.net weiter. Hier passiert dann vermutlich irgendwas.

... hier scheint die Namensauflösung schlichtweg nicht zu funktionieren. Du fragst nun aber auch explizit nach "Deinem" Record, hast Du mal versucht einen anderen FQDN aufzulösen?

Was hier passiert sein "könnte": Du aktivierst IPv6, Deinem Client wird auch eine IPv6-Adresse zugewiesen, aber evtl. kein IPv6-DNS-Resolver. Wenn nun versuchst wird, einen FQDN aufzulösen und der Client es via IPv6 versucht - aber keinen Resolver zugewiesen bekommen hat - "könnte" es sein, dass die Namensauflösung schlichtweg "generell" nicht funktioniert. Kann sein, muss aber nicht, könnte auch sein, dass das System dann als Fallback zur IPv4-Verbindung greift, sicher weiss ich das grade aber nicht. In diesem Fall müsste man - bei aktiviertem IPv6 im Router - erstmal schauen, ob der Client a) auch eine (öffentliche) IPv6-Adresse bekommt und b) ob die Namensauflösung via IPv6 auch funktioniert.

Wie Du siehst, sind wir hier noch garnicht bei Portweiterleitungen/-freigaben und den Diensten dahinter, also erstmal Basics abklären