[gelöst] Privacy Extension blockt WWW

[TomL]

Moin

Ich habe heute nachmittag eine neue Buster-VM aufgesetzt und bin auf ein unerklärliches Problem gestoßen: Sobald ich die PE aktiviere, kann ich nicht mehr nach draußen 'pingen'... obwohl der ISP-Prefix gleich geblieben und für beide IPv6-Adressen/64 korrekt ist ... und es funkt auch definitiv kein Paketfilter dazwischen. Das Problem ist hier beliebig reproduzierbar.

Wenn ich 'use_tempaddr' auf 1 setze, ist die aus der MAC gebildete IPv6 aktiv und ich kann z.b 'heise.de' mit v6 pingen. Ändere ich auf '2', wird die temp.Addr. gebildet und damit stirbt der Ping ohne jede Reaktion, er hängt einfach. Ändere ich wieder zurück auf '1' klappt der Ping erneut. Vielleicht ist in meiner sysctl_ipv6.conf ein Fehler enthalten. Hat jemand eine Idee, wie man dem Fehler auf die Schliche kommt?

Interessant ist, dass ich LAN-Intern andere IPv6-Adressen pingen kann... nur halt wird die temp-Addr anscheinend nicht raus ins WWW geroutet... trotz gleichem Prefix und gleicher Default-Route.... und (was ich gar nicht verstehe) sogar mit funktionierender Namensauflösung. Der Name wird korrekt aufgelöst. Aber selbst wenn ich dann die Heise-IPv6 direkt anpinge, also ohne DNS, auch das geht mit der Temp-Addr. nicht.

Code: Alles auswählen

net.ipv6.conf.default.disable_ipv6=0
net.ipv6.conf.default.forwarding=0
net.ipv6.conf.default.autoconf=1
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.default.accept_ra = 1
net.ipv6.conf.default.temp_prefered_lft = 86400
net.ipv6.conf.default.temp_valid_lft = 172800
net.ipv6.conf.default.max_addresses = 16
net.ipv6.conf.default.regen_max_retry = 6
net.ipv6.conf.default.max_desync_factor = 600

net.ipv6.conf.all.disable_ipv6=0
net.ipv6.conf.all.forwarding=0
net.ipv6.conf.all.autoconf=1
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.all.temp_prefered_lft = 86400
net.ipv6.conf.all.temp_valid_lft = 172800
net.ipv6.conf.all.max_addresses = 16
net.ipv6.conf.all.regen_max_retry = 6
net.ipv6.conf.all.max_desync_factor = 600

net.ipv6.conf.enp1s0.disable_ipv6=0
net.ipv6.conf.enp1s0.forwarding=0
net.ipv6.conf.enp1s0.autoconf=1
net.ipv6.conf.enp1s0.use_tempaddr = 2
net.ipv6.conf.enp1s0.accept_ra = 1
net.ipv6.conf.enp1s0.temp_prefered_lft = 86400
net.ipv6.conf.enp1s0.temp_valid_lft = 172800
net.ipv6.conf.enp1s0.max_addresses = 16
net.ipv6.conf.enp1s0.regen_max_retry = 6
net.ipv6.conf.enp1s0.max_desync_factor = 600

[mat6937]

Sobald ich die PE aktiviere, kann ich nicht mehr nach draußen 'pingen'... obwohl der ISP-Prefix gleich geblieben und für beide IPv6-Adressen/64 korrekt ist ... und es funkt auch definitiv kein Paketfilter dazwischen. Das Problem ist hier beliebig reproduzierbar.

Weil Du schreibst "PE blockt WWW", funktioniert

Code: Alles auswählen

nc -zv -6 heise.de 443
dig -6 aaaa +tcp ubuntuusers.de +short @2620:0:ccc::2
dig -6 aaaa ubuntuusers.de +short @2620:0:ccc::2

mit aktivierten PEs?

[TomL]

...funktioniert ::: mit aktivierten PEs?

Nein, nicht ein einziger Befehl funktioniert ... und ja, alle funktionieren...

Also, keine einzige meiner KVM-VMs kann mit der temp-addr umgehen, aber alle können mit der aus der MAC gebildeten umgehen, egal ob die PE aktiviert sind oder nicht. Sobald die PE-Adresse verwendet wird (egal ob inbound oder outbound), steht der jeweilige Prozess still und fällt irgendwann mit Timeout aus. Die PE-Adresse einer VM kann auch nicht von einem anderen LAN-Client angesprochen werden, weder mit GUA noch mit ULA, die Antwort lautet sofort "Destination unreachable: Address unreachable". Verwende ich hingegen die MAC-basierte läuft alles (GUA+ULA) wie geschmiert.

