Perché abbiamo sviluppato un target iSCSI nativo per Windows in Rust per ripristini Zero-Knowledge

Nello spazio del Disaster Recovery (DR), il "Instant Mount" è una funzionalità standard. La capacità di prendere un flusso di backup remoto ed esporlo istantaneamente come una lettera di unità locale su una macchina Windows è fondamentale per riportare online un'azienda e ridurre al minimo l'RTO (Recovery Time Objective).

La maggior parte dei fornitori di backup risolve questo problema includendo driver di dischi virtuali di terze parti — come ImDisk o WNBD — nei loro agenti. Questi sono driver in modalità kernel (file .sys) che si integrano profondamente nello stack di archiviazione di Windows.

In StateWarden®, la nostra architettura è governata da un mandato rigoroso: Zero Dipendenze Esterne. Ci rifiutiamo di inquinare il kernel dell'host con driver di terze parti. L'installazione di moduli kernel esterni introduce significativi rischi per la sicurezza, attriti nell'implementazione e potenziale instabilità del sistema (BSOD).

Fatto ancora più importante, StateWarden è un sistema 100% zero-knowledge. I backup vengono pesantemente deduplicati e crittografati (AES-256-GCM) a livello di blocco prima ancora di lasciare il client. Le chiavi di decrittografia non lasciano mai la macchina host. Se vogliamo montare istantaneamente un backup remoto di 2 TB, non possiamo scaricarlo e decrittografarlo in un file temporaneo: ciò vanifica lo scopo del zero-knowledge e distrugge le prestazioni.

Il testo in chiaro (plaintext) deve esistere solo nella memoria RAM, esattamente nel momento in cui il sistema operativo richiede un settore specifico.

Per raggiungere questo obiettivo senza driver personalizzati, abbiamo scelto la strada più difficile, ma architettonicamente più pura: Abbiamo costruito un server target iSCSI completamente conforme da zero, scritto interamente in Rust, incorporato direttamente nell'agente StateWarden.

Windows ha un iniziatore iSCSI nativo integrato. Parlando la sua lingua su un'interfaccia di loopback locale, abbiamo potuto trasmettere blocchi dai nostri data center, decrittografarli nella RAM al volo e servirli in modo nativo allo stack di archiviazione di Windows.

Ecco cosa serve per creare un target di archiviazione a blocchi da zero e domare il notoriamente spietato stack di archiviazione di Windows.

Navigare nel rigore di Windows iSCSI

Il protocollo iSCSI (RFC 3720) incapsula comandi SCSI complessi all'interno di Protocol Data Units (PDU) su TCP. L'iniziatore iSCSI di Windows svolge eccezionalmente bene il suo lavoro, ma è incredibilmente rigoroso. Un singolo byte fuori posto o una leggera deviazione dalla macchina a stati provoca un errore silenzioso: l'iniziatore interrompe semplicemente la connessione TCP (os error 10054) senza alcuna spiegazione.

Durante la nostra implementazione iniziale, l'iniziatore Windows completava con successo il complesso handshake di login e scopriva il nostro target virtuale. Ma nel momento in cui cercava di interrogare il disco, la connessione moriva violentemente.

Il tracciamento dei pacchetti ha rivelato il momento esatto dell'errore: Windows stava inviando un comando REPORT LUNS (0xA0). Il nostro server Rust lo elaborava perfettamente e allegava i dati di payload direttamente al PDU SCSI Response (0x21).

Secondo la RFC, un PDU SCSI Response deve contenere solo codici di stato (come SUCCESS o CHECK CONDITION). Non può trasportare dati di lettura. Tutti i dati reali devono essere inviati tramite un PDU SCSI Data-In dedicato (0x25). L'iniziatore di Windows ha visto byte di payload collegati a un frame di stato, l'ha classificato come una corruzione fatale del protocollo e ha immediatamente attivato un TCP RST (Reset).

Refactoring del nostro packet builder per separare il flusso di dati e impostare correttamente i flag F (Final) e S (Status present) sul frame Data-In ha stabilizzato la connessione.

Gestione della frammentazione PDU

Anche con il protocollo conforme, le scansioni approfondite del file system causavano interruzioni intermittenti della connessione. La svolta è arrivata analizzando i parametri di login iSCSI.

