Direcciones de privacidad IPv6 o una lista de permitidos RDP: elija el equilibrio

El acceso al escritorio remoto funcionó durante un mes, y luego la lista de permitidos dejó de coincidir sin ninguna razón visible. El host no se había movido y nada del firewall se había editado. Windows sigue formando direcciones temporales IPv6 con identificadores de interfaz aleatorios y retirándolas, así que la dirección de origen que ve el servidor en un día cualquiera puede ser una que nadie escribió en la regla. Desactivar ese comportamiento arregla la coincidencia y convierte al host en un identificador de larga vida al mismo tiempo. Sopesa las alternativas antes de aceptar la segunda mitad.

Por qué la regla dejó de coincidir

El RFC 4941 describe las direcciones temporales: el host crea direcciones adicionales con identificadores aleatorizados y las retira, lo que impide que un observador correlacione un host entre visitas. Windows implementa ese comportamiento, así que la dirección de origen de ayer no es necesariamente la de hoy. La dirección predecible sigue existiendo en la interfaz; simplemente no es la que prefiere una conexión saliente.

Por eso el fallo parece intermitente y no total. La regla coincide durante un tiempo después de crearse la dirección, deja de coincidir cuando se retira y vuelve a coincidir después de que alguien la edite. La monitorización agrupada por dirección de origen y las comprobaciones de licencia ligadas a una dirección de host se rompen con el mismo calendario. Una regla que funciona justo después de editarla y falla tres semanas más tarde suele ser esto, no una recarga del firewall.

Opción uno: una dirección estable, menos privacidad

La reparación habitual desactiva los dos mecanismos de rotación en el host: netsh interface ipv6 set privacy state=disabled store=persistent y netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Añade store=active si quieres que el cambio surta efecto sin esperar a un reinicio, y acepta que ahora has hecho que el identificador sea predecible en todas las redes.

Esa previsibilidad es exactamente lo que las extensiones se construyeron para evitar. Una dirección que sigue al host de la cafetería a la oficina y a casa es una clave de filtrado cómoda y una clave de seguimiento igual de cómoda, y la segunda propiedad sobrevive al ticket que pidió la primera.

Opción dos: permitir un prefijo o un nombre

Permitir el /64 en lugar de la dirección completa mantiene la rotación intacta y encaja con una afirmación más débil pero a menudo honesta: esta máquina está en mi red doméstica. Deja de ser suficiente en el momento en que ese prefijo contiene hosts que no admitirías, lo que en una conexión de consumo suele ser un conjunto más pequeño de lo que la gente supone. Un nombre publicado mediante DNS dinámico es más fácil de operar, porque el registro sigue al host y la política se lee como una identidad en lugar de como un rango que crece cada vez que se añade un dispositivo.

Ambas opciones necesitan un resolutor en el que el servidor pueda confiar y un nombre que no se pueda falsificar trivialmente, así que trátalas como una decisión de política sobre identidad y no como un cambio cosmético en la regla. Anota qué resolutor responde a ese nombre, porque la regla es tan fiable como el registro que hay detrás.

Opción tres: deja que el túnel asigne la dirección

Si la conexión atraviesa una VPN que controlas, el servidor puede repartir la dirección de su propio grupo de direcciones, y la lista de permitidos pasa a referenciar un valor que elige el servidor en lugar de uno que prefiere el cliente. Eso funciona bien para clientes gestionados y mal para cualquier cosa que el cliente pueda anular, así que verifica qué lado gana realmente en tu despliegue.

Mover la decisión completamente fuera de la dirección, hacia un certificado de cliente o una puerta de enlace autenticada, es la opción que escala, porque deja de depender de un valor que el sistema operativo tiene derecho a cambiar.

Elige con el coste de seguimiento a la vista

Escribe las cuatro opciones frente al requisito real y elige una en lugar de combinarlas. Si desactivas la privacidad de todos modos, limítala al host que la necesita, documenta el motivo junto a la regla y considera el direccionamiento estable-privado del RFC 7217 donde la plataforma lo admita, ya que conserva un identificador por prefijo sin exponer el derivado del hardware. Vuelve a habilitar las extensiones cuando se sustituya la lista de permitidos.

Registra el cambio junto a la regla que respalda. Sin esa nota, el siguiente administrador encuentra un host con las extensiones de privacidad desactivadas y sin explicación, y las vuelve a activar durante una limpieza.