IPv6-privatecadresoj aŭ RDP-permeslisto: elektu la kompromison
Rotacianta provizora adreso rompas RDP-permesliston, kaj malŝalti privatecon igas la gastigan komputilon spurebla. Pripensu la alternativojn antaŭ ol elekti iun ajn.
Fora labortabla aliro funkciis dum monato, kaj poste la permeslisto ĉesis kongrui sen iu ajn videbla kaŭzo. La gastiga komputilo ne moviĝis kaj nenio en la fajroŝirmilo estis redaktita. Windows daŭre formas provizorajn IPv6-adresojn kun hazardaj interfacaj identigiloj kaj retiras ilin, do la fonta adreso, kiun la servilo vidas iun ajn tagon, povas esti unu, kiun neniu skribis en la regulon. Malŝalti tiun konduton riparas la kongruon kaj samtempe igas la gastigan komputilon longdaŭra identigilo. Pripensu la alternativojn antaŭ ol akcepti la duan duonon.
Kial la regulo ĉesis kongrui
RFC 4941 priskribas provizorajn adresojn: la gastiga komputilo kreas pliajn adresojn kun hazardigitaj identigiloj kaj eksvalidigas ilin, kio malhelpas observanton korelacii unu gastigan komputilon tra vizitoj. Windows efektivigas tiun konduton, do la hieraŭa fonta adreso ne nepre estas la hodiaŭa. La antaŭvidebla adreso ankoraŭ ekzistas sur la interfaco; ĝi simple ne estas tiu, kiun elira konekto preferas.
Tial la fiasko aspektas intermita anstataŭ totala. La regulo kongruas dum iom da tempo post kiam la adreso kreiĝas, ĉesas kongrui kiam ĝi retiriĝas, kaj rekomencas kongrui post kiam iu ĝin redaktas. Monitorado grupigita laŭ fonta adreso kaj licencaj kontroloj ligitaj al gastiga adreso rompiĝas laŭ la sama horaro. Regulo, kiu funkcias tuj post redaktado kaj fiaskas tri semajnojn poste, kutime estas ĉi tio, ne reŝarĝo de la fajroŝirmilo.
Opcio unu: unu stabila adreso, malpli da privateco
La kutima riparo malŝaltas ambaŭ rotaciajn mekanismojn sur la gastiga komputilo: netsh interface ipv6 set privacy state=disabled store=persistent kaj netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Aldonu store=active se vi volas, ke la ŝanĝo efiku sen atendi restartigon, kaj akceptu, ke vi nun igis la identigilon antaŭvidebla trans retoj.
Tiu antaŭvidebleco estas ĝuste tio, kion la etendaĵoj estis konstruitaj por malhelpi. Adreso, kiu sekvas la gastigan komputilon de kafejo al oficejo al hejmo, estas oportuna filtrila ŝlosilo kaj same oportuna spurila ŝlosilo, kaj la dua eco postvivas la bileton, kiu petis la unuan.
Opcio du: permesi prefikson aŭ nomon
Permesi la /64 anstataŭ la plenan adreson konservas la rotacion sendifekta kaj kongruas kun pli malforta sed ofte honesta aserto: ĉi tiu maŝino estas en mia hejma reto. Ĝi ĉesas sufiĉi en la momento, kiam tiu prefikso enhavas gastigajn komputilojn, kiujn vi ne akceptus, kio ĉe konsumanta konekto kutime estas pli malgranda aro ol homoj supozas. Nomo publikigita per dinamika DNS estas pli facile funkciigebla, ĉar la rikordo sekvas la gastigan komputilon kaj la politiko legiĝas kiel identeco anstataŭ kiel gamo, kiu kreskas ĉiufoje kiam aparato aldoniĝas.
Ambaŭ opcioj bezonas solvilon, kiun la servilo povas fidi, kaj nomon, kiu ne estas triviale falsigebla, do traktu ilin kiel politikan decidon pri identeco anstataŭ kiel kosmetikan ŝanĝon de la regulo. Notu, kiu solvilo respondas al tiu nomo, ĉar la regulo estas nur tiom fidinda kiom la rikordo malantaŭ ĝi.
Opcio tri: lasu la tunelon atribui la adreson
Se la konekto trapasas VPN-on, kiun vi kontrolas, la servilo povas disdoni la adreson el sia propra provizo, kaj la permeslisto tiam referencas valoron, kiun elektas la servilo, anstataŭ unu, kiun preferas la kliento. Tio bone funkcias por administrataj klientoj kaj malbone por io ajn, kion la kliento povas anstataŭigi, do kontrolu, kiu flanko efektive venkas en via deplojo.
Translokigi la decidon tute for de la adreso, al klienta atestilo aŭ al aŭtentikigita enirejo, estas la opcio, kiu skaliĝas, ĉar ĝi ĉesas dependi de valoro, kiun la operaciumo rajtas ŝanĝi.
Elektu konsiderante la koston de spurado
Skribu la kvar opciojn kontraŭ la fakta postulo, kaj elektu unu anstataŭ kombini ilin. Se vi tamen malŝaltas privatecon, limigu ĝin al la gastiga komputilo, kiu bezonas ĝin, dokumentu la kialon apud la regulo, kaj pripensu stabilan-privatecan adresadon el RFC 7217 tie, kie la platformo subtenas ĝin, ĉar ĝi konservas identigilon por prefikso sen malkaŝi la hardvare derivitan. Reaktivigu la etendaĵojn kiam la permeslisto estos anstataŭigita.
Registru la ŝanĝon apud la regulo, kiun ĝi subtenas. Sen tiu noto la sekva administranto trovas gastigan komputilon kun privatecaj etendaĵoj malŝaltitaj kaj sen klarigo, kaj reŝaltas ilin dum purigado.