Von dem Problem sind meine Custom-Debian-VMs ausnahmslos alle betroffen, ebenso wie eine reguläre xubuntu- und Mint-Installation in jeweils einer VM. Auf allen 'echten' Maschinen hingegen funktioniert mein (teilweise zu den VMs identisches) Setup und auch die Verwendung der PE-Adresse.

Dumm ist, dass ich die Tragweite jetzt nicht oder nur schwer abschätzen kann. Eigentlich bin ich ja total gegen die Abschaltung von IPv6, aber ich denke, statt mit konstanter IPv6 isses wohl bei solchen Voraussetzungen besser, auf einigen VMs wieder mit IPv4 zu natten.....

[mat6937]

...funktioniert ::: mit aktivierten PEs?

Nein, nicht ein einziger Befehl funktioniert ... und ja, alle funktionieren...

Versuch mal mit:

Code: Alles auswählen

net.ipv6.ip_nonlocal_bind = 1

in der "/etc/sysctl.conf"-Datei (oder gleichwertig) und nach einem reboot.

[TomL]

Versuch mal mit: ....

Was bewirkt dieser Bind-Befehl? So richtig schlau werde ich aus den Web-Funden dazu nicht... vor allem vor dem Hintergrund, dass ich gar keine non-local-IPs habe....

Aber es gibt Neuigkeiten... allerdings übersteigt es momentan meine Fähigkeiten das 'Warum?' zu erklären.... es funktioniert jetzt nämlich, aber ich weiss nicht welcher Fehler für die Probleme verantwortlich war. Ich hatte zwischenzeitlich (und in allen Situationen immer mit gültigen (!) IPs) jetzt folgende wechselnde Situationen:

IPv4 = Meldung "Kein Netzwerk" auf ICMP, obwohl Traceroute funktioniert hat.
IPv4 = Das gleiche wie vor, aber nicht für alle lokalen Clients ... einigen waren via ICMP zu erreichen, einige nicht
IPv6 = temp. Addr wird gebildet, ist aber tot... alle Prozesse, die die verwenden, hängen bis zum timeout
IPv6 = mit abgeschalteten PE wird trotzdem temp Addr gebildet... ist aber auch tot
IPv6 = alle NICs sind via MAC-basierter IP voll funktionsfähig, egal ob PE oder nicht
IPv4 = zum letzten (vorherigen) Punk teilweise kein IPv4-Netz, trotz IP im NIC und keine Fehlermeldung im Journal
IPv4+6 Meldung "admin-prohibited" auf ICMP und das ohne (!) aktiven Paketfilter

Ich war aus lauter Verzweiflung kurz davor, Buster noch mal neu aufzusetzen. Stattdessen habe ich jetzt jedoch alles maskiert oder deinstalliert, was mit Netzwerk zu tun hat, wie dhcp, avahi, networking, ifup@service, systemd-networkd. Ich starte jetzt aktuell das Netzwerk mit Static-IP und Routen über eine eigene Service-Unit. Und weil ich hier wegen der laufenden KVM-VMs insgesamt 12 Interfaces habe, passiert das alles jetzt in meiner von mir vorgegebenen und damit eindeutigen Reihenfolge. Wie gesagt, damit funktionierts erst mal. Aber ich muss mal abwarten, was wieder passiert, wenn ich den DNS von der Fritte wieder auf die VM umleite. Das wird jetzt erst wohl mal laufen ...aber das Problem ist ja meistens, wie die Prozesse beim täglichen Emfpang eines neues Prefix reagieren....

[mat6937]

Versuch mal mit: ....

Was bewirkt dieser Bind-Befehl? So richtig schlau werde ich aus den Web-Funden dazu nicht... vor allem vor dem Hintergrund, dass ich gar keine non-local-IPs habe....

Diese Konfiguration hat nichts mit non-local-IPs zu tun.

Dieser Bind-Befehl bewirkt, dass eine Software/Anwendung auch mit einer IPv6-Adresse konfiguriert werden kann, die zum Zeitpunkt des Starten der Software/Anwendung, dem Interface noch nicht zugewiesen ist. Ohne diesen Bind-Befehl wird die Software/Anwendung nicht starten können, wenn dem Interface die IPv6-Adresse noch nicht zugewiesen ist.

[TomL]

Ok, das kannte ich noch nicht, weil ich so eine Situation noch nicht hatte. Bei mir ist alles so eingerichtet, dass die Jobs auf fertig konfigurierte Interfaces warten.

