IPv6-privacyadressen of een RDP-allowlist: kies de afweging

Extern-bureaubladtoegang werkte een maand, en toen stopte de allowlist met matchen zonder zichtbare reden. De host was niet verhuisd en er was niets in de firewall aangepast. Windows blijft tijdelijke IPv6-adressen vormen met willekeurige interface-identificaties en die weer intrekken, dus het bronadres dat de server op een gegeven dag ziet, kan er een zijn die niemand in de regel heeft geschreven. Dat gedrag uitschakelen herstelt de match en maakt de host tegelijk een langlevende identificatie. Weeg de alternatieven voordat je de tweede helft accepteert.

Waarom de regel niet meer matchte

RFC 4941 beschrijft tijdelijke adressen: de host maakt extra adressen met gerandomiseerde identificaties en trekt ze in, wat voorkomt dat een waarnemer één host over bezoeken heen correleert. Windows implementeert dat gedrag, dus het bronadres van gisteren is niet noodzakelijk dat van vandaag. Het voorspelbare adres bestaat nog steeds op de interface; het is alleen niet het adres dat een uitgaande verbinding verkiest.

Daarom lijkt de storing onregelmatig in plaats van volledig. De regel matcht een tijdje nadat het adres is aangemaakt, stopt met matchen zodra het wordt ingetrokken en begint weer te matchen nadat iemand het heeft bewerkt. Monitoring gegroepeerd op bronadres en licentiescontroles die aan een hostadres hangen, breken volgens hetzelfde schema. Een regel die direct na bewerken werkt en drie weken later faalt, is meestal dit en niet een herlaad van de firewall.

Optie één: één stabiel adres, minder privacy

De gebruikelijke reparatie schakelt beide rotatiemechanismen op de host uit: netsh interface ipv6 set privacy state=disabled store=persistent en netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Voeg store=active toe als je wilt dat de wijziging zonder herstart ingaat, en accepteer dat je de identificatie nu voorspelbaar hebt gemaakt tussen netwerken.

Precies die voorspelbaarheid wilden de extensies voorkomen. Een adres dat de host van café naar kantoor en naar huis volgt, is een handige filtersleutel en een even handige volgsleutel, en de tweede eigenschap overleeft het ticket dat om de eerste vroeg.

Optie twee: een prefix of een naam toestaan

De /64 in plaats van het volledige adres toestaan houdt de rotatie intact en past bij een zwakkere maar vaak eerlijke bewering: deze machine staat op mijn thuisnetwerk. Het houdt op voldoende te zijn op het moment dat die prefix hosts bevat die je niet zou toelaten, wat op een consumentenverbinding meestal een kleinere verzameling is dan mensen aannemen. Een naam die via dynamische DNS wordt gepubliceerd, is eenvoudiger te beheren, omdat het record de host volgt en het beleid als een identiteit leest in plaats van als een bereik dat groeit telkens wanneer een apparaat wordt toegevoegd.

Beide opties hebben een resolver nodig die de server kan vertrouwen en een naam die niet triviaal te vervalsen is, dus behandel ze als een beleidsbeslissing over identiteit en niet als een cosmetische wijziging van de regel. Noteer welke resolver die naam beantwoordt, want de regel is alleen zo betrouwbaar als het record erachter.

Optie drie: laat de tunnel het adres toewijzen

Als de verbinding door een VPN loopt die je beheert, kan de server het adres uit zijn eigen pool uitdelen, en de allowlist verwijst dan naar een waarde die de server kiest in plaats van een die de client verkiest. Dat werkt goed voor beheerde clients en slecht voor alles wat de client kan overschrijven, dus controleer welke kant in jouw uitrol echt wint.

De beslissing volledig van het adres afhalen, naar een clientcertificaat of een geauthenticeerde gateway, is de optie die schaalt, omdat ze niet langer afhangt van een waarde die het besturingssysteem mag wijzigen.

Kies met de volgkosten in het vizier

Schrijf de vier opties op tegen de werkelijke eis, en kies er één in plaats van ze te combineren. Als je privacy toch uitzet, beperk het dan tot de host die het nodig heeft, documenteer de reden naast de regel, en overweeg stabiele-privacyadressering uit RFC 7217 waar het platform dat ondersteunt, omdat het een identificatie per prefix behoudt zonder de van hardware afgeleide prijs te geven. Zet de extensies weer aan wanneer de allowlist wordt vervangen.

Leg de wijziging vast naast de regel die ze ondersteunt. Zonder die notitie treft de volgende beheerder een host met privacy-extensies uit en geen uitleg aan, en zet ze tijdens een opruiming weer aan.