Firewall erlaubt keinen IPv6 Zugriff trotz "exposed host"

[sf3978]

Also ich musste die Interface-ID von Hand eingeben, die Fritzbox hat diese nicht automatisch ermitteln können (bei anderen Geräten war dieses Feld früher immer automatisch ausgefüllt?).

Ja, weil die Interface-ID vom Client mit slaac generiert wird.

Die Interface-ID habe ich mit Hilfe eines Online-Tools aus der MAC-Adresse aus "ipconfig /all" (Windows) berechnen lassen.

Das verstehe ich jetzt nicht. Ich habe das so verstanden, dass Du dhcpcd.conf mit "slaac hwaddr" verwendest. Warum jetzt mit Windows etwas berechnen lassen?

 

[pcfann]

Ich dachte wir reden über das Hostsystem der virtuellen Maschine, weil ich für dieses ja auch den Ping testen sollte, um herauszufinden ob es an der Server-Einstellungen oder tatsächlich an den Einstellungen der Fritzbox liegt.
Da habe ich dich wohl missverstanden.

Also der Ubuntu-Server hat in der Fritzbox automatisch eine Interface-ID eingetragen bekommen.
Diese ist soweit ich das verstanden habe aus der MAC-Adresse errechenbar. Wenn ich die MAC-Adresse mit einem Online-Tool zur Interface-ID "umrechnen" lasse, kommt dieselbe Interface-ID heraus, wie sie in der Fritzbox steht. Somit ist diese korrekt, richtig?

 

[PeterPawn]

@sf3978:
OK, da ist dann die fehlende Verbindung ... die älteren FRITZ!OS-Versionen arbeiten ja noch reichlich anders, gerade auch bei den Freigaben - dort gibt es kein PCP und auch andere Probleme (bei der gesamten internen IPv6-Umsetzung), dort steht aber zu diesen IPv6-Freigaben auch fast nichts in den Support-Daten.

Bei der 06.83 gibt es aber m.W. und m.E. keinen wirklichen Grund, warum man da die rDNS-Auflösung hinbekommen muß bzw. die funktioniert dann eigentlich automatisch, wenn man die FRITZ!Box "einfach machen läßt". Ansonsten steht auch diese Konfiguration des internen DNS-Servers (multid) in den Support-Daten und kann da leicht nachgelesen werden bzw. für das "Veröffentlichen" in einer "CODE"-Box hier im IPPF herauskopiert werden - falls jemand (von den späteren Lesern) kein passendes System hat, um mit den vorgeschlagenen Linux-Kommandos selbst auf die Fehlersuche zu gehen ... außerdem ist so eine Support-Datei immer ein "kompletter Schnappschuß" der jeweiligen Situation mit zueinanderpassenden Angaben, die nicht durch zwischenzeitliche Änderungen zu falschen Zusammenhängen/Schlußfolgerungen verleiten können.

---

-Bei korrekt konfiguriertem Server sollte es auch vollkommen unnötig sein, den irgendwie von Hand in der FRITZ!Box einzutragen - das gibt (so jedenfalls meine Erfahrung bei der Analyse ähnlicher Probleme) nur Schwierigkeiten.

Ich würde hier einfach den betreffenden Server noch einmal herunterfahren, seinen Eintrag komplett aus der FRITZ!Box entfernen und dann den (korrekt auch für DHCPv6-Nutzung konfigurierten) Server neu starten.

