IPv6-personvernadresser eller en RDP-tillatelsesliste: velg avveiingen
En roterende midlertidig adresse bryter en RDP-tillatelsesliste, og slår du av personvernet blir verten sporbar. Vei alternativene før du velger noen av dem.
Eksternt skrivebord fungerte i én måned, og så sluttet tillatelseslisten å stemme uten noen synlig grunn. Verten hadde ikke flyttet seg, og ingenting i brannmuren var redigert. Windows fortsetter å danne midlertidige IPv6-adresser med tilfeldige grensesnittidentifikatorer og trekke dem tilbake, så kildeadressen serveren ser en gitt dag kan være en som ingen har skrevet inn i regelen. Slår du av denne atferden, rettes treffet, og samtidig gjøres verten til en langlivet identifikator. Vei alternativene før du godtar den andre halvdelen.
Hvorfor regelen sluttet å stemme
RFC 4941 beskriver midlertidige adresser: verten oppretter flere adresser med tilfeldige identifikatorer og trekker dem tilbake, noe som hindrer en observatør i å korrelere én vert på tvers av besøk. Windows implementerer denne atferden, så gårsdagens kildeadresse er ikke nødvendigvis dagens. Den forutsigbare adressen finnes fortsatt på grensesnittet; den er bare ikke den en utgående forbindelse foretrekker.
Derfor ser feilen periodisk ut i stedet for total. Regelen stemmer en stund etter at adressen er opprettet, slutter å stemme når den trekkes tilbake, og begynner å stemme igjen etter at noen har redigert den. Overvåking gruppert etter kildeadresse og lisenssjekker knyttet til en vertsadresse bryter sammen etter samme tidsplan. En regel som virker rett etter at den er redigert og svikter tre uker senere, er vanligvis dette og ikke en omlasting av brannmuren.
Alternativ én: én stabil adresse, mindre personvern
Den vanlige reparasjonen slår av begge rotasjonsmekanismene på verten: netsh interface ipv6 set privacy state=disabled store=persistent og netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Legg til store=active hvis du vil at endringen skal tre i kraft uten å vente på en omstart, og godta at du nå har gjort identifikatoren forutsigbar på tvers av nettverk.
Nettopp den forutsigbarheten var det utvidelsene ble bygget for å hindre. En adresse som følger verten fra kafé til kontor og hjem, er en praktisk filternøkkel og en like praktisk sporingsnøkkel, og den andre egenskapen overlever billetten som ba om den første.
Alternativ to: tillat et prefiks eller et navn
Å tillate /64 i stedet for full adresse holder rotasjonen intakt og passer med en svakere, men ofte ærlig påstand: denne maskinen er på hjemmenettet mitt. Det slutter å være tilstrekkelig i det øyeblikket prefikset inneholder verter du ikke ville slippe inn, noe som på en forbrukerforbindelse vanligvis er et mindre sett enn folk antar. Et navn publisert via dynamisk DNS er enklere å drifte, fordi posten følger verten, og policyen leses som en identitet i stedet for som et område som vokser hver gang en enhet legges til.
Begge alternativene trenger en resolver serveren kan stole på og et navn som ikke er trivielt forfalskbart, så behandle dem som en prinsippavgjørelse om identitet og ikke som en kosmetisk endring av regelen. Skriv ned hvilken resolver som svarer på det navnet, for regelen er bare så pålitelig som posten bak den.
Alternativ tre: la tunnelen tildele adressen
Hvis forbindelsen går gjennom en VPN du kontrollerer, kan serveren dele ut adressen fra sitt eget basseng, og tillatelseslisten viser da til en verdi serveren velger i stedet for en klienten foretrekker. Det virker bra for administrerte klienter og dårlig for alt klienten kan overstyre, så kontroller hvilken side som faktisk vinner i utrullingen din.
Å flytte beslutningen helt bort fra adressen, til et klientcertifikat eller en autentisert gateway, er alternativet som skalerer, fordi det slutter å avhenge av en verdi operativsystemet har rett til å endre.
Velg med sporingskostnaden i tankene
Skriv de fire alternativene opp mot det faktiske kravet, og velg ett i stedet for å kombinere dem. Hvis du likevel slår av personvern, avgrens det til verten som trenger det, dokumenter grunnen ved siden av regelen, og vurder stabil-personvern-adressering fra RFC 7217 der plattformen støtter det, siden den beholder en identifikator per prefiks uten å avsløre den maskinvareavledede. Slå utvidelsene på igjen når tillatelseslisten erstattes.
Registrer endringen ved siden av regelen den støtter. Uten den noten finner den neste administratoren en vert med personvernutvidelser av og ingen forklaring, og slår dem på igjen under en opprydding.