Durante l'handshake, Windows negozia un MaxRecvDataSegmentLength (in genere 256 KB). Tuttavia, durante la lettura di grandi strutture Master File Table (MFT), Windows emette letture SCSI per 512 KB o più. La nostra implementazione iniziale ha tentato di inviare l'intero payload di 512 KB in un singolo PDU Data-In. Windows ha visto il pacchetto sovradimensionato, si è reso conto che superava i limiti negoziati e ha immediatamente interrotto il socket.

Abbiamo dovuto riscrivere la nostra logica di streaming Data-In per frammentare automaticamente le massicce richieste di lettura SCSI in una sequenza di PDU più piccoli e conformi, suddivisi in blocchi precisi in base ai limiti negoziati dall'iniziatore, eseguendo la decrittografia e la mappatura della deduplicazione al volo su più pacchetti.

Falsificare la geometria NTFS in memoria

Rafforzato il protocollo di rete, l'iniziatore Windows si è finalmente connesso senza problemi. Un nuovo disco è apparso in Gestione disco di Windows. Ma Windows Explorer si rifiutava di aprirlo, etichettando il file system come "RAW".

Il nostro target stava fornendo gli esatti byte decrittografati della partizione NTFS di backup. Perché Windows non riusciva a leggerla?

Il problema risiedeva nella geometria fisica del backup originale. Quando l'agente StateWarden esegue il backup di un'unità Windows attiva, interroga l'API FSCTL_GET_NTFS_VOLUME_DATA per determinare l'esatta dimensione del file system.

Tuttavia, questa API di Windows riporta le dimensioni del volume escludendo il settore finale. Quel settore finale contiene il Backup Volume Boot Record (VBR). A un sistema Windows attivo in esecuzione non importa di questo troncamento, ma il driver ntfs.sys che convalida un disco appena montato richiede assolutamente che il VBR principale (al LBA 0) e il VBR di backup (alla fine del disco) corrispondano perfettamente. Poiché al nostro flusso di backup mancava quel settore finale, Windows ha rifiutato l'intero file system come corrotto.

Abbiamo progettato una correzione in tempo reale nel nostro backend di streaming. Il nostro MbrWrapperBackend ora memorizza nella cache il VBR principale al volo, calcola i veri confini fisici della partizione e inietta dinamicamente un VBR di backup sintetico all'esatta estremità del flusso in memoria. Facciamo efficacemente un padding perfetto della geometria prima di presentarla all'iniziatore iSCSI.

Il vantaggio architettonico

Con l'esatta geometria NTFS ripristinata e i payload di rete perfettamente frammentati, il disco virtuale si monta istantaneamente. L'errore "RAW" è scomparso e gigabyte di dati pesantemente crittografati e deduplicati dei nostri data center sono immediatamente consultabili in Esplora risorse.

Ogni volta che fai doppio clic su un file, l'Agente StateWarden recupera gli esatti blocchi deduplicati dal nodo di archiviazione remoto, li decrittografa nella RAM utilizzando le chiavi conservate localmente e li invia attraverso la connessione iSCSI di loopback al sistema operativo.

Costruire un target di archiviazione a blocchi da zero è doloroso, ma il vantaggio architettonico è enorme. Offriamo funzionalità Bare-Metal "Instant Mount" di livello aziendale in modo nativo, con sicurezza Zero-Knowledge assoluta e senza inquinare il kernel dell'utente con driver di terze parti. Non prendiamo scorciatoie quando si tratta dell'integrità del sistema host.

Ci aspettiamo pienamente che i vendor legacy tentino di decodificare e replicare questa architettura senza driver dopo aver letto questo. Sono i benvenuti a provare. Ma un'implementazione iSCSI nativa è semplicemente un singolo componente del motore StateWarden. È solo una delle dozzine di decisioni architettoniche proprietarie — dalla nostra crittografia a cipolla PrimeKEM alle nostre euristiche di difesa attiva Vigil — che declassano fondamentalmente le attuali offerte di mercato. Non stiamo solo costruendo uno strumento di backup; stiamo progettando il nuovo standard per la resilienza dei dati.