Aber zur Erläuterung, ich habe jetzt scheinbar exakt die gleiche Interface-Situation wie während des Problems, alle Interfaces haben (sofern IPv6 gewollt ist) zwei IPv6-GUA (2000::/3), jeweils MAC-Based und PE. Ich habe an der IPv6-Konfiguration vorher auch nicht rumgeschraubt, die ist eigentlich sogar von Stretch übernommen... das lief hier schon immer via sysctl-Conf und SLAAC, ganz automatisch, seit Jahren erfolgreich. Nur hatten die PE-Adressen während des Problems keine Netz-Funktion, weder rein noch raus.... die PE-Adressen waren da, sahen optisch völlig 'gesund' aus, hatten aber keinerlei Funktion.

Und erst jetzt wird wieder outbound automatisch die PE-Adresse verwendet, inbound kann ich beide ansprechen und frei die Zieladresse wählen. Meine Änderungen am System: Prüfen, ob ein Router-Neustart was verändert. Hat er nicht. Router-Updates installiert, mit Reboot. Wieder erfolglos. Erst das Ausplanen aller obligatorischen Netzwerk-Tools und Ersetzen durch ein manuelles Starten des Netzwerks (einschließlich der Bridge- (für isolierte Netze) und der macvtap-Devices (LAN-Anbindung der VMs)) via iproute2-Kommandos mit dezidierten Service-Units war dann erfolgreich. Die richtige Fehlerquelle konnte ich nicht finden, weil es schlichtweg überhaupt keine Fehlermeldungen gab ... rein visuell betrachtet sah tatsächlich alles top aus, nur gabs halt keine Funktion bei den PE-Adressen.... die Programme taten bis zum Timeout einfach nix

[TomL]

Nachtrag:

Das Problem ist leider nicht gelöst. Ich kann das jetzt beliebig und zielgerichtet reproduzieren bzw. provozieren. Tatsache ist, IPv6 funktioniert in allen VMs tadellos, solange wie man auf die PE verzichtet. Sobald man die PE aktiviert und eine Temp-Adresse via SLAAC gebildet wird, hat der "Client" Outbound keinen Traffic mehr. Das liegt daran, dass die laufenden Prozesse natürlich gemäß den PE nur diese Adresse verwenden... aber die ist halt tot... also kommen sie nicht raus. Der IPv6-Stack selber arbeitet hingegen tadellos, die VM ist über die MAC-Based-GUA weiterhin jederzeit erreichbar. Das Problem ist auch nicht auf eine VM beschränkt, das passiert in allen. Und ebenfalls bei identischer Konfiguration mit der eines echten Gerätes. Das echte Gerät funktioniert mit der Temp-Addr, die VM nicht. Auch dann nicht, wenn die VM auf einem anderen echten Gerät betrieben wird.

Das eigentliche Problem ist jetzt, ich kann nicht einschätzen, ob das ein Bug ist oder ob es einfach auf einer fehlenden Fähigkeit des virtuellen Devices resp. dessen Treibers beruht.

[mat6937]

Das liegt daran, dass die laufenden Prozesse natürlich gemäß den PE nur diese Adresse verwenden... aber die ist halt tot... also kommen sie nicht raus.

Teste mal im (W)LAN ob Du einen tcp6-Ping mit nping auf einen lauschenden Port machen kannst, unter Verwendung von source-mac, dst-mac und der temporären-source-IPv6-Adresse. Z. B.:

Code: Alles auswählen

nping -6 -c 3 --tcp --flags syn --delay 1s -g 34567 --source-mac <source-MAC-Adresse> -S <temp.-source-IPv6-Adresse> -p <lauschender-Port> --dest-mac <dst-MAC-Adresse> <dst-IPv6-Adresse-im-W/LAN>

EDIT: (am 20.09.19, um 14:24 Uhr/CEST)

Wenn es nicht funktioniert, dann versuch mal auf dem Host mit:

Code: Alles auswählen

sysctl -w net.ipv6.conf.all.proxy_ndp=1
ip -6 neigh add proxy <globale-temp.-IPv6-Adresse-aus-VM> dev <output-Interface-host>

[unitra]

Das ist eine imposante und lange Liste um PrivacyExtensions einzuschalten. Ich wüsste auf Anhieb nicht was jede einzelne Konfigurationszeile bezweckt und ob sie wirklich funktioniert.
Für frühere Linux Kernel gab es Bugreports dass die Einstellung "conf.all" nicht funktioniert. Das war auch meine Erfahrung, siehe:

* https://bugzilla.kernel.org/show_bug.cgi?id=11655
* https://bugzilla.kernel.org/show_bug.cgi?id=9224

Diese Bugs wurden nie gelöst, und ich glaube auch nicht dass sie gelöst sind, weil sich vermutlich keiner die Mühe gemacht hat diese wieder zu eröffen. Ich hatte jedenfalls Schwierigkeiten die Privacy Extensions mit dem Kernel 4.x zu nutzen, wie Du auch.

Moin ...

