IPv6-Datenschutzadressen oder eine RDP-Allowlist: Wählen Sie den Kompromiss

Der Remote-Desktop-Zugriff funktionierte einen Monat lang, dann passte die Allowlist ohne erkennbaren Grund nicht mehr. Der Host war nicht umgezogen, und in der Firewall war nichts bearbeitet worden. Windows bildet weiterhin temporäre IPv6-Adressen mit zufälligen Schnittstellen-Identifikatoren und zieht sie zurück, sodass die Quelladresse, die der Server an einem beliebigen Tag sieht, eine sein kann, die niemand in die Regel geschrieben hat. Das Abschalten dieses Verhaltens behebt die Übereinstimmung und macht den Host zugleich zu einer langlebigen Kennung. Wägen Sie die Alternativen ab, bevor Sie die zweite Hälfte akzeptieren.

Warum die Regel nicht mehr passte

RFC 4941 beschreibt temporäre Adressen: Der Host erzeugt zusätzliche Adressen mit randomisierten Identifikatoren und zieht sie zurück, was einen Beobachter daran hindert, einen Host über Besuche hinweg zu korrelieren. Windows setzt dieses Verhalten um, sodass die gestrige Quelladresse nicht unbedingt die heutige ist. Die vorhersagbare Adresse existiert weiterhin auf der Schnittstelle; sie ist nur nicht die, die eine ausgehende Verbindung bevorzugt.

Deshalb wirkt der Fehler zeitweise statt vollständig. Die Regel passt eine Weile nach dem Anlegen der Adresse, passt nicht mehr, sobald sie zurückgezogen wird, und passt wieder, nachdem jemand sie bearbeitet hat. Nach Quelladresse gruppierte Überwachung und Lizenzprüfungen, die an einer Hostadresse hängen, brechen im selben Rhythmus. Eine Regel, die direkt nach dem Bearbeiten funktioniert und drei Wochen später ausfällt, ist meistens dies und kein Neuladen der Firewall.

Option eins: eine stabile Adresse, weniger Privatsphäre

Die übliche Reparatur schaltet beide Rotationsmechanismen auf dem Host ab: netsh interface ipv6 set privacy state=disabled store=persistent und netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Fügen Sie store=active hinzu, wenn die Änderung ohne Neustart wirksam werden soll, und akzeptieren Sie, dass Sie die Kennung nun netzwerkübergreifend vorhersagbar gemacht haben.

Genau diese Vorhersagbarkeit sollten die Erweiterungen verhindern. Eine Adresse, die dem Host vom Café ins Büro bis nach Hause folgt, ist ein bequemer Filterschlüssel und ein ebenso bequemer Tracking-Schlüssel, und die zweite Eigenschaft überlebt das Ticket, das die erste verlangt hat.

Option zwei: ein Präfix oder einen Namen erlauben

Das /64 statt der vollständigen Adresse zu erlauben, erhält die Rotation und passt zu einer schwächeren, aber oft ehrlichen Aussage: Diese Maschine steht in meinem Heimnetz. Das reicht nicht mehr, sobald dieses Präfix Hosts enthält, die Sie nicht zulassen würden, was bei einem Privatanschluss meist eine kleinere Menge ist, als Leute annehmen. Ein über dynamisches DNS veröffentlichter Name ist leichter zu betreiben, weil der Eintrag dem Host folgt und die Richtlinie als Identität gelesen wird und nicht als Bereich, der mit jedem weiteren Gerät wächst.

Beide Optionen brauchen einen Resolver, dem der Server vertrauen kann, und einen Namen, der nicht trivial fälschbar ist, behandeln Sie sie also als Grundsatzentscheidung über Identität und nicht als kosmetische Änderung der Regel. Notieren Sie, welcher Resolver diesen Namen beantwortet, denn die Regel ist nur so vertrauenswürdig wie der Eintrag dahinter.

Option drei: den Tunnel die Adresse vergeben lassen

Wenn die Verbindung durch ein VPN läuft, das Sie kontrollieren, kann der Server die Adresse aus seinem eigenen Pool ausgeben, und die Allowlist verweist dann auf einen Wert, den der Server wählt, statt auf einen, den der Client bevorzugt. Das funktioniert gut für verwaltete Clients und schlecht für alles, was der Client überschreiben kann, prüfen Sie also, welche Seite in Ihrer Bereitstellung tatsächlich gewinnt.

Die Entscheidung ganz von der Adresse wegzunehmen, hin zu einem Clientzertifikat oder einem authentifizierten Gateway, ist die Option, die skaliert, weil sie nicht länger von einem Wert abhängt, den das Betriebssystem ändern darf.

Wählen Sie mit Blick auf die Tracking-Kosten

Schreiben Sie die vier Optionen gegen die tatsächliche Anforderung auf und wählen Sie eine, statt sie zu kombinieren. Wenn Sie den Datenschutz ohnehin abschalten, beschränken Sie es auf den Host, der ihn braucht, dokumentieren Sie den Grund neben der Regel und erwägen Sie stabile Privatsphäre-Adressierung nach RFC 7217, wo die Plattform sie unterstützt, da sie eine Kennung pro Präfix behält, ohne die hardwareabgeleitete preiszugeben. Aktivieren Sie die Erweiterungen wieder, wenn die Allowlist ersetzt wird.

Halten Sie die Änderung neben der Regel fest, die sie stützt. Ohne diese Notiz findet der nächste Administrator einen Host mit abgeschalteten Datenschutzerweiterungen und ohne Erklärung vor und schaltet sie bei einer Aufräumaktion wieder ein.