Il traffico di Windows Sandbox non segue il VPN dell’host per impostazione predefinita
La sandbox raggiunge la rete tramite un adattatore virtuale sullo switch predefinito. Se il tuo tunnel la copre è una proprietà del client, quindi verifica dall’interno.
Avvii Windows Sandbox, ci apri un browser e la pagina si carica dalla tua connessione normale anche se l’host era sul VPN un minuto prima. Niente è rotto. La sandbox riceve un adattatore di rete virtuale collegato allo switch predefinito dell’host, e se il tunnel dell’host copra quel percorso è una proprietà del client VPN, non di Windows.
Che cosa riceve davvero la sandbox
La sandbox è una macchina virtuale leggera con il proprio adattatore di rete. Quell’adattatore si collega tramite lo switch predefinito di Hyper-V dell’host, che traduce il traffico della sandbox verso l’interfaccia Ethernet virtuale dell’host prima che lasci la macchina. Questo dettaglio spiega quasi ogni sintomo che le persone segnalano al riguardo.
Quindi la sandbox non è un processo sul tuo desktop. È un endpoint di rete separato i cui pacchetti vengono inoltrati dall’host, e il firewall dell’host e il client VPN vedono ciascuno quell’inoltro a modo proprio. Una regola scritta per un processo del browser non corrisponde automaticamente a un frame tradotto da uno switch virtuale.
Due requisiti che sembrano uno
Raggiungere una risorsa privata e forzare ogni richiesta della sandbox attraverso il tunnel sono obiettivi diversi. Il primo richiede una route e una risoluzione dei nomi che funzionino per l’endpoint della sandbox. Il secondo richiede un’applicazione forzata che sopravviva a una riconnessione e a un guasto. Nessuno dei due deriva dall’altro, e un controllo che soddisfa uno non dice nulla sul secondo.
Un controllo dell’indirizzo pubblico non risponde del tutto a nessuna delle due domande. Vedere l’uscita del VPN dall’interno della sandbox dimostra che parte del traffico ha usato il tunnel. Non dice nulla sulla risoluzione dei nomi privati, né su cosa accade a una richiesta che inizia mentre il tunnel è inattivo.
Annota quale dei due ti serve prima di testare qualcosa, perché i due requisiti portano a progetti diversi e solo uno può essere verificato con un browser.
Verifica dall’interno della sandbox
L’unica osservazione significativa viene dalla sessione della sandbox stessa, non dall’host. Apri lì PowerShell e guarda l’adattatore, la risoluzione dei nomi e il percorso verso un indirizzo di documentazione:
ipconfig /all Resolve-DnsName files.corp.example Test-NetConnection 198.51.100.7 -Port 443 Get-NetRoute -DestinationPrefix 0.0.0.0/0
L’elenco degli adattatori mostra l’indirizzo e il gateway assegnati alla sandbox. Un gateway diverso da quello dell’host è normale per lo switch predefinito, quindi confronta l’uscita e non il gateway. Il test di risoluzione dice se un nome privato riceve risposta, ed è qui che le configurazioni split-horizon di solito divergono dall’host. La riga della route dice quale gateway la sandbox ritiene proprietario della route predefinita.
Ripeti gli stessi tre controlli con il tunnel connesso e disconnesso. Un risultato che non cambia tra questi due stati è la prova che il tunnel non è affatto sul percorso della sandbox, qualunque indirizzo abbia mostrato il controllo pubblico.
Disattiva la rete quando la sandbox non ne ha bisogno
Per un’ispezione offline, un file di configurazione personalizzato può rimuovere del tutto la rete. L’impostazione è un solo elemento nel documento di configurazione:
<Configuration> <Networking>Disable</Networking> </Configuration>
La riferimento di configurazione della sandbox documenta questo elemento e avverte che la rete abilitata può esporre reti interne ad applicazioni di cui non ti fidi. Quell’avviso è l’intero motivo per impostarla esplicitamente invece di accettare il valore predefinito.
Lo switch però non seleziona un’interfaccia VPN. È una decisione binaria sulla presenza di una rete, non un modo per legare la sandbox a un tunnel particolare. Un requisito che nomina un’uscita non può essere soddisfatto da uno switch che decide solo se ce n’è una.
Progetta il confine prima di concedere qualcosa
Se il requisito è un isolamento rigoroso, scegli un progetto di rete di macchina virtuale che possa imporlo, e usa la politica supportata del prodotto VPN per il traffico inoltrato o delle macchine virtuali. Indovinare il comportamento del client dell’host non è un progetto, e un solo controllo riuscito non è un’implementazione.
Non dare a una sandbox non attendibile un profilo VPN aziendale o credenziali private per far passare un test. Questo scambia il confine che stavi cercando di stabilire con un risultato verde, e la credenziale sopravvive al test.
Annota la modalità di rete, l’uscita osservata e il comportamento di riconnessione nelle note di distribuzione. Quando un aggiornamento del client cambia il modo in cui viene gestito il traffico inoltrato, sono quelle note a dire che il requisito non è mai stato davvero soddisfatto.