IPv6-privaatheidadresse of 'n RDP-toelatingslys: kies die afweging

Toegang tot die afgeleë lessenaar het 'n maand lank gewerk, en toe het die toelatingslys opgehou pas sonder enige sigbare rede. Die gasheer het nie beweeg nie en niks in die vuurmuur is verander nie. Windows hou aan om IPv6-tydelike adresse met ewekansige koppelvlak-identifiseerders te vorm en hulle weer aftree, so die bronadres wat die bediener op enige gegewe dag sien, kan een wees wat niemand in die reël geskryf het nie. Om daardie gedrag af te skakel, maak die passing reg en verander terselfdertyd die gasheer in 'n langdurige identifiseerder. Weeg die alternatiewe voordat jy die tweede helfte aanvaar.

Waarom die reël opgehou pas het

RFC 4941 beskryf tydelike adresse: die gasheer skep bykomende adresse met gerandomiseerde identifiseerders en stel hulle uit diens, wat 'n waarnemer verhoed om een gasheer oor besoeke heen te korreleer. Windows implementeer daardie gedrag, so die bronadres van gister is nie noodwendig dié van vandag nie. Die voorspelbare adres bestaan steeds op die koppelvlak; dit is bloot nie die een wat 'n uitgaande verbinding verkies nie.

Dit is waarom die fout onreëlmatig eerder as totaal lyk. Die reël pas 'n ruk nadat die adres geskep is, hou op pas sodra dit uit diens gestel word, en begin weer pas nadat iemand dit verander. Monitering gegroepeer volgens bronadres en lisensiekontroles wat op 'n gasheeradres geskoei is, breek op dieselfde skedule. 'n Reël wat reg werk net nadat dit verander is en drie weke later misluk, is gewoonlik dit, nie 'n vuurmuur-herlaai nie.

Opsie een: een stabiele adres, minder privaatheid

Die gewone herstel skakel albei roterende meganismes op die gasheer af: netsh interface ipv6 set privacy state=disabled store=persistent en netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Voeg store=active by as jy wil hê die verandering moet in werking tree sonder om op 'n herbegin te wag, en aanvaar dat jy die identifiseerder nou oor netwerke heen voorspelbaar gemaak het.

Daardie voorspelbaarheid is presies wat die uitbreidings gebou is om te voorkom. 'n Adres wat die gasheer van kafee na kantoor na huis volg, is 'n gerieflike filtersleutel en 'n ewe gerieflike naspeuringsleutel, en die tweede eienskap oorleef die kaartjie wat om die eerste gevra het.

Opsie twee: laat 'n voorvoegsel of 'n naam toe

Om die /64 eerder as die volledige adres toe te laat, hou die rotasie ongeskonde en pas by 'n swakker maar dikwels eerlike bewering: hierdie masjien is op my tuisnetwerk. Dit hou op voldoende wees sodra daardie voorvoegsel gashere bevat wat jy nie sou toelaat nie, wat op 'n verbruikersverbinding gewoonlik 'n kleiner stel is as wat mense aanneem. 'n Naam wat deur dinamiese DNS gepubliseer word, is makliker om te bestuur, want die rekord volg die gasheer en die beleid lees as 'n identiteit eerder as 'n reeks wat groei elke keer as 'n toestel bygevoeg word.

Albei opsies benodig 'n oplosser wat die bediener kan vertrou en 'n naam wat nie maklik vervals kan word nie, so hanteer hulle as 'n beleidsbeslissing oor identiteit eerder as 'n kosmetiese verandering aan die reël. Skryf neer watter oplosser daardie naam beantwoord, want die reël is net so betroubaar soos die rekord agter dit.

Opsie drie: laat die tonnel die adres toeken

As die verbinding deur 'n VPN gaan wat jy beheer, kan die bediener die adres uit sy eie poel uitdeel, en die toelatingslys verwys dan na 'n waarde wat die bediener kies eerder as een wat die kliënt verkies. Dit werk goed vir bestuurde kliënte en sleg vir enigiets wat die kliënt kan oorheers, so verifieer watter kant werklik wen in jou ontplooiing.

Om die besluit heeltemal van die adres af te skuif, na 'n kliëntsertifikaat of 'n geauthentiseerde poort, is die opsie wat skaal, want dit hou op om afhanklik te wees van 'n waarde wat die bedryfstelsel geregtig is om te verander.

Kies met die naspeuringskoste in die oog

Skryf die vier opsies teen die werklike vereiste neer, en kies een eerder as om hulle te kombineer. As jy privaatheid tog afskakel, beperk dit tot die gasheer wat dit nodig het, dokumenteer die rede langs die reël, en oorweeg stabiele privaatheidadressering uit RFC 7217 waar die platform dit ondersteun, want dit hou 'n identifiseerder per voorvoegsel sonder om die een wat van hardeware afgelei is, bloot te stel. Heraktiveer die uitbreidings wanneer die toelatingslys vervang word.

Teken die verandering langs die reël aan wat dit ondersteun. Sonder daardie nota vind die volgende administrateur 'n gasheer met privaatheidsuitbreidings af en geen verduideliking nie, en skakel hulle weer aan tydens 'n opruiming.