Hier geht nach meinem Empfinden ohnehin von Beginn an einiges durcheinander ... das geht bei "DHCP ja oder nein" los (#5 sagt ja, aber wie genau ist das eingestellt) und zieht sich über die Frage, was die "/etc/dhcpd.conf" in #13 mit dem Thema zu tun haben soll (die konfiguriert dann - wenn ich nicht etwas fundamental falsch verstanden habe - vielleicht einen DHCP-Service auf dem Ubuntu-Server, den der selbst aber gar nicht (be)nutzen kann) eben bis hin zu den in der FRITZ!Box bei der IPv6-Konfiguration für das LAN verwendeten Einstellungen (die durchaus Einfluß auf das Zusammenspiel zwischen VM und der FRITZ!Box haben können und die man dann "kennen" sollte) und zu den Netzwerkeinstellungen (u.U. auch nur den "resultierenden" nach DHCP) des Servers ... am besten wäre es hier wohl, wenn die FRITZ!Box tatsächlich den DHCPv6-Server gibt (kommt aber auch darauf an, wie schnell und wie häufig der vom Provider zugewiesene Präfix wechselt - dann muß der Server zeitnah auf wechselnde RAs von der Box reagieren und sein Interface ebenfalls neu konfigurieren ... ein Vorgang, den es so bei IPv4 gar nicht gibt) und ihrerseits die Clients mit einer IPv6-Adresse versorgt (stateful configuration).

Dann kennt sie diese Adressen auch automatisch und muß sie nicht erst aus dem NDP-Verkehr "erlernen". Dann sollte sie auch (ein paar Minuten nach dem Start des Servers jedenfalls und am besten sogar noch nach einem L3-Zugriff vom Server auf die Box - das kann schon ein "wget http://fritz.box" sein, vielleicht noch für IPv6 und IPv4 getrennt) den Server in ihrer eigenen Netzwerk-Übersicht mit den korrekten Adressen (inkl. der richtigen IID) führen und beim Anlegen von Freigaben die IID auch richtig vorbelegen. Das hindert den Server noch nicht daran, seinerseits mit "privacy extensions" nach RFC 4941 (auch wenn die eigentlich zur IPv6-Autokonfiguration gehören, kann man das auch als Mix betreiben) zu arbeiten für die eigenen Internet-Zugriffe, die er selbst im Rahmen seines Betriebs so verwendet (z.B. für die Suche nach Updates).

Solche "zusätzlichen" Adressen sind es dann auch, die von der FRITZ!Box im Laufe der Zeit "erlernt" werden (und diese langen Listen ergeben), wenn der Server darüber mit dem Internet kommuniziert (die Zuordnung zwischen IPv6-Adresse aus einem Paket und dem sendenden Host erfolgt wohl anhand der MAC-Adresse auf L2 oder direkt über NDP-Infos - wie genau, ist bei AVM irgendwie "geheim", aber die Möglichkeiten sind ja nicht so überbordend) und die dann irgendwann vom Client (hier ist eben der Server dann der Client) als "deprecated" angesehen und nicht länger verwendet werden, wenn er sich z.B. wg. der Verwendung von "privacy extensions" eine neue Adresse generiert hat (das ist i.d.R. ein Hash über MAC-Adresse und Timestamp). Dann ist es an der FRITZ!Box, solche älteren Adressen irgendwann auch mal zu entsorgen ... wie schnell das dann bei der 06.83 erfolgt, weiß ich im Moment auch nicht, sollte aber wieder in den Support-Daten (bei den "neighbors") stehen, wie groß die jeweilige "lifetime" eines Eintrags dort ist.

Wobei ich überhaupt nicht verstehe, warum die Box bei @pcfann (nach dem, was in #16 steht) nun eine link-lokale IPv6-Adresse (die mit "fe80" beginnt) per PCP freigeben sollte - das macht absolut keinen Sinn, weil die "fe80"-Adressen per Definition nicht geroutet werden (dürfen) und damit nie ein ICMPv6-Paket mit einer solchen Adresse am WAN-Interface der Box aufschlagen dürfte.

- - - Aktualisiert - - -

Da das Hostsystem der VM sicherlich selbst über eine Firewall verfügt, müßte auch da wohl erst einmal geklärt werden, ob es auf externe ICMPv6-Pakete überhaupt reagiert ... es ist doch viel einfacher, sowohl die "1. Internetverbindung" als auch "lan" per Paket-Mitschnitt zu belauschen und dann dort nachzusehen, ob ein auf dem WAN-Interface eingehendes ICMPv6-Paket nun sein Pendant im LAN-Mitschnitt hat oder nicht. Kommt es im LAN nicht an, fehlt vermutlich der PCP-Eintrag für ICMPv6 für genau diese verwendete IPv6-Adresse ... ich bin etwas ratlos, wo da das Problem beim Eingrenzen der Ursache liegen sollte.

 

[pcfann]

es ist doch viel einfacher, sowohl die "1. Internetverbindung" als auch "lan" per Paket-Mitschnitt zu belauschen und dann dort nachzusehen, ob ein auf dem WAN-Interface eingehendes ICMPv6-Paket nun sein Pendant im LAN-Mitschnitt hat oder nicht.

Ich kann mich irren, aber haben wir nicht genau dies bereits getan?
Der Mitschnitt des WAN-Interfaces zeigt laut Wireshark, dass auf ein eingehendes ICMP6 Paket keine Antwort gefunden werden konnte, und dann mit "administratively prohibited" dieser "Ping" abgelehnt wird.
Das Hostsystem der virtuellen Maschine lässt sich trotz "Ping6 freigeben" ebenfalls nicht anpingen (Windows).
Und auch bei

sudo tcpdump -vvveni <Interface> icmp6 and '(ip6[40] == 128 ) or (ip6[40] == 129)'

haben wir doch bereits geprüft, ob auf den Server ein ICMP6 Paket überhaupt eingeht. Dies war nur bei lokalem Ping aus dem Heimnetz der Fall, wie in #11.


Somit kann die Fehlerquelle des Servers doch eigentlich ausgeschlossen werden, wenn keine Pakete an den Server gesandt werden, oder habe ich irgendetwas grundlegend falsch verstanden?

Einen Neustart des Servers werde ich gleich nocheinmal ausprobieren und die Fritzbox ebenfalls neu starten. Dabei werde ich dann auch den Server komplett aus der Fritbox entfernen, sodass sich dieser über DHCP (Ich habe in den Internetoptionen bei IPv6 automatisch ausgewählt, das müsste reichen oder?) eine neue Adresse beschaffen muss.

 

[sf3978]

... - dann muß der Server zeitnah auf wechselnde RAs von der Box reagieren und sein Interface ebenfalls neu konfigurieren ... ... und ihrerseits die Clients mit einer IPv6-Adresse versorgt (stateful configuration).

Das macht der Server ja auch (wenn die FB so konfiguriert ist), und zwar unabhängig ob PEs auf dem Server aktiviert sind oder der Server die Interface-ID selber generiert oder von der FB zugewiesen bekommt.

Anschauen kann man das (d. h. die RAs der FB), auf dem Server mit z. B.:

sudo ndptool -v -i <Interface> monitor

oder mit:

sudo tcpdump -v -ni <Interface> 'icmp6 and (ip6[40] == 134)'

 

[PeterPawn]

@pcfann:
Du verwechselst hier vermutlich (oder ich habe die ausgeführten Arbeiten nicht richtig verstanden) die Interpretation des Mitschnitts durch Wireshark (wo die Dissectoren dann versuchen, die Pakete zu "matchen") mit der Frage, ob nun diese Antwort von der FRITZ!Box-Firewall oder erst vom Server selbst stammt.

Dazu braucht es eben parallele Mitschnitte der "1. Internetverbindung" und des "lan"-Interfaces ... nur dann kann man eben sehen, ob ein Paket aus dem WAN im LAN auftaucht (und dann der Server seinerseits mit Ablehnung reagiert) oder ob es bereits die FRITZ!Box ist, die da die Verbindung ablehnt, weil es keinen PCP-Eintrag für diese Art von Verkehr gibt.

Wenn Du das tatsächlich schon definitiv festgestellt und geschrieben haben solltest, habe ich es nicht verstanden ... ich verstehe aber auch den Sinn des IPv6-Tests für das Host-System nicht so richtig (es sei denn, es geht nur darum, ob überhaupt IPv6 im LAN richtig arbeitet, dann kann das aber auch jeder andere Client mit IPv6 sein, mit dem man das testet), weil ja nach irgendeiner Aussage zuvor die VM über eine Bridge(!) angebunden ist und dafür muß das Host-System noch nicht einmal selbst eine IPv6-Konfiguration haben oder benutzen - zumindest wüßte ich nicht, warum das anders sein sollte. Und da kommen dann für einen solchen "ping"-Test zu einer Windows-Maschine eben wieder andere Probleme in den Frage und erst wenn man diese auch geprüft und ggf. ausgeräumt hat, kann man da eine Aussage treffen, wenn keine Antwort kommt - deshalb würde ich so einen "generellen" IPv6-Test nun auch nicht unbedingt mit einem Windows-Rechner machen, ohne dessen genaue Firewall-Konfiguration zu kennen.

Ansonsten macht mich ehrlich gesagt dieser Umgang mit den IPv6-Adressen wahnsinnig, weil man mehr oder weniger raten muß/soll ... wenn #18 wirklich heißen soll, daß die ICMPv6-Antwort von der FRITZ!Box kommt und nicht vom Server (wer ist denn "IPv6-Router", die FRITZ!Box oder irgendein anderer Router auf dem Weg im Internet?), dann ist dort eben die Weiterleitung für die verwendete IPv6-Adresse nicht konfiguriert und deshalb lehnt die FRITZ!Box höchstselbst diesen Request ab (sie ist dann wohl nicht im Stealth-Mode, dann sollte sie m.E. gar nicht reagieren und den Request ins Leere laufen lassen).

Genau dann muß man eben die PCP-Protokolle prüfen und ermitteln, ob diese Freigabe nun eingerichtet sein sollte oder nicht. Steht sie da drin (und zwar zum Zeitpunkt des Tests, denn die 120 Sekunden "lifetime" hast Du inzwischen sicherlich selbst gesehen), dann sollte das Paket ins LAN durchgereicht werden und kein "administratively prohibited"-Paket von der FRITZ!Box erzeugt werden. Steht sie dort gar nicht drin (bzw. mit einer abweichenden Adresse), ist die Box falsch konfiguriert und man muß sich nicht wundern, wenn die Pakete (glücklicherweise) abprallen. Stimmen die PCP-Infos und das Paket kommt trotzdem nicht durch, hat die Box ein Problem.

Die Neustarts sollten aber dabei helfen, daß die FRITZ!Box ältere IPv6-Adressen "vergißt" und dem Server sollte es dann genauso gehen. Damit hat der (wenn man mal PE außen vor läßt) genau eine statische IPv6-Adresse (da sollte ihm die FRITZ!Box eigentlich die Adresse zuweisen, die aus dem Präfix und der, aus der MAC-Adresse abgeleiteten, IID besteht) und genau für diese sollte dann auch in der FRITZ!Box in den PCP-Daten die Freigabe für ICMPv6 auftauchen. Wenn die dann da ist, sollte auch ein von extern kommendes ICMPv6-Paket an die richtige Adresse bis ins LAN gelangen (auch hier einfach auf der Box oder auf dem Windows-Rechner mit dem Host per Wireshark mitschneiden) und dann kommt trotzdem wieder der Server mit seiner Firewall-Konfiguration in den Fokus, weil es bei IPv6 problemlos möglich ist, Regeln für "iptables" (bzw. für das IPv6-Pendant "ip6tables") festzulegen, die genau dann ICMPv6-Pakete berücksichtigen, wenn die von einem Rechner mit dem eigenen (globalen) Präfix oder von eine link-lokalen Adresse (die beginnt mit "fe80") kommen. Das muß dann noch nicht automatisch heißen, daß auch andere Absenderadressen zugelassen werden - dann kommt also wieder die Frage, was denn nun in den "ip6tables"-Chains steht.

 

[pcfann]

Ich glaube, wir kommen der Problemlösung näher.
Ich habe sowohl Fritzbox als auch Ubuntu-Server neu gestartet. Eine neue IPv6 Adresse (bzw. mehrere...?) wurde erfolgreich per DHCP vergeben, in der Fritzbox taucht als Information zum angeschlossenen Endgerät (Server) auch dieser Zusatz auf:

dhcpcd-6.10.1

Jedoch hat der Server in der Fritzbox (Heimnetzübersicht->Netzwerkverbindungen->Server) wieder mehrere IPv6 Adressen...:


In "ifconfig" steht Folgendes:


enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.178.26 netmask 255.255.255.0 broadcast 192.168.178.255
inet6 fe80::A1:A2:A3:A4 prefixlen 64 scopeid 0x20<link>
inet6 2a00:6020:X:X:B1:B2:B3:B4 prefixlen 64 scopeid 0x0<global>
inet6 2a00:6020:X:X:C1:C2:C3:C4 prefixlen 64 scopeid 0x0<global>
inet6 2a00:6020:X:X1234 prefixlen 64 scopeid 0x0<global>

Soweit so gut. Nun zur Erreichbarkeit:

Es ist nur eine von den 3 Adressen aus dem Internet erreichbar. Im Bildausschnitt der Fritzbox die 2. Adresse (also die nach fe80:
Bei "ifconfig" ist es die 3., also 2a00:6020:X:X:C1:C2:C3:C4.

Somit wäre für mich das Problem der Erreichbarkeit erstmal gelöst, jedoch frage ich mich immernoch, wieso der Server dann überhaupt 2 weitere <global> IPv6 Adressen vergeben bekommt.
Wenn ich online meine eigene IP Adresse des Servers auslese, steht dort jedoch wieder eine andere, nämlich die 2. aus "ifconfig" und die 3. aus der Fritzbox-Tabelle (2a00:6020:X:X:B1:B2:B3:B4)
Und scheinbar nur um mich nochmehr zu verwirren wird dem Dynv6 Eintrag die 4. aus "ifconfig" und die 4. aus dem Fritzbox-Bild zugeordnet(2a00:6020:X:X1234).

Somit scheint es mir nun so, als wäre der Server aus dem Internet erreichbar, leider bringt dies jedoch noch nichts, da alle Seiten, auf die ich verbinde Adresse B angezeigt bekommen und der Dynv6 Eintrag Adresse D zugeordnet bekommt, die beide nicht erreichbar sind.

Wäre es der Einfachheit halber nicht möglich, dass der Server nur eine einzige globale IPv6 Adresse bekommt, anstatt 3 von denen 2 nicht so funktionieren wie sie sollen?

 

[PeterPawn]

Warum interessiert es Dich denn überhaupt, welche Adressen ein anderer Server im Internet "sieht", wenn Du selbst dorthin eine Verbindung aufbaust? Wenn jemand etwas von Deinem Server will, antwortet der auch von der Adresse aus, an welche die Anfrage ging.

Für Dich ist doch nur wichtig, daß Dein eigener Server unter einer einzigen festen Adresse (wobei da natürlich auch mehrere funktionieren würden, aber das verwirrt Dich wohl noch mehr und m.W. kann das auch die FRITZ!Box dann nicht mehr, wenn es um mehr als eine Adresse für ein Gerät im LAN geht und man müßte auf einen delegierten Präfix umsteigen) aus dem Internet erreichbar ist und Du mußt nun nur noch dafür sorgen, daß irgendein DynDNS-Dienst (hier bietet sich dann MyFRITZ! an, weil der für IPv6-Clients einen "Namen" bereitstellen kann, auch wenn der schlecht einzugeben ist, wenn man das ständig machen soll) jeweils die aktuelle Adresse (bei der sich ja nur der Präfix wirklich ändert, die IID bleibt konstant) auch kennt.

Wenn Du einen "einfacheren Namen" haben willst als den kryptischen MyFRITZ!-Namen, kannst Du irgendwo in einer eigenen Domain ja dann einen Alias auf diesen MyFRITZ!-Namen setzen. Die Aktualisierung der MyFRITZ!-Adressen übernimmt die FRITZ!Box jedenfalls selbst, wenn sie einen neuen IPv6-Präfix kriegen sollte - ansonsten müßtest Du die DynDNS-Aktualisierung auf den Server verlagern, der dann nach der Umkonfiguration seiner IPv6-Adressen die neuen Angaben bei irgendeinem DynDNS-Service Deiner Wahl registrieren muß.

Theoretisch (vermutlich, weil ich Ubuntu und die Möglichkeiten der Netzwerk-Konfiguration da nicht in vollem Umfang kenne) könnte man sicherlich auch alles mit einer einzigen IPv6-Adresse betreiben ... aber ich verstehe immer nicht, warum die Leute auf der einen Seite "die volle Kontrolle" und auf der anderen Seite aber nicht getrackt werden wollen.

Was interessiert Dich denn Deine IP-Adresse bei einer ausgehenden Verbindung, wenn da nicht ein anderer Dienst im Internet angesprochen werden soll, der seinerseits auf der Basis der Absender-Adresse irgendwelche Filterungen vornimmt - so etwas mag es geben, dann muß man eben für die Benutzung solcher Dienste die eigene ausgehende IP-Adresse explizit festlegen. Vor dem Tracken anhand der eigenen IPv6-Adresse ist man jedenfalls wieder dann sicher, wenn diese Adresse (die andere Server im Internet sehen, wenn man dorthin Verbindungen aufbaut) sich eben auch mal ändert ... genau dafür sind ja u.a. auch die PE gedacht. Wenn Du mit Deinem Smartphone unterwegs irgendwelche Daten abrufst, fragst Du ja auch nicht zuerst, welche IP-Adresse Dein Provider Dir gerade zugewiesen hat und ob das über IPv4 oder IPv6 geht bzw. ob das mit oder ohne CGN arbeitet ... solange die Daten bei Dir ordentlich ankommen, kann der Rest Dir doch eigentlich egal sein.

Wenn Du den dynv6-Service irgendwie von Deinem Server aus aktualisieren lassen willst, mußt Du eben (keine Ahnung, was Du da zum Aktualisieren verwendest, steht ja auch nirgendwo, soweit ich weiß) dafür sorgen, daß da die richtige Adresse im HTTP-Request für das Update angegeben wird und nicht irgendein "auto" (oder daß genau die freigegebene Adresse für diesen HTTP-Request benutzt wird) ... wobei ich nicht verstehe, warum man so einen Dienst nutzen sollte, wenn man mit der FRITZ!Box doch MyFRITZ! verwenden kann und dann auch noch die Box die Aktualisierungen selbst macht - ist mir einfach zu hoch.

 

[pcfann]

Ich habe nun eine MyFritz-Freigabe eingerichtet und in meinem Domain-Service ein CNAME Alias auf die lange myfritz-Adresse gelegt.
Somit ist der Server nun unter dem Alias erreichbar, während die Fritzbox die Updates (falls nötig) übernimmt.

Problem gelöst


Vielen Dank für eure hilfreichen Antworten und eure Geduld mit mir

 

[sf3978]

Wäre es der Einfachheit halber nicht möglich, dass der Server nur eine einzige globale IPv6 Adresse bekommt, anstatt 3 von denen 2 nicht so funktionieren wie sie sollen?

Doch, wie schon geschrieben, ist das ganz einfach möglich wenn man dhcpcd (oder gleichwertig) verwendet. Z. B.:

:~ $ cat /etc/dhcpcd.conf | grep -i slaac
slaac hwaddr
##slaac private

und die PEs auf dem Server _deaktiviert_ sind.
Auf meinem Server sieht das mit den IPv6-Adressen für das LAN-Interface, z. B. so aus:

 inet6 [color=blue]fd00::[/color]xxx:xxff:fexx:xxxx/64 scope global noprefixroute dynamic 
       valid_lft 6928sec preferred_lft 3328sec
    inet6 [color=red]2###:####:####:0[/color]:xxx:xx[b][color=red]ff:fe[/color][/b]xx:xxxx/64 scope global noprefixroute dynamic 
       valid_lft 6928sec preferred_lft 3328sec
    inet6 [color=blue]fe80::[/color]xxx:xxff:fexx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

Wie man sehen kann, eine einzige globale IPv6-Adresse, über die der Server (an der FB) aus dem Internet erreichbar ist bzw. diese einzige globale IPv6-Adresse kann auch vom Server aus (... d. h. der v6-ddns-Client befindet sich auf dem Server, da ja "border device"), mit einem v6-ddns-Dienst verwendet werden.
Mit "curl -B6 http://checkip6.spdyn.de" auf dem Server, wird nur diese eine globale IPv6-Adresse angezeigt.

Was dann aber die FritzBox _z. Zt._ in ihrem Web-IF an (generierte/zugewiesene) IPv6-Adressen für den Server noch so anzeigt, muss man erstmal ignorieren. Denn irgendwann wenn die v6-dhcp-lease-Zeit für den Server abgelaufen sind, wird die FritzBox in ihrem Web-IF auch nur die IPv6-Adressen anzeigen die man mit "ip -6 a" für das betr. Interface auf dem Server jetzt schon sieht.

 

[PeterPawn]

Hier sollte man dann aber - zumindest bin ich der Meinung, daß man das sollte - noch einmal auf den Halbsatz "anstatt 3 von denen 2 nicht so funktionieren wie sie sollen?" eingehen. Denn diese Annahme, daß die nicht so funktionieren würden, wie sie sollen (weil dort kein eingehender Verkehr ankommt), ist ja falsch ... diese zusätzlichen Adressen sind für ausgehende Verbindungen gedacht (Server-Dienste sollten sich gar nicht direkt an diese Adressen binden, höchstens als Nebeneffekt über die Bindung an ein spezifisches Interface) und dafür sollten sie dann auch funktionieren.

Gerade dann, wenn man sich um Datenschutz und Tracking Gedanken macht (wenn jemand seine MAC- und IPv6-Adressen so umfangreich maskiert, kann man ihm das vermutlich unterstellen), dann sollte man auch verstehen, daß man bei IPv6 genau anhand dieser einen IPv6-Adresse tatsächlich bei jeder einzelnen IPv6-Verbindung "verfolgt" werden kann.

Selbst wenn sich der zugewiesene globale Präfix mal ändern mag, bleibt doch in diesem Falle die IID immer dieselbe und diese sollte (zumindest in der Theorie) ebenfalls weltweit eineindeutig sein - d.h. man kann bei IPv6 eben auch anhand der unteren 64 Bit einer Adresse einen Benutzer überall verfolgen. Anders als bei IPv4, wo für eine L2-Adresse am nächsten Router das Ende der Fahnenstange erreicht ist, ist die MAC-basierte IID bei IPv6 dann Bestandteil der global gültigen IPv6-Adresse und wird mit jedem ausgehenden IPv6-Paket auf die Reise geschickt.

Das mag nicht so offensichtlich sein, weil sich die oberen 64 Bit eben ändern (oder das zumindest könn(t)en) - aber anders als bei IPv4 reicht eben schon die halbe IPv6-Adresse für das Identifizieren eines Absenders, selbst wenn sich die andere Hälfte ständig ändern sollte.

Gegen eine gewisse "Statik" in den oberen Bits können zwar auch die "privacy extensions" nichts ausrichten, aber hier greift dann auch noch ein gewisser "Schutz" ... es ist ja nicht grundsätzlich klar, wieviele der oberen Bits einer IPv6-Adresse nun zum (wechselnden) Präfix gehören, das ist - von Provider zu Provider ggf. sogar - variabel und damit kann man nicht automatisch davon ausgehen, daß sich hinter identischen 64 Bits im oberen Teil auch immer derselbe Absender verbirgt - anders eben bei einer unveränderlichen (bzw. immer wieder benutzten) IPv6-IID, solange diese tatsächlich auf der Basis der Ethernet-Adresse gebildet wurde.

Die Benutzung solcher "zufälligen" Adressen ist also nicht zwingend bei IPv6 ... aber wenn das ein eigener Server mit einem DNS-Server oder -Forwarder ist, der nur mit einer einzigen IID arbeitet und seinerseits andere Server per IPv6 befragt, kann der Betreiber dieser Server - auch ohne die Kenntnis, welchen IPv6-Präfix oder welche IPv4-Adresse der Absender dynamisch von seinem Provider erhalten hat - problemlos anhand der IPv6-Adresse des Absenders alle von dort kommenden Anfragen "zusammenfassen" und einem einzelnen Absender über lange, lange Zeiträume zuordnen und das ist ein Vorgang, der bei dynamischen IPv4-Adressen oder IPv6-Nutzung mit PE eben nicht ohne weiteres möglich ist.

Das gilt natürlich für so ziemlich alles, was so ein Server "von sich aus" im Internet macht - auch dann, wenn er es nur als Stellvertreter für irgendwelche LAN-Clients machen sollte. Wer also einen (HTTP-)Proxy-Server auf so einem Gerät betreibt (wo dann die abgehende Verbindung zum Anbieter eben von diesem Proxy-Server startet), der ermöglicht jedem Betreiber eines befragten HTTP-Servers auch vollkommen ohne Cookies o.ä. (oder gar "Super-Cookies") das langfristige Verfolgen aller Benutzer des Proxy-Servers (was in unserem Kontext sicherlich dann eine Einzelperson, eine Familie, eine WG oder eine kleinere Firma wäre) und das "Aggregieren" von deren Internet-Nutzung (zumindest bei den eigenen Diensten des Anbieters) - "big data" läßt da grüßen.

 

[pcfann]

Leider muss ich mich nochmal melden, da mein Problem zwar teilweise gelöst ist, jedoch doch noch nicht ganz zufriedenstellend.
Ich habe nun über eine MyFritz-Freigabe den Server über ein CNAME-Alias im Internet freigegeben (Anbieter: noip com)
Ein ausdrücklich auf IPv6 gerichteter Ping an diese Adresse ist erfolgreich. Wenn jedoch einfach so auf den Server über den Browser zugegriffen werden soll, wird anscheinend die ebenfalls durch MyFritz zum Hostname gehörende IPv4 Adresse bevorzugt benutzt. -> Website nicht erreichbar, da IPv4 Adresse nicht öffentlich erreichbar

Nun wäre meine Frage, ob ich beim DNS-Anbieter oder in den MyFritz Einstellungen die Weiterleitung auf den Server ausschließlich über IPv6 erlauben kann, da die IPv4 Anfrage nicht ankommen (NAT des Providers..)
Dass ich sozusagen die Verbindung zu dem Server nur über den AAAA-Eintrag im DNS zwinge während der A-Eintrag "ignoriert" wird?
Beziehungsweise ob es möglich ist, den A Eintrag aus dem MyFritz DNS-Eintrag zu entfernen?

 

[koyaanisqatsi]

Moin

Meines Erachtens nicht über xyz.myfritz.net, aber mit einen anderen DynDNS Anbieter sollte das schon möglich sein.
Beispielsweise: spdyn.de (SECUREPOINT, gratis bis zu 5 Hostnamen)
...mit dem geht sowas (separate A und AAAA Hostnamen).

 

[pcfann]

Vielen Dank für den Hinweis.
Leider scheint es dort einige Probleme zu geben:
Ich kann zwar erfolgreich meine IPv6-Adresse in den DNS-Dienst eintragen lassen, auch das updaten klappt einwandfrei, jedoch lässt sich kein DNS Eintrag für die ausgewählte Domain finden...
Bsp: meinedomain.spdns.de hat die korrekte IPv6-Adresse eingetragen bekommen, ein "nslookup meinedomain.spdns.de" führt zu einem DNS Timeout:

nslookup meinedomain.spdns.de
Server:  fritz.box
Address:  192.168.178.1

Nicht autorisierende Antwort:
DNS request timed out.
    timeout was 2 seconds.
Name:    meinedomain.spdns.de

Wenn ich nun dasselbe für die auf meine Fritzbox IPv6 Adresse wiederhole, wird ein Ergebnis zurückgegeben:

nslookup Routerdomain.spdns.de
Server:  fritz.box
Address:  192.168.178.1

Name:    Routerdomain.spdns.de
Address:  IPv6 des Routers

Dabei ist meine Vermutung, dass die Fritzbox die eigene Domain nicht bei einem DNS-Server nachfragt, da sie ja bekannt sein sollte, denn eine DNS-Abfrage von einem externen Rechner führt ebenfalls zu einem Timeout.

Hat irgendjemand eine Vermutung, woran das liegen könnte?

EDIT:
Domains werden als "aktiv" angezeigt

EDIT2:
Sowohl die Standard ISP-Nameserver als auch die Google Dns-Server geben beide einen Timeout zurück (Einstellung in Fritzbox->Internet->Zugangsdaten->DNS)

 

[koyaanisqatsi]

Aus Griechenland über den frisch eingerichteten Gastzugang ( 7580, v6.83 ) und erlaubten surfen, mailen, VPN und NTP KiSi-Gastzugangs-Profil...

 / # nslookup koyaanisqatsi.spdns.org 192.168.189.1
Server:    192.168.189.1
Address 1: 192.168.189.1
 
Name:      koyaanisqatsi.spdns.org
Address 1: 2003:e9:7bbf:17d:3a10:d5ff:fe42:d512 p200300E97BBF017D3A10D5FFFE42D512.dip0.t-ipconnect.de
Address 2: 79.209.78.137 p4FD14E89.dip0.t-ipconnect.de

...gehts auf die zwei ( A & AAAA ) gleichnamigen Hostnamen (Standort: Berlin, 7560 mit v6.83) für Dual Stack und...

 / # nslookup koyaanisqatsi.spdns.de 192.168.189.1
Server:    192.168.189.1
Address 1: 192.168.189.1
 
Name:      koyaanisqatsi.spdns.de
Address 1: 2003:e9:7bbf:17d:3a10:d5ff:fe42:d512 p200300E97BBF017D3A10D5FFFE42D512.dip0.t-ipconnect.de

...den Einen ( AAAA ) für IPv6-Only.
:noidea:

 

[pcfann]

Also deine (Test-)Adresse kann ich auch über nslookup erreichen, meine eigenen jedoch nicht...
Muss ich bei meinem Account dort irgendetwas umstellen?
Oder muss ich einen neuen erstellen? -> Eventuell Fehler auf den Servern von spdyn de bzw spdns de?

 

[sf3978]

..., auch das updaten klappt einwandfrei, ...

Wie hast Du updatet?

 

[pcfann]

Wie hast Du updatet?

Ist das nicht für den DNS-Timeout völlig egal?
Ich habe sowohl auf ubuntu über ddclient, als auch in der Fritzbox (Internet->Freigaben->DynDns) geupdated. Auch habe ich probiert Adressen von Hand bzw. anhand meiner aktuellen IP zu übernehmen.
Es scheint alles zu klappen, da die Updates im Log auch als erfolgreich angezeigt werden und die eingetragene IP stimmt.
Nur kann ich über nslookup die DNS-Server nicht erreichen. Auch mit einem neuen Account schlägt es fehl. Das Konto wurde mit Hilfe des Email-Links aktiviert, die Domain steht ebenfalls auf "aktiv"

nslookup domain.spdns.de
Server:  fritz.box
Address:  192.168.178.1

DNS request timed out.
    timeout was 2 seconds.
Name:    domain.spdns.de

Bei der Domain 3 Beiträge weiter oben (koyaanisqatsi) , kann ich jedoch problemlos ein nslookup durchführen.

 

[sf3978]

nslookup domain.spdns.de
Server:  fritz.box
Address:  192.168.178.1

DNS request timed out.
    timeout was 2 seconds.
Name:    domain.spdns.de

Versuch mal mit:

nslookup -q=AAAA domain.spdns.de 8.8.8.8

 

[pcfann]

Ich bin hier echt gerade leicht am verzweifeln...
Dis bisherige Erkenntnis ist:
Um meinen Server über IPv6 erreichen zu können, kann ich keine MyFritz Freigabe verwenden, da diese wohl standardmäßig IPv4 bevorzugt. Und die v4 Adresse zeigt auf den NAT vom Provider.
Ich habe eine Domain router.spdns.de eingerichtet, die Fritzbox updated alles ordnungsgemäß, Erreichbarkeit "von außen" ist vorhanden.

Nun habe ich jedoch wieder das gleiche Problem:
Mein ddclient auf Ubuntu gibt dem DNS-Anbieter die falsche IP mit.

ifconfig: 

inet 192.168.178.26  netmask 255.255.255.0  broadcast 192.168.178.255
        inet6 2a00:6020:X:X:X:X:X:65f3  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::X:X:X:df2e prefixlen 64  scopeid 0x20<link>
        inet6 2a00:6020:X:X:X:X:X:9a81  prefixlen 64  scopeid 0x0<global>
        inet6 2a00:6020:X:X:X:X:X:15b3  prefixlen 64  scopeid 0x0<global>
        inet6 2a00:6020:X:X:X:X:X:b145  prefixlen 64  scopeid 0x0<global>

ddclient teilt nun dem DNS-Server die 9a81 IP mit. Diese ist jedoch von außen nicht zu erreichen, nur die 15b3 ist erreichbar.

Meine /etc/ddclient.conf:

  GNU nano 2.7.4                                          Datei: /etc/ddclient.conf

# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf

protocol=dyndns2
usev6=if, if=enp0s3
server=update.spdyn.de
login=domain.spdns.de
password='TOKEN'
domain.spdns.de

Meine /etc/default/ddclient:

run_dhclient="false"
run_ipup="false"
run_daemon="true"
daemon_interval="1200"

Und meine /etc/dhcpcd.conf:

# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac hwaddr

Die IP Tabelle zum Server in der Fritzbox:


Wie kann ich nun dem ddclient sagen, dass er die "richtige" öffentliche IPv6 übermitteln soll?



Außerdem klappt der nslookup ebenfalls noch nicht:
Nachdem ich nun einen neuen Account erstellt habe, ist zumindest die Domain durch online-tools wie z.B. der Ping6 von subnetonline com erreichbar. Sie wird korrekt auf die im DNS-Service eingetragene IPv6 aufgelöst.
Die Router-Domain wird noch immer durch nslookup richtig dargestellt, aber für die IPv6 des Servers erhalte ich immernoch einen timeout.

Was mache ich falsch?

EDIT:
Huch, da war jemand schneller. Habe #39 erst jetzt gesehen.
Ja, das funktioniert. Jedoch bringt mich das auch nicht wirklich weiter, da z.B. am Handy über mobile Daten ein Öffnen der Domain im Browser zu einem DNS-Fehler führt.