Code: Alles auswählen

net.ipv6.conf.default.disable_ipv6=0
net.ipv6.conf.default.forwarding=0
net.ipv6.conf.default.autoconf=1
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.default.accept_ra = 1
net.ipv6.conf.default.temp_prefered_lft = 86400
net.ipv6.conf.default.temp_valid_lft = 172800
net.ipv6.conf.default.max_addresses = 16
net.ipv6.conf.default.regen_max_retry = 6
net.ipv6.conf.default.max_desync_factor = 600

net.ipv6.conf.all.disable_ipv6=0
net.ipv6.conf.all.forwarding=0
net.ipv6.conf.all.autoconf=1
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.all.temp_prefered_lft = 86400
net.ipv6.conf.all.temp_valid_lft = 172800
net.ipv6.conf.all.max_addresses = 16
net.ipv6.conf.all.regen_max_retry = 6
net.ipv6.conf.all.max_desync_factor = 600

net.ipv6.conf.enp1s0.disable_ipv6=0
net.ipv6.conf.enp1s0.forwarding=0
net.ipv6.conf.enp1s0.autoconf=1
net.ipv6.conf.enp1s0.use_tempaddr = 2
net.ipv6.conf.enp1s0.accept_ra = 1
net.ipv6.conf.enp1s0.temp_prefered_lft = 86400
net.ipv6.conf.enp1s0.temp_valid_lft = 172800
net.ipv6.conf.enp1s0.max_addresses = 16
net.ipv6.conf.enp1s0.regen_max_retry = 6
net.ipv6.conf.enp1s0.max_desync_factor = 600

Mein Vorschlag um sich sich einer funktionierenden Konfiguration zu nähern. Suche erst einmal die Schnittstelle mit der Du testen möchtest. Von mir aus wlan0 oder eth0, aber nicht beide. Und entferne die ganze ipv6.conf.all Sektion. Weniger ist oft mehr.

Dann versuche es erst einmal mit folgenden Zeilen, hier nur für die enp1s0 Schnittstelle:

Code: Alles auswählen

net.ipv6.conf.enp1s0.use_tempaddr = 2
net.ipv6.conf.enp1s0.use_tempaddr = 86400

Dann wenn es funktioniert, kann man immer noch mehr konfigurieren und zusätzliche Schnittstellen hinzufügen.

[mat6937]

Das ist eine imposante und lange Liste um PrivacyExtensions einzuschalten.

Das ist vom TE aber nicht konfiguriert worden für die PEs bzw. das sind die default-Einstellungen/-Konfiguration aus sysctl bzgl. IPv6.

[unitra]

Wenn es default Einstellungen sind, dann sollte es funktionieren. Fakt ist, es funktioniert nicht. Frage, was macht man in so einem Fall?
Fehler eingrenzen. Das ist was ich mache würde.

Egal ob das defaulteinstellungen sind oder nicht. Man nimmt an sie mögen richtig sein und korrekt. Aber das tut nichts zur Sache. Funktionalität abschalten und verifizieren was passiert.

Das ist eine imposante und lange Liste um PrivacyExtensions einzuschalten.

Das ist vom TE aber nicht konfiguriert worden für die PEs bzw. das sind die default-Einstellungen/-Konfiguration aus sysctl bzgl. IPv6.

[wanne]

Ich weiß nicht, wie du deine KVM startest. Aber per default filtern alle Virtualisierungsumgebungen auf source-addressen.
Hintergrund ist, dass man es als Sicherheitslücke ansieht, wenn man in ner VM beliebige IPs nutzen kann , weil viele auf IP-Basis filtern. (Obwohl eigentlich hinreichend bekannt sein sollte das das wirkungslos ist.) Die wenigsten machen das per iptables.
Entspircht die Source-IP nicht der der, die die VM haben soll wird gefiltert. Das widerspricht grundsätzlich der Idee hinter SLAAC und Privacy-Extentions, wo ja gerade nicht bekannt sein soll, wer welche IP zu wem gehört. Das beißt sich nunmal systembedingt: Entweder der Anbieter hat alles unter Kontrolle und weiß alles oder halt nicht. Beides geht nicht. Deswegen haben alle "Cloud-Images" PE abgeschaltet während die Desktop-Installer sie an haben.

[TomL]

Teste mal im (W)LAN ob Du einen tcp6-Ping mit nping auf einen lauschenden Port machen kannst, unter Verwendung von source-mac, dst-mac und der temporären-source-IPv6-Adresse. Z. B.:

Das war jetzt aufschlußreich.... jeweils 4 Varianten von meinem PC zur VM, also mit beiden meiner IPv6 auf die 2 IPs der VM, und dann das ganze umgekehrt. Ergebnis:

