Firewall erlaubt keinen IPv6 Zugriff trotz "exposed host"

pcfann schrieb:

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?).

Zum Vergrößern anklicken....

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

pcfann schrieb:

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

Zum Vergrößern anklicken....

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?

@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.

PeterPawn schrieb:

... - 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).

Zum Vergrößern anklicken....

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.:
oder mit:

@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.

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 schrieb:

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?

Zum Vergrößern anklicken....

Doch, wie schon geschrieben, ist das ganz einfach möglich wenn man dhcpcd (oder gleichwertig) verwendet. Z. B.:
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:
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.

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.

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).

Aus Griechenland über den frisch eingerichteten Gastzugang ( 7580, v6.83 ) und erlaubten surfen, mailen, VPN und NTP KiSi-Gastzugangs-Profil...
...gehts auf die zwei ( A & AAAA ) gleichnamigen Hostnamen (Standort: Berlin, 7560 mit v6.83) für Dual Stack und...
...den Einen ( AAAA ) für IPv6-Only.
:noidea:

pcfann schrieb:

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

Zum Vergrößern anklicken....

Wie hast Du updatet?

pcfann schrieb:

Code:

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

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

Zum Vergrößern anklicken....

Versuch mal mit: