IPv6-privatlivsadresser eller en RDP-tilladelsesliste: vælg afvejningen

Fjernskrivebordsadgang fungerede i en måned, og så holdt tilladelseslisten op med at matche uden nogen synlig grund. Værten var ikke flyttet, og intet i firewallen var blevet redigeret. Windows bliver ved med at danne midlertidige IPv6-adresser med tilfældige grænseflade-identifikatorer og trække dem tilbage, så den kildeadresse, serveren ser på en given dag, kan være en, som ingen har skrevet ind i reglen. Slår man den adfærd fra, rettes matchningen, og samtidig gøres værten til en langlivet identifikator. Afvej alternativerne, før du accepterer den anden halvdel.

Hvorfor reglen holdt op med at matche

RFC 4941 beskriver midlertidige adresser: værten opretter ekstra adresser med tilfældige identifikatorer og udfaser dem, hvilket forhindrer en observatør i at korrelere én vært på tværs af besøg. Windows implementerer den adfærd, så gårsdagens kildeadresse er ikke nødvendigvis dagens. Den forudsigelige adresse findes stadig på grænsefladen; den er blot ikke den, en udgående forbindelse foretrækker.

Derfor ser fejlen periodisk ud i stedet for total. Reglen matcher et stykke tid, efter adressen er oprettet, holder op med at matche, når den udfases, og begynder at matche igen, efter nogen har redigeret den. Overvågning grupperet efter kildeadresse og licenskontroller knyttet til en værtadresse bryder sammen efter samme tidsplan. En regel, der virker lige efter, den er redigeret, og svigter tre uger senere, er normalt dette og ikke en genindlæsning af firewallen.

Mulighed et: én stabil adresse, mindre privatliv

Den sædvanlige reparation slår begge roterende mekanismer fra på værten: netsh interface ipv6 set privacy state=disabled store=persistent og netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Tilføj store=active, hvis du vil have ændringen til at virke uden at vente på en genstart, og accepter, at du nu har gjort identifikatoren forudsigelig på tværs af netværk.

Den forudsigelighed er præcis det, udvidelserne blev bygget til at forhindre. En adresse, der følger værten fra café til kontor til hjem, er en bekvem filternøgle og en lige så bekvem sporingsnøgle, og den anden egenskab overlever den billet, der bad om den første.

Mulighed to: tillad et præfiks eller et navn

At tillade /64 i stedet for den fulde adresse holder rotationen intakt og matcher et svagere, men ofte ærligt udsagn: denne maskine er på mit hjemmenetværk. Det holder op med at være tilstrækkeligt i det øjeblik, præfikset indeholder værter, du ikke ville lukke ind, hvilket på en forbrugerforbindelse normalt er et mindre sæt, end folk antager. Et navn offentliggjort via dynamisk DNS er lettere at drive, fordi posten følger værten, og politikken læses som en identitet snarere end som et interval, der vokser, hver gang en enhed tilføjes.

Begge muligheder kræver en resolver, serveren kan stole på, og et navn, der ikke let kan forfalskes, så behandl dem som en politisk beslutning om identitet snarere end som en kosmetisk ændring af reglen. Skriv ned, hvilken resolver der svarer på det navn, for reglen er kun så troværdig som posten bag den.

Mulighed tre: lad tunnelen tildele adressen

Hvis forbindelsen går gennem en VPN, du kontrollerer, kan serveren udlevere adressen fra sin egen pulje, og tilladelseslisten refererer så til en værdi, serveren vælger, snarere end en, klienten foretrækker. Det virker godt for administrerede klienter og dårligt for alt, klienten kan tilsidesætte, så bekræft, hvilken side der faktisk vinder i din udrulning.

At flytte beslutningen helt væk fra adressen, til et klientcertifikat eller en autentificeret gateway, er den mulighed, der skalerer, fordi den holder op med at afhænge af en værdi, som operativsystemet har ret til at ændre.

Vælg med sporingsomkostningen for øje

Skriv de fire muligheder op mod det faktiske krav, og vælg én i stedet for at kombinere dem. Hvis du alligevel slår privatliv fra, så afgræns det til den vært, der har brug for det, dokumentér årsagen ved siden af reglen, og overvej stabil-privat adressering fra RFC 7217, hvor platformen understøtter det, da den beholder en identifikator for hvert præfiks uden at afsløre den hardwareafledte. Genaktiver udvidelserne, når tilladelseslisten erstattes.

Registrér ændringen ved siden af den regel, den understøtter. Uden den note finder den næste administrator en vært med privatlivsudvidelser slået fra og ingen forklaring og slår dem til igen under en oprydning.