Due account di accesso Mac non separano il traffico VPN

Due account di accesso sullo stesso Mac sembrano due mondi separati finché non arriva la rete. Un tunnel avviato in una sessione può comunque cambiare ciò che vive l'altra sessione, a seconda di quale client lo possiede e quale criterio lo accompagna. Descrivere la separazione necessaria prima di scegliere un meccanismo per imporla. L'ordine conta, perché un meccanismo scelto per primo tende a ridefinire il requisito attorno a sé.

Tre domande fanno la maggior parte del lavoro: quali applicazioni di chi hanno bisogno di quali risorse private, se entrambe le sessioni devono essere attive insieme e cosa è consentito fare a quelle applicazioni quando il loro tunnel non è disponibile.

Partire dal traffico, non dall'elenco degli account

Cambiare account è un confine di identità, non un confine di instradamento. macOS carica una configurazione VPN per l'account che la possiede, ma l'interfaccia, le sue rotte e qualsiasi criterio a livello di sistema che installa appartengono alla macchina. Se il requisito è che solo le applicazioni di una persona entrino nella rete aziendale, il progetto deve dirlo in termini di applicazioni e destinazioni, non di chi ha effettuato l'accesso. Altrimenti il secondo account eredita ciò che il client del primo ha lasciato.

Scrivere il comportamento richiesto in una frase: la posta e l'accesso ai file di un utente seguono il tunnel gestito, la navigazione dell'altro utente resta sulla connessione di casa e nessuno dei due percorsi eredita la rotta predefinita dell'altro. Quella frase è verificabile; una storia di cambio di accesso di solito non lo è.

Canale del profilo e ambito del traffico sono cose diverse

Apple supporta disposizioni VPN gestite fornite per utente o per dispositivo, e una guida alla distribuzione descrive quei modelli insieme all'integrazione dipendente dal fornitore. Il canale di consegna dice chi riceve la configurazione e chi la possiede. Non definisce da solo quale traffico viene catturato, perché l'implementazione del client e il criterio configurato continuano a deciderlo.

Dove una modalità documentata consapevole dell'utente o dell'applicazione può esprimere il requisito, quella è la strada più breve. Poi verificare le applicazioni e le identità reali invece di fidarsi dei nomi: due copie della stessa applicazione non sono due percorsi di rete diversi, e un profilo che elenca un'applicazione non garantisce che i suoi processi ausiliari siano coperti.

Un sistema ospite è un confine reale con limiti reali

Una macchina virtuale dà un sistema operativo separato con la propria pila di rete, così un ospite può eseguire il proprio tunnel e le proprie applicazioni senza toccare le rotte dell'host. È una separazione più forte di un secondo account di accesso, ed è anche più lavoro di manutenzione. Decidere se quel costo compra un confine che serve davvero prima di proporlo.

La modalità di rete virtuale va comunque esaminata. Se l'ospite è in bridge, dietro NAT o isolato determina cosa può raggiungere e cosa può raggiungerlo, e le applicazioni dell'host non diventano applicazioni dell'ospite solo perché l'ospite è connesso. Controllare anche il criterio di blocco, altrimenti un tunnel dell'ospite caduto tornerà sul percorso dell'host in un modo che nessuno intendeva.

Un proxy è più stretto di un account utente

Un'applicazione dell'host può raggiungere un vero servizio proxy in esecuzione in un ospite o container approvato, e ciò copre il traffico che l'applicazione invia realmente tramite il protocollo supportato. Non copre ogni processo posseduto da quell'account Mac, né il traffico che l'applicazione invia fuori dal protocollo proxy.

Un'altra cautela sulle macchine condivise: un listener TCP legato al loopback dell'host non è un controllo del nome utente. Limitare un proxy alla macchina locale lo tiene fuori dalla rete, ma non autorizza un utente locale rispetto a un altro già connesso. Mantenere esplicita l'autenticazione del servizio se questa distinzione conta.

Dimostrare il confine con due test

Eseguire entrambi i percorsi e osservarli separatamente. Con l'account previsto, aprire l'applicazione che ha bisogno della risorsa privata e confermare che raggiunge il servizio gestito; con l'altro account, confermare che la navigazione ordinaria mantiene il percorso di casa. Poi rompere il tunnel di proposito e controllare il comportamento di ripiego su ciascun lato, perché è lì che la maggior parte dei progetti fallisce in silenzio. Eseguire i controlli anche nella stessa ora, così una rete cambiata non contamina il confronto.

Se un container o un ospite esegue il tunnel, aggiungere un terzo controllo: confermare che un'applicazione Mac nativa al di fuori si comporti ancora come progettato. Scegliere la disposizione più semplice di cui si può dimostrare l'ambito, e non etichettare le macchine virtuali come universalmente necessarie né il cambio di account come universalmente sufficiente prima di eseguire quei test.