Por qué desarrollamos un target iSCSI nativo de Windows en Rust para restauraciones Zero-Knowledge
En el espacio de la recuperación ante desastres (Disaster Recovery), el "Instant Mount" (montaje instantáneo) es una característica estándar. La capacidad de tomar un flujo de respaldo remoto y exponerlo instantáneamente como una letra de unidad local en una máquina Windows es fundamental para poner una empresa nuevamente en línea y minimizar el RTO (Recovery Time Objective).
La mayoría de los proveedores de copias de seguridad resuelven esto agrupando controladores de discos virtuales de terceros —como ImDisk o WNBD— en sus agentes. Estos son controladores en modo kernel (archivos .sys) que se integran profundamente en la pila de almacenamiento de Windows.
En StateWarden®, nuestra arquitectura se rige por un mandato estricto: Cero Dependencias Externas. Nos negamos a contaminar el kernel del host con controladores de terceros. La instalación de módulos de kernel externos introduce importantes riesgos de seguridad, fricción en la implementación y posible inestabilidad del sistema (BSOD).
Más importante aún, StateWarden es un sistema 100% Zero-Knowledge. Las copias de seguridad están fuertemente deduplicadas y encriptadas (AES-256-GCM) a nivel de bloque antes de que abandonen el cliente. Las claves de descifrado nunca abandonan la máquina anfitriona. Si queremos montar instantáneamente una copia de seguridad remota de 2 TB, no podemos descargarla y descifrarla en un archivo temporal; eso frustra el propósito del Zero-Knowledge y destruye el rendimiento.
El texto sin formato (plaintext) debe existir solo en la memoria RAM, exactamente en el momento en que el sistema operativo solicita un sector específico.
Para lograr esto sin controladores personalizados, elegimos el camino más difícil, pero arquitectónicamente más puro: Construimos un servidor iSCSI Target totalmente compatible desde cero, escrito íntegramente en Rust, integrado directamente en el Agente StateWarden.
Windows tiene un iniciador iSCSI nativo incorporado. Al hablar su idioma a través de una interfaz de loopback local, pudimos transmitir bloques desde nuestros propios centros de datos, descifrarlos en la memoria RAM sobre la marcha y entregarlos de forma nativa a la pila de almacenamiento de Windows.
Esto es lo que se necesita para construir un target de almacenamiento en bloques desde cero y domar la notoriamente implacable pila de almacenamiento de Windows.
Navegando por el rigor de Windows iSCSI
El protocolo iSCSI (RFC 3720) encapsula comandos SCSI complejos dentro de Protocol Data Units (PDU) sobre TCP. El iniciador iSCSI de Windows hace un trabajo excepcional, pero es increíblemente estricto. Un solo byte fuera de lugar o una ligera desviación de la máquina de estados da como resultado un fallo silencioso: el iniciador simplemente corta la conexión TCP (os error 10054) sin ninguna explicación.
Durante nuestra implementación inicial, el iniciador de Windows completaba con éxito el complejo protocolo de conexión (handshake) y descubría nuestro target virtual. Pero en el momento en que intentaba consultar el disco, la conexión moría violentamente.
El rastreo de paquetes reveló el momento exacto del fallo: Windows estaba enviando un comando REPORT LUNS (0xA0). Nuestro servidor Rust lo procesaba perfectamente y adjuntaba los datos del payload directamente al PDU SCSI Response (0x21).
Según la RFC, un PDU SCSI Response solo debe contener códigos de estado (como SUCCESS o CHECK CONDITION). No puede transportar datos de lectura. Cualquier dato real debe enviarse a través de un PDU dedicado SCSI Data-In (0x25). El iniciador de Windows vio bytes de carga útil (payload) adjuntos a un marco de estado, lo clasificó como una corrupción fatal del protocolo y activó instantáneamente un TCP RST (Reset).
Refactorizar nuestro constructor de paquetes para separar el flujo de datos y configurar correctamente las banderas F (Final) y S (Status present) en el marco Data-In estabilizó la conexión.
Manejo de la fragmentación PDU
Incluso con el protocolo en cumplimiento, los escaneos profundos del sistema de archivos causaban caídas intermitentes de la conexión. El gran avance se produjo al analizar los parámetros de inicio de sesión de iSCSI.
Durante el handshake, Windows negocia una longitud MaxRecvDataSegmentLength (generalmente 256 KB). Sin embargo, al leer grandes estructuras de la Tabla Maestra de Archivos (MFT), Windows emite lecturas SCSI de 512 KB o más. Nuestra implementación inicial intentó enviar la carga útil completa de 512 KB en un solo PDU Data-In. Windows vio el paquete de gran tamaño, se dio cuenta de que excedía los límites negociados y destruyó instantáneamente el socket.
Tuvimos que reescribir nuestra lógica de transmisión Data-In para fragmentar automáticamente las solicitudes de lectura SCSI masivas en una secuencia de PDU más pequeños y compatibles, divididos con precisión según los límites negociados por el iniciador, realizando el descifrado y el mapeo de deduplicación sobre la marcha en múltiples paquetes.
Falsificación de la geometría NTFS en la memoria
Con el protocolo de red consolidado, el iniciador de Windows finalmente se conectó sin problemas. Apareció un nuevo disco en la Administración de Discos de Windows. Pero el Explorador de Windows se negó a abrirlo, etiquetando el sistema de archivos como "RAW".
Nuestro target entregaba los bytes descifrados exactos de la partición NTFS respaldada. ¿Por qué Windows no podía leerla?
El problema residía en la geometría física de la copia de seguridad original. Cuando el Agente StateWarden hace una copia de seguridad de una unidad de Windows activa, consulta la API FSCTL_GET_NTFS_VOLUME_DATA para determinar el tamaño exacto del sistema de archivos.
Sin embargo, esta API de Windows informa el tamaño del volumen excluyendo el sector final. Ese sector final contiene el Volume Boot Record de Respaldo (Backup VBR). A un sistema Windows activo en funcionamiento no le importa este truncamiento, pero el controlador ntfs.sys que valida un disco recién montado requiere absolutamente que el VBR Principal (en LBA 0) y el VBR de Respaldo (al final del disco) coincidan perfectamente. Debido a que a nuestro flujo de respaldo le faltaba ese último sector, Windows rechazó todo el sistema de archivos como corrupto.
Diseñamos una solución en tiempo real en nuestro backend de streaming. Nuestro MbrWrapperBackend ahora almacena en caché el VBR Principal sobre la marcha, calcula los verdaderos límites físicos de la partición e inyecta dinámicamente un VBR de Respaldo sintético exactamente al final del flujo en la memoria. Efectivamente aplicamos padding a la geometría a la perfección antes de presentarla al iniciador iSCSI.
La recompensa arquitectónica
Con la geometría NTFS exacta restaurada y los payloads de red perfectamente fragmentados, el disco virtual se monta al instante. El error "RAW" desaparece y se puede navegar de inmediato por gigabytes de datos fuertemente encriptados y deduplicados de nuestros centros de datos en el Explorador de Windows.
Cada vez que hace doble clic en un archivo, el Agente StateWarden recupera los bloques deduplicados exactos del nodo de almacenamiento remoto, los descifra en la RAM utilizando las claves que se mantienen localmente y los alimenta a través de la conexión iSCSI de loopback al sistema operativo.
Construir un target de almacenamiento en bloques desde cero es doloroso, pero la recompensa arquitectónica es enorme. Ofrecemos capacidades Bare-Metal de "Instant Mount" de nivel empresarial de forma nativa, con seguridad absoluta Zero-Knowledge y sin contaminar el kernel del usuario con controladores de terceros. No tomamos atajos cuando se trata de la integridad del sistema anfitrión.
Esperamos plenamente que los proveedores tradicionales intenten realizar ingeniería inversa y replicar esta arquitectura sin controladores después de leer esto. Son bienvenidos a intentarlo. Pero una implementación iSCSI nativa es simplemente un solo componente del motor StateWarden. Es solo una de las docenas de decisiones arquitectónicas patentadas —desde nuestra criptografía en capas PrimeKEM hasta nuestras heurísticas de defensa activa Vigil— que superan fundamentalmente las ofertas actuales del mercado. No solo estamos construyendo una herramienta de respaldo; estamos diseñando el nuevo estándar para la resiliencia de los datos.