Adresa privatësie IPv6 ose një listë lejimesh RDP: zgjidhni kompromisin

Aksesi në desktopin në distancë funksionoi një muaj, dhe pastaj lista e lejeve pushoi së përputhuri pa asnjë arsye të dukshme. Host-i nuk ishte zhvendosur dhe asgjë në firewall nuk ishte redaktuar. Windows vazhdon të formojë adresa të përkohshme IPv6 me identifikues ndërfaqeje të rastësishëm dhe t'i tërheqë ato, kështu që adresa burimore që serveri sheh në çdo ditë të caktuar mund të jetë një që askush nuk e ka shkruar në rregull. Fikja e këtij sjelljeje rregullon përputhjen dhe në të njëjtën kohë e kthen host-in në një identifikues jetëgjatë. Peshojini alternativat përpara se të pranoni gjysmën e dytë.

Pse rregulli pushoi së përputhuri

RFC 4941 përshkruan adresat e përkohshme: host-i krijon adresa shtesë me identifikues të rastësishëm dhe i tërheq ato, gjë që e pengon një vëzhgues të korrelojë një host mes vizitave. Windows e zbaton këtë sjellje, prandaj adresa burimore e djeshme nuk është domosdoshmërisht ajo e sotmja. Adresa e parashikueshme ekziston ende në ndërfaqe; thjesht nuk është ajo që preferon një lidhje dalëse.

Prandaj dështimi duket i ndërprerë dhe jo i plotë. Rregulli përputhet për një kohë pasi adresa krijohet, pushon së përputhuri kur ajo tërhiqet, dhe fillon të përputhet përsëri pasi dikush e redakton atë. Monitorimi i grupuar sipas adresës burimore dhe kontrollet e licencës të lidhura me një adresë hosti prishen sipas të njëjtit orar. Një rregull që funksionon menjëherë pas redaktimit dhe dështon tre javë më vonë është zakonisht kjo, jo një ringarkim i firewall-it.

Opsioni një: një adresë e qëndrueshme, më pak privatësi

Riparimi i zakonshëm fik të dy mekanizmat e rrotullimit në host: netsh interface ipv6 set privacy state=disabled store=persistent dhe netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Shtoni store=active nëse dëshironi që ndryshimi të hyjë në fuqi pa pritur një rinisje, dhe pranoni që tani e keni bërë identifikuesin të parashikueshëm mes rrjeteve.

Pikërisht kjo parashikueshmëri është ajo që shtesat u ndërtuan për të parandaluar. Një adresë që ndjek host-in nga kafja në zyrë dhe në shtëpi është një çelës filtrimi i përshtatshëm dhe një çelës gjurmimi po aq i përshtatshëm, dhe vetia e dytë mbijeton më shumë se bileta që kërkoi të parën.

Opsioni dy: lejoni një prefiks ose një emër

Lejimi i /64 në vend të adresës së plotë e mban rrotullimin të paprekur dhe përputhet me një pohim më të dobët, por shpesh të sinqertë: kjo makinë është në rrjetin tim të shtëpisë. Ai pushon së qeni i mjaftueshëm në momentin kur ai prefiks përmban host-e që nuk do t'i pranonit, gjë që në një lidhje konsumatori është zakonisht një grup më i vogël sesa njerëzit mendojnë. Një emër i publikuar përmes DNS dinamik është më i lehtë për t'u operuar, sepse regjistri ndjek host-in dhe politika lexohet si identitet dhe jo si një interval që rritet sa herë shtohet një pajisje.

Të dy opsionet kërkojnë një zgjidhës që serveri mund t'i besojë dhe një emër që nuk falsifikohet lehtë, prandaj trajtojini si një vendim politike për identitetin dhe jo si një ndryshim kozmetik i rregullit. Shkruani cili zgjidhës përgjigjet për atë emër, sepse rregulli është vetëm aq i besueshëm sa regjistri pas tij.

Opsioni tre: lëreni tunelin të caktojë adresën

Nëse lidhja kalon përmes një VPN që ju kontrolloni, serveri mund ta japë adresën nga grupi i vet, dhe lista e lejeve i referohet atëherë një vlere që zgjedh serveri dhe jo një që preferon klienti. Kjo funksionon mirë për klientët e menaxhuar dhe keq për çdo gjë që klienti mund të anashkalojë, prandaj verifikoni cila palë fiton vërtet në vendosjen tuaj.

Zhvendosja e vendimit plotësisht jashtë adresës, drejt një certifikate klienti ose një portë të autentikuar, është opsioni që shkallëzohet, sepse pushon së varuri nga një vlerë që sistemi operativ ka të drejtë ta ndryshojë.

Zgjidhni duke pasur parasysh koston e gjurmimit

Shkruani katër opsionet kundrejt kërkesës reale dhe zgjidhni një në vend që t'i kombinoni. Nëse gjithsesi e fikni privatësinë, kufizojeni atë tek host-i që ka nevojë, dokumentoni arsyen pranë rregullit dhe merrni parasysh adresimin e qëndrueshëm-privat nga RFC 7217 aty ku platforma e mbështet, sepse ruan një identifikues për çdo prefiks pa ekspozuar atë të nxjerrë nga hardueri. Ripërfshini shtesat kur lista e lejeve zëvendësohet.

Regjistroni ndryshimin pranë rregullit që mbështet. Pa atë shënim, administratori tjetër gjen një host me shtesat e privatësisë të fikura dhe pa shpjegim, dhe i ndez përsëri gjatë një pastrimi.