IPv6-Probleme nach Verbindungsabruch

[franco]

Ja, sollte so passen. Merci!


Grüsse
Franco

[glasi]

Mal eben kurz getestet auf OPNsense 21.1.7_1.

Sieht gut aus. Die alten (ungültigen) IPv6-Adressen wurden restlos von der Schnittstelle entfernt.

[franco]

Huch, die sollten doch aber mit dem letzten Patch nur noch als deprecated markiert werden?

Komplettes Entfernen hat leider Seiteneffekte die wir vermeiden wollen.


Grüsse
Franco

[glasi]

Lass mich kurz noch was testen...

[glasi]

Ok, mein erster Test war natürlich Müll. Netzwerkkabel vom Glasfasermodem abziehen war zu einfach gedacht. Da verschwindet ja das ganze pppoe0-Interface.

Mal schnell das ganze über den Switch geleitet, so dass das pppoe0-Interface nicht verloren geht, wenn ich das Netzwerkkabel ziehe.

Und ja, die alten Adressen werden nun als deprecated markiert. Funktioniert also wie gedacht.

Sorry für die Verwirrung.

[schnipp]

Ich habe die Befürchtung, dass das das alleinige Markieren von IPv6-Adressen nicht zum Erfolg führen wird.

Ich habe auf Version 21.1.8_1 aktualisiert und den Patch eingespielt. Die IPv6-Adressen werden wie hier diskutiert als "deprecated" markiert. Jedoch funktioniert das Internet nach dem Verbindungsab- und aufbau nicht mehr, da diverse Dienste (u.a. DNS) weiterhin die als "deprecated" markierten Adressen verwenden, welche der ISP als nicht mehr gültig anssieht.

Sind denn noch weitere Änderungen eingeflossen?

[franco]

> da diverse Dienste (u.a. DNS) weiterhin die als "deprecated" markierten Adressen verwenden

Das klingt seltsam. Welche Dienste sind das denn... die von der OPNsense gesteuert werden?


Grüsse
Franco

[schnipp]

> da diverse Dienste (u.a. DNS) weiterhin die als "deprecated" markierten Adressen verwenden

Das klingt seltsam. Welche Dienste sind das denn... die von der OPNsense gesteuert werden?

Ich hatte bisher nur einen kurzen Test gemacht, dabei sind mir die DNS-Anfragen (Unbound) aufgefallen.

Für mich ist das Verhalten jedoch keineswegs seltsam. Als „deprecated“ markierte Adressen sind nicht automatisch ungültig. Sie sind für Anwendungen lediglich ein Hinweis, diese nicht mehr für neue Verbindungen zu verwenden. Auch werden diese Adressen bei der automatischen Quelladressierung möglichst nicht mehr verwendet. Bereits bestehende Sockets verwenden allerdings weiterhin ihre mittlerweile als „veraltet“ markierten Adressen. Applikationen, welche veraltete Quelladressen explizit bei der Erstellung neuer Sockets angeben, werden diese vermutlich auch zugewiesen bekommen.

Daher bin ich der Überzeugung, dass alle Adressen mit einen ungültigen IPv6-Präfix weiterhin von der Schnittstelle entfernt werden müssen.

Komplettes Entfernen hat leider Seiteneffekte die wir vermeiden wollen.

Welche Seiteneffekte hattest Du denn beim Entfernen der Adressen beobachtet?

[franco]

Na ja, der Seiteneffekt, dass die statische Konfiguration so gelöscht wird wenn wir nicht auf autoconf gehen. Einen Patch minimalinvasiv zu gestalten sollte schon die normale Herangehensweise sein.

Abgesehen davon war es gut zu wissen, dass deprecated nicht reicht und die Sockets offen bleiben. Es bedeutet ja letztlich dass der ISP seine eigene Zusage vergisst und die vorherige IP nicht weiter durchreicht. Ob das jetzt RFC-konform ist mag ich nicht beurteilen.

Und die eine Zeile zu ändern ist jetzt auch kein Akt mit dem Wissen und Vorbereitung die wir haben.


Grüsse
Franco

[franco]

PS: https://github.com/opnsense/core/commit/dac9a74479a5

[schnipp]

Na ja, der Seiteneffekt, dass die statische Konfiguration so gelöscht wird wenn wir nicht auf autoconf gehen. Einen Patch minimalinvasiv zu gestalten sollte schon die normale Herangehensweise sein.

Das ist in der Tat ein Problem, sofern man eine statische Konfiguration verwendet. Daran hatte ich nicht gedacht. Vermutlich wird man es nur durch Implementierung eines endlichen Zustandsautomaten für die Einwahlverbindungen sauber hinbekommen, welcher die unterschiedlichen Szenarien berücksichtigt. Der Umbau wäre vermutlich erst einmal aufwendig.

Abgesehen davon war es gut zu wissen, dass deprecated nicht reicht und die Sockets offen bleiben. Es bedeutet ja letztlich dass der ISP seine eigene Zusage vergisst und die vorherige IP nicht weiter durchreicht. Ob das jetzt RFC-konform ist mag ich nicht beurteilen.

Die Problematik mit dem dynamischen IPv6-Präfix setzt sich im Prinzip analog der Problematik mit der dynamischen IPv4-Adresse fort. Wobei die Probleme bei letzterem auf der NAT-Tabelle liegen, was wir vor längerer Zeit mit der Option "Dynamic State Reset" (Firewall -> Settings -> Advanced) gelöst hatten.

Und die eine Zeile zu ändern ist jetzt auch kein Akt mit dem Wissen und Vorbereitung die wir haben.

Für den neuen Test müsste ich den alten Patch deinstallieren und danach den neuen installieren?

[franco]

Für den neuen Test müsste ich den alten Patch deinstallieren und danach den neuen installieren?

Ja, genau

Oder:

# opnsense-revert opnsense
# opnsense-patch dac9a7447


Grüsse
Franco

[schnipp]

Mit dem neuen Patch funktioniert es wieder

Wäre denn der Vorschlag, zukünftig einem Zustandsautomaten zu implementieren, eine Idee?

Viele Grüße,
Schnipp