Adreces de privadesa IPv6 o una llista d'autorització RDP: trieu el compromís

L'accés a l'escriptori remot va funcionar durant un mes, i després la llista d'autorització va deixar de coincidir sense cap motiu visible. L'amfitrió no s'havia mogut i no s'havia editat res del tallafoc. Windows continua formant adreces temporals IPv6 amb identificadors d'interfície aleatoris i retirant-les, de manera que l'adreça d'origen que el servidor veu en un dia qualsevol pot ser una que ningú no va escriure a la regla. Desactivar aquest comportament arregla la coincidència i, alhora, converteix l'amfitrió en un identificador de llarga durada. Peseu les alternatives abans d'acceptar la segona meitat.

Per què la regla va deixar de coincidir

L'RFC 4941 descriu les adreces temporals: l'amfitrió crea adreces addicionals amb identificadors aleatoritzats i les retira, cosa que impedeix que un observador correlacioni un amfitrió entre visites. Windows implementa aquest comportament, així que l'adreça d'origen d'ahir no és necessàriament la d'avui. L'adreça predictible encara existeix a la interfície; simplement no és la que prefereix una connexió sortint.

Per això la fallada sembla intermitent i no total. La regla coincideix durant un temps després de crear-se l'adreça, deixa de coincidir quan es retira i torna a coincidir després que algú l'editi. El monitoratge agrupat per adreça d'origen i les comprovacions de llicència vinculades a una adreça d'amfitrió es trenquen amb el mateix calendari. Una regla que funciona just després d'editar-se i falla tres setmanes més tard sol ser això, no una recàrrega del tallafoc.

Opció u: una adreça estable, menys privadesa

La reparació habitual desactiva tots dos mecanismes de rotació a l'amfitrió: netsh interface ipv6 set privacy state=disabled store=persistent i netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Afegiu store=active si voleu que el canvi tingui efecte sense esperar un reinici, i accepteu que ara heu fet l'identificador predictible entre xarxes.

Aquesta predictibilitat és exactament el que les extensions van ser creades per evitar. Una adreça que segueix l'amfitrió del cafè a l'oficina i a casa és una clau de filtre convenient i una clau de seguiment igualment convenient, i la segona propietat sobreviu al tiquet que va demanar la primera.

Opció dos: permetre un prefix o un nom

Permetre el /64 en lloc de l'adreça completa manté la rotació intacta i encaixa amb una afirmació més feble però sovint honesta: aquesta màquina és a la meva xarxa domèstica. Deixa de ser suficient en el moment que aquest prefix conté amfitrions que no admetríeu, cosa que en una connexió de consum sol ser un conjunt més petit del que la gent suposa. Un nom publicat mitjançant DNS dinàmic és més fàcil d'operar, perquè el registre segueix l'amfitrió i la política es llegeix com una identitat i no com un rang que creix cada cop que s'afegeix un dispositiu.

Totes dues opcions necessiten un resolutor en què el servidor pugui confiar i un nom que no es pugui falsificar trivialment, així que tracteu-les com una decisió de política sobre identitat i no com un canvi cosmètic a la regla. Anoteu quin resolutor respon a aquest nom, perquè la regla és tan fiable com el registre que hi ha al darrere.

Opció tres: deixeu que el túnel assigni l'adreça

Si la connexió travessa una VPN que controleu, el servidor pot repartir l'adreça del seu propi pool, i la llista d'autorització passa a referenciar un valor que tria el servidor i no un que prefereix el client. Això funciona bé per a clients gestionats i malament per a qualsevol cosa que el client pugui anul·lar, així que verifiqueu quin costat guanya realment al vostre desplegament.

Moure la decisió completament fora de l'adreça, cap a un certificat de client o una passarel·la autenticada, és l'opció que escala, perquè deixa de dependre d'un valor que el sistema operatiu té dret a canviar.

Trieu amb el cost de seguiment a la vista

Escriviu les quatre opcions contra el requisit real i trieu-ne una en lloc de combinar-les. Si desactiveu la privadesa igualment, limiteu-ho a l'amfitrió que la necessita, documenteu el motiu al costat de la regla i considereu l'adreçament estable-privat de l'RFC 7217 allà on la plataforma el permeti, ja que manté un identificador per prefix sense exposar el derivat del maquinari. Torneu a habilitar les extensions quan es reemplaci la llista d'autorització.

Registreu el canvi al costat de la regla que dona suport. Sense aquesta nota, el següent administrador troba un amfitrió amb les extensions de privadesa desactivades i sense explicació, i les torna a activar durant una neteja.