• Von meinem PC ausgehend bekomme ich einen Response auf alle 4 Versuche, auch die Temp-Addr der VM ist von beiden IPv6 meines PC erreichbar
• Von der VM bekomme ich einen Response nur bei Verwendung der MAC-Based-IP, die auf beide Addr. meines PC senden kann

Fazit: Outbound aus der VM geht es nicht mit der temp. Addresse, inbound hingegen sind beide erreichbar.

Das ist eine imposante und lange Liste um PrivacyExtensions einzuschalten.

Das hatte ich zwischenzeitlich schon überarbeitet und mich mit der Überarbeitung auf Defaults verlassen. Ich hatte früher mal mit den Werten rumgespielt, aber die Lifecycle-Werte blieben hier völlig ohne Effekt. Deswegen habe ich die dieser Tage bei der Fehlersuche schon entfernt. Das sieht jetzt wie folgt aus:

Zunächst auf dem Server, der die virtuellen Schnittstellen zur Verfügung stellt. Die Unterscheidung ist imho hier notwendig, weil ich NUR auf eno1 ein Forwarding habe und eno1 das exponierte Interface ist. Weitere Interfaces (sofern sie denn (ggf. auch dynamisch) kommen) brauchen keine PE, das regelt 'default'. Und macvtap ist das Bridge-Interface, das bekommt gar keine IPv6-GUA.

Code: Alles auswählen

net.ipv6.conf.default.disable_ipv6=0
net.ipv6.conf.default.forwarding=0
net.ipv6.conf.default.autoconf=1
net.ipv6.conf.default.use_tempaddr=0
net.ipv6.conf.default.accept_ra=1

net.ipv6.conf.eno1.disable_ipv6=0
net.ipv6.conf.eno1.forwarding=1
net.ipv6.conf.eno1.autoconf=1
net.ipv6.conf.eno1.use_tempaddr=2
net.ipv6.conf.eno1.accept_ra=2

net.ipv6.conf.macvtap0.disable_ipv6=0
net.ipv6.conf.macvtap0.forwarding=0
net.ipv6.conf.macvtap0.autoconf=1
net.ipv6.conf.macvtap0.use_tempaddr=0
net.ipv6.conf.macvtap0.accept_ra=0

Die VM selber ist einfacher gestrickt. Nur das exponierte Interface bekommt eine PE-Adresse.

Code: Alles auswählen

net.ipv6.conf.default.disable_ipv6=0
net.ipv6.conf.default.forwarding=0
net.ipv6.conf.default.autoconf=1
net.ipv6.conf.default.use_tempaddr=0
net.ipv6.conf.default.accept_ra=1

net.ipv6.conf.enp1s0.disable_ipv6=0
net.ipv6.conf.enp1s0.forwarding=0
net.ipv6.conf.enp1s0.autoconf=1
net.ipv6.conf.enp1s0.use_tempaddr=2
net.ipv6.conf.enp1s0.accept_ra=1

[TomL]

Ich weiß nicht, wie du deine KVM startest.

Die VMs werden im Zusammenspiel mit den folgenden 5 Service-Units in vorgegebener Reihenfolge gestartet.
1. Netzwerk grundsätzlich starten: 'eno1' eine Static-IPv4 zuweisen, eno1->UP, Route und default-GW setzen, GUA werden generiert
2. macvtap-Bridge generieren und UP'n (damit werden die VMs regulärer LAN-Client)
3. Normale Brigde für "isolated Subnets" generieren (notwendig für VM <-> Host-Kommunikation oder für Host-IPv4-NAT)
4. Netfilter-Regeln setzen/starten
5. Alle VMs starten

Die VMs beziehen entweder vom DSL-Router ihre IPv4 und das RA und generieren sich eine GUA, oder sie hängen bei den isolierten Subnets für IPv4 am dnsmasq des Host (als DHCP ), oder sie haben einfach eine Static-IPv4.

Der komplette Prozess ist optimal aufeinander abgestimmt und vollständig mit manuellen ip-Statements realisiert. Das heisst, ich starte das gesamte Netzwerk-Setup durchweg mit iproute2-Commands... alles gestartet mit systemd-Service-Units. Ums kurz zu sagen, ich verwende hier keinen networkmanager, kein networkd, kein dhcpcd5, keine /etc/network/interfaces, und schließlich auch nicht das Libvirt-Network, weil das mir im Paketfilter rumfummelt ... damit entzieht sich das meiner Kontrolle ... also nutze ich das auch nicht. Ich habe aber selbstverständlich gepüft, ob möglicherweise mein Customizing die Ursache für das Problem ist... isses aber nicht. Verwende ich das Libvirt-Network mit einem regulären Debian-Setup ist es genau das gleiche.

Aber per default filtern alle Virtualisierungsumgebungen auf source-addressen. ..... Die wenigsten machen das per iptables..

Nee, die machens nicht mit iptables... es werden beim macvtap-Setup definitiv keine Paketfilter-Regeln gesetzt. Nur für die genatteten VMs werden Regeln gebildet... aber genau diese machen mir meine eigenen Regeln strubbelig. Ich habe also sichergestellt, dass der libvirt-manager keine Paketfilterregeln aktivieren kann.

Entspircht die Source-IP nicht der der, die die VM haben soll wird gefiltert. Das widerspricht grundsätzlich der Idee hinter SLAAC und Privacy-Extentions, wo ja gerade nicht bekannt sein soll, wer welche IP zu wem gehört. Das beißt sich nunmal systembedingt: Entweder der Anbieter hat alles unter Kontrolle und weiß alles oder halt nicht. Beides geht nicht. Deswegen haben alle "Cloud-Images" PE abgeschaltet während die Desktop-Installer sie an haben.

Ja, so sieht es fast aus. Wenn die IP nicht zur MAC passt, wird gefiltert... aber eben nicht über den Paketfilter... das muss woanders passieren. Fakt ist, ich habe da definitiv keine Kontrolle... ich kann das Verhalten nicht verändern. Das ist natürlich insofern total bescheuert, wenn man gerade für die VM die PE braucht... weil man gerade für diesen besonderen Job der VM einen täglichen Wechsel haben will. Hier gehts dann wirklich nur noch, IPv6 in dieser VM zu deaktivieren und mit IPv4 wieder über den Router zu natten. *hmmm*

[schorsch_76]

Hast du mal mit net.ipv6.conf.default.forwarding=1 probiert?

[TomL]

Hast du mal mit net.ipv6.conf.default.forwarding=1 probiert?

Nee, nicht wirklich. Ich halte das auch für kontraproduktiv bzw. sogar für schädlich. Das hat -sofern ich das richtig verstanden habe- auf jeden Fall Einfluss auf das RA. Man muss dann eigentlich völlig unnötig wieder das RA overrulen, weil für das RA im Normalfall von forward=disabled ausgegangen wird. Außerdem, in der VM wird eh nicht geforwardet und auf dem Host forwardet nur das exponierte NIC, allen anderen Interfaces sollen das doch gar nicht. Ich glaube also nicht, dass das so gut wäre, forwarding generell zu setzen.

[schorsch_76]

Hast du mal mit net.ipv6.conf.default.forwarding=1 probiert?

Nee, nicht wirklich. Ich halte das auch für kontraproduktiv bzw. sogar für schädlich. Das hat -sofern ich das richtig verstanden habe- auf jeden Fall Einfluss auf das RA. Man muss dann eigentlich völlig unnötig wieder das RA overrulen, weil für das RA im Normalfall von forward=disabled ausgegangen wird. Außerdem, in der VM wird eh nicht geforwardet und auf dem Host forwardet nur das exponierte NIC, allen anderen Interfaces sollen das doch gar nicht. Ich glaube also nicht, dass das so gut wäre, forwarding generell zu setzen.

Der Host muss aber forwarden

[TomL]

Der Host muss aber forwarden

Ja, das tut er doch... guckstu: viewtopic.php?f=30&t=174712#p1217494

[mat6937]

Fazit: Outbound aus der VM geht es nicht mit der temp. Addresse, inbound hingegen sind beide erreichbar.

Nur als Test, versuch doch mal mit:

Code: Alles auswählen

sysctl -w net.ipv6.conf.all.proxy_ndp=1
ip -6 neigh add proxy <globale-temp.-IPv6-Adresse-aus-VM> dev <output-Interface-host>

auf dem Host.

[schorsch_76]

Ich ab das gerade mit einem LXC Container ausprobiert. Bei mir hat das erst mit dem forwarding echo 1 > /proc/sys/net/ipv6/conf/all/forwarding funktioniert. (Buster mit Standardkernel).

Aufbau:

Code: Alles auswählen

    +----------+     +-------------+     +--------+
    |          |     |             |     |        |
    |          |     |             |     |        |
    | FritzBox |     |   Laptop    |     |    LXC |
    |          |     |             |     |        |
    |          <----->eth0      br0<----->eth0    |
    |          |     |             |     |        |
    |          |     |             |     |PE      |
    |          |     |             |     |        |
    |          |     |             |     |        |
    +----------+     +-------------+     +--------+



                 IPV6      NAT66    fd00:ba9c:dd5a:eac1::/64
               Telekom

IP6 Regeln des Hosts:

Code: Alles auswählen

root@M4700:~# ip6tables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all      anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  

http://tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html

Radvd.conf

