Enderezos de privacidade IPv6 ou unha lista de permitidos RDP: escolla o equilibrio

O acceso ao escritorio remoto funcionou durante un mes, e logo a lista de permitidos deixou de coincidir sen ningunha razón visible. O host non se movera e nada do firewall se editara. Windows segue formando enderezos temporais IPv6 con identificadores de interface aleatorios e retirándoos, así que o enderezo de orixe que ve o servidor nun día calquera pode ser un que ninguén escribiu na regra. Desactivar ese comportamento arranxa a coincidencia e converte o host nun identificador de longa vida ao mesmo tempo. Pondere as alternativas antes de aceptar a segunda metade.

Por que a regra deixou de coincidir

O RFC 4941 describe os enderezos temporais: o host crea enderezos adicionais con identificadores aleatorizados e retíraos, o que impide que un observador correlacione un host entre visitas. Windows implementa ese comportamento, así que o enderezo de orixe de onte non é necesariamente o de hoxe. O enderezo previsible segue existindo na interface; simplemente non é o que prefire unha conexión saínte.

Por iso o fallo parece intermitente e non total. A regra coincide durante un tempo despois de crearse o enderezo, deixa de coincidir cando se retira e volve coincidir despois de que alguén o edite. A monitorización agrupada por enderezo de orixe e as comprobacións de licenza ligadas a un enderezo de host rompen co mesmo calendario. Unha regra que funciona xusto despois de editada e falla tres semanas máis tarde adoita ser isto, non unha recarga do firewall.

Opción un: un enderezo estable, menos privacidade

A reparación habitual desactiva os dous mecanismos de rotación no host: netsh interface ipv6 set privacy state=disabled store=persistent e netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Engade store=active se queres que o cambio teña efecto sen esperar a un reinicio, e acepta que agora fixeches que o identificador sexa previsible entre redes.

Esa previsibilidade é exactamente o que as extensións se construíron para evitar. Un enderezo que segue o host do café á oficina e á casa é unha clave de filtrado cómoda e unha clave de seguimento igual de cómoda, e a segunda propiedade sobrevive ao ticket que pediu a primeira.

Opción dous: permitir un prefixo ou un nome

Permitir o /64 en lugar do enderezo completo mantén a rotación intacta e encaixa cunha afirmación máis débil pero a miúdo honesta: esta máquina está na miña rede doméstica. Deixa de ser suficiente no momento en que ese prefixo contén hosts que non admitirías, o que nunha conexión de consumo adoita ser un conxunto máis pequeno do que a xente supón. Un nome publicado mediante DNS dinámico é máis doado de operar, porque o rexistro segue o host e a política lese como unha identidade en lugar de como un rango que medra cada vez que se engade un dispositivo.

As dúas opcións necesitan un resolutor no que o servidor poida confiar e un nome que non se poida falsificar trivialmente, así que trátaas como unha decisión de política sobre identidade e non como un cambio cosmético na regra. Anota que resolutor responde a ese nome, porque a regra é tan fiable como o rexistro que hai detrás.

Opción tres: deixa que o túnel asigne o enderezo

Se a conexión atravesa unha VPN que controlas, o servidor pode repartir o enderezo do seu propio conxunto, e a lista de permitidos pasa a referenciar un valor que elixe o servidor en lugar dun que prefire o cliente. Iso funciona ben para clientes xestionados e mal para calquera cousa que o cliente poida anular, así que verifica que lado gaña realmente no teu despregamento.

Mover a decisión completamente fóra do enderezo, cara a un certificado de cliente ou unha pasarela autenticada, é a opción que escala, porque deixa de depender dun valor que o sistema operativo ten dereito a cambiar.

Escolla co custo de seguimento á vista

Escribe as catro opcións fronte ao requisito real e escolle unha en lugar de combinalas. Se desactivas a privacidade de todos os xeitos, limítaa ao host que a necesita, documenta o motivo xunto á regra e considera o enderezamento estable-privado do RFC 7217 onde a plataforma o admita, xa que conserva un identificador por prefixo sen expor o derivado do hardware. Volve habilitar as extensións cando se substitúa a lista de permitidos.

Rexistra o cambio xunto á regra que respalda. Sen esa nota, o seguinte administrador atopa un host coas extensións de privacidade desactivadas e sen explicación, e vólveas activar durante unha limpeza.