Code: Alles auswählen

interface br0 { 
        AdvSendAdvert on;
        MinRtrAdvInterval 3; 
        MaxRtrAdvInterval 10;
        prefix fd00:ba9c:dd5a:eac1::/64 { 
                AdvOnLink on; 
                AdvAutonomous on; 
                AdvRouterAddr on; 
        };
};

Netz des Hosts:

Code: Alles auswählen

root@M4700:~# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.160.104  netmask 255.255.255.0  broadcast 192.168.160.255
        inet6 2003:d8:2708:5000:5825:45d5:6ac5:17f3  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1ff7:76f6:ca0b:51a3  prefixlen 64  scopeid 0x20<link>
        ether e0:db:55:ea:52:3f  txqueuelen 1000  (Ethernet)
        RX packets 9517  bytes 6307707 (6.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5448  bytes 793941 (775.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xf7e00000-f7e20000  

Das hier ist der LXC Container:

Code: Alles auswählen

root@BuildRPI:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.119  netmask 255.255.255.0  broadcast 192.168.100.255
        inet6 fd00:ba9c:dd5a:eac1:f42b:1d2a:a8dc:269b  prefixlen 64  scopeid 0x0<global>
        inet6 fd00:ba9c:dd5a:eac1:1893:d6ff:fe57:d754  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1893:d6ff:fe57:d754  prefixlen 64  scopeid 0x20<link>
        ether 1a:93:d6:57:d7:54  txqueuelen 1000  (Ethernet)
        RX packets 956  bytes 124162 (121.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 715  bytes 103424 (101.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@BuildRPI:~# ping6 google.de
PING google.de(fra16s18-in-x03.1e100.net (2a00:1450:4001:81e::2003)) 56 data bytes
64 bytes from fra16s18-in-x03.1e100.net (2a00:1450:4001:81e::2003): icmp_seq=1 ttl=56 time=13.3 ms
64 bytes from fra16s18-in-x03.1e100.net (2a00:1450:4001:81e::2003): icmp_seq=2 ttl=56 time=11.9 ms
^C
--- google.de ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 11.877/12.568/13.259/0.691 ms

[TomL]

Ja klar, das funktioniert hier genauso ... das ist simples Masquerading von rein lokalen IPv6-Adressen, für den über die Bridge kommenden Traffic. Das heisst, Dein Container verwendet nur ULAs und die benötigen sowieso keine Privacy Extensions, weil sie eben nur einen lokalen Scope haben. Das bedeutet, Dein Container selber ist im Internet gar nicht sichtbar, sondern immer hinter dem Host versteckt. Dafür (ich nenns isolated subnet) und für OpenVPN (was ja auch maskiert wird) ist hier auf dem passenden Interface (eno1) forwarding aktiviert.

Das Unterschied zu meinen VMs ist, dass die VMs reguläre LAN-Clients sind,die NICHT via masquerading genattet werden, sondern selber öffentliche IPv6 haben. Das bedeutet, die verwenden keine ULA's (lokal), sondern GUA's (öffentlich), weswegen für IPv6 gar kein Masquerding stattfindet, es sind für die reine Netzfunktion auch keine Paketfilterregeln notwendig, das IPv4-NAT macht wie für andere physische Geräte der DSL-Router. Im Grundegenommen verhalten sich meine VMs wie reguläre physische LAN-Clients.

Ganz nebenbei bemerkt würde ich ja dazu raten, auf Deinem Host auch die PE zu aktivieren. Ohne PE kannst Du Dir eigentlich alle anderen Aktionen zur Verhinderung von Tracking sparen...

[mat6937]

Von der VM bekomme ich einen Response nur bei Verwendung der MAC-Based-IP, die auf beide Addr. meines PC senden kann
Fazit: Outbound aus der VM geht es nicht mit der temp. Addresse, inbound hingegen sind beide erreichbar.

Werden hier (d. h. mit PE) die Datenpakete (aus der VM) gar nicht gesendet oder werden die Datenpakete unterwegs geblockt?
Wie ist aus der VM die Ausgabe von:

Code: Alles auswählen

mtr -6nr --tcp -P 443 -c 1 2a02:02e0:03fe:1001:0302:0000:0000:0000

?

Im Grundegenommen verhalten sich meine VMs wie reguläre physische LAN-Clients.

Wie ist auf deinen VMs die Ausgabe von:

Code: Alles auswählen

ip -6 r | grep -i default

?

[TomL]

Moin

Nur als Test, versuch doch mal mit:

Code: Alles auswählen

sysctl -w net.ipv6.conf.all.proxy_ndp=1
ip -6 neigh add proxy <globale-temp.-IPv6-Adresse-aus-VM> dev <output-Interface-host>

auf dem Host.

Mit dem Versuch tu ich mich ein bisschen schwer.... was wohl auch daran liegt, dass ich den Zusammenhang zum Problem nicht so recht herstellen kann. Eigentlich versuch ich am Server selber nicht zu viel zu schrauben, weil der ja grundsätzlich bestens funktioniert. Und wenn ich das tue, schließe ich vorher immer alle Dienste und natürlich auch die VMs. Gerade was so ein Proxy-Setting angeht, habe ich Sorge wegen Kollateral-Auswirkungen, die ich im Moment nicht greifen kann, sondern nur "als möglich" befürchte.

Auch jetzt, bei der Rumspielerei mit der VM, da verwende ich nur eine nicht-produktive Test-VM, die ich vor gravierenden Änderungen einmal schnell komplett mit der Extension 'sik' kopiere.

Code: Alles auswählen

mtr -6nr --tcp -P 443 -c 1 2a02:02e0:03fe:1001:0302:0000:0000:0000

Den gibts hier nicht.

Code: Alles auswählen

ip -6 r | grep -i default

Auch das ist natürlich fehlerfrei, so wie es sein muss.

Ich will noch mal drauf hinweisen: es gibt KEIN generelles Problem mit dem IPv6-Stack und der Verwendung von 2003::/3-Adressen, auch nicht mit der täglichen Zwangstrennung. Die Bildung neuer IPv6 via RA und SLAAC und die Entfernung der alten nach Ablauf der Lifetime funktioniert völlig unauffällig und automatisch in der VM. Das einzige Problem ist, dass in der VM (und zwar nur dort) die PE-IPv6 ausgehend still und heimlich geblockt wird. Das bedeutet aber nicht, dass der IPv6-Stack platt ist, nein, alles funktioniert unverändert... sowohl die lokalen Adressen (fd00::/16) als auch die globale Mac-Basierte. Ich glaube deshalb nicht mehr, dass das am IPv6-Stack liegt, sondern ich nähere mich immer mehr Wanne's Hinweis/Vermutung an, dass dieser Filterung "working as intended" zugrunde liegt.

Ich lese (oder besser überfliege) ja mehr oder weniger regelmäßig die Libvirt-Liste. Jetzt habe ich einfach mal dort mein Problem geschildert, denn wenn die es nicht wissen, wer dann?

[mat6937]

Nur als Test, versuch doch mal mit:

Code: Alles auswählen

sysctl -w net.ipv6.conf.all.proxy_ndp=1
ip -6 neigh add proxy <globale-temp.-IPv6-Adresse-aus-VM> dev <output-Interface-host>

auf dem Host.

Mit dem Versuch tu ich mich ein bisschen schwer.... was wohl auch daran liegt, dass ich den Zusammenhang zum Problem nicht so recht herstellen kann.

Es geht hier darum, dass das default-v6-gateway (bzw. der Host/v6-Router) durch diese Konfiguration (proxy_ndp) immer in Kenntnis ist bzw. sein soll, von und zu welcher PE-IPv6-Adresse die Datenpakete zuzuordnen sind. Ob das so funktioniert weiß ich nicht, deshalb ein temporärer Test. Und weil es wie Du schreibst eine nicht-produktive Test-VM ist, verstehe ich deine Sorgen bzgl. Kollateral-Auswirkungen nicht ganz.

Code: Alles auswählen

mtr -6nr --tcp -P 443 -c 1 2a02:02e0:03fe:1001:0302:0000:0000:0000

Den gibts hier nicht.

Meinst Du den mtr? Wenn ja, dann kann man den doch installieren:

Code: Alles auswählen

apt-get install mtr-tiny

Das einzige Problem ist, dass in der VM (und zwar nur dort) die PE-IPv6 ausgehend still und heimlich geblockt wird.

Wenn ja, dann geht es doch auch darum festzustellen, wie die PE-IPv6 geblockt wird. Werden die ausgehenden Datenpakete für diese source-PE-IPv6 erst gar nicht produziert oder produziert und nicht gesendet oder gesendet und irgendwo unterwegs geblockt?

EDIT:

BTW: Im Traceroute mit mtr kannst Du auch die source-PE-IPv6-Adresse mit angeben. Z. B.:

Code: Alles auswählen

mtr -6nr --tcp -P 443 -c 1 -a <source-PE-IPv6-Adresse> 2a02:02e0:03fe:1001:0302:0000:0000:0000

Frage: Sind in der VM, die "MAC-Based GUA (2000::/3)" und die "second GUA (PE-Based)" gleichzeitig vorhanden bzw. konfiguriert? Wenn ja, wie ist es wenn nur die "second GUA (PE-Based)" in der VM vorhanden ist bzw. benutzt wird?