Due applicazioni aprono connessioni verso lo stesso server d’ufficio, e solo una di esse dovrebbe usare il tunnel. Una rotta non può esprimere quel desiderio, perché le tabelle di routing sono indicizzate sulle destinazioni e non hanno alcuna nozione di quale processo abbia aperto il socket. Ciò che le persone chiedono e ciò di cui hanno bisogno sono spesso cose diverse. Separa le due prima di cambiare qualsiasi configurazione.

Il selettore è una destinazione, mai un processo

Ogni decisione di routing parte da un indirizzo di destinazione e termina con un’interfaccia. Il kernel non chiede mai quale binario abbia inviato il pacchetto, e su macOS anche pf non instrada per processo, quindi una regola del firewall non può mettere un’applicazione su un percorso diverso. Ecco perché lo stesso server, raggiunto da un browser e da uno strumento di reporting, prende un solo percorso per entrambi. La separazione a livello applicativo deve quindi venire da qualcosa di diverso da una rotta: un plugin VPN che possiede il socket, un proxy che prende la connessione per conto dell’applicazione, o uno stack di rete separato. Nessuna di queste è una modifica di routing.

Due applicazioni che parlano con un solo indirizzo sono il test più pulito di un progetto. Se la risposta non può differire tra loro, il progetto è basato sulla destinazione, comunque lo si chiami.

Cosa offre davvero uno split tunneling ordinario

Uno split tunnel installa rotte per i prefissi privati e lascia tutto il resto sul percorso fisico. Di solito è questo che significa la richiesta: raggiungere il server d’ufficio attraverso il tunnel, mantenere la navigazione pubblica diretta. È semplice, ogni client comune lo supporta, ed è imposto dallo stesso meccanismo di qualsiasi altra rotta. Controlla la destinazione specifica con route -n get invece di leggere la rotta predefinita, perché uno split tunnel spesso lascia quest’ultima intatta.

Modificare a mano la rotta predefinita non è una conversione verso nulla. Si scontra con il ripristino delle rotte del client e, nei client che installano una politica di protezione, può lasciare la macchina in uno stato che né tu né il client vi aspettate. Configura invece lo split tunnel nelle impostazioni supportate del client.

Cosa richiede un VPN per applicazione su macOS

Un vero VPN per applicazione su macOS è una funzionalità Network Extension guidata da un profilo di configurazione. Un payload di gestione associa applicazioni scelte a una configurazione VPN, e il sistema instrada poi il traffico di quelle applicazioni di conseguenza. È una distribuzione gestita, il che significa un MDM, un profilo firmato e un amministratore che possiede entrambi.

Installare il client a mano non crea quell’associazione, e il normale pannello delle impostazioni non rende le applicazioni selezionabili singolarmente. Un fornitore può esporre le proprie regole applicative, e queste seguono la sua documentazione anziché una regola generale.

Tre vie per la separazione per applicazione senza MDM

Dove la gestione non è disponibile, un proxy è la risposta pratica. Imposta la configurazione proxy dell’applicazione stessa, oppure usa un file PAC che seleziona per destinazione e protocollo solo per quell’applicazione.

Un proxy locale termina la connessione e la riorigina attraverso il tunnel, così l’applicazione non ha mai bisogno di una rotta. La seconda opzione è uno stack di rete separato: una macchina virtuale o un container con la propria rotta predefinita, che l’applicazione raggiunge tramite un indirizzo locale. La terza è accettare il routing basato sulla destinazione e abbandonare il requisito, il che è onesto quando entrambe le applicazioni possono usare il tunnel. Tutte e tre sono verificabili, e nessuna finge che una rotta conosca i processi.

Scrivi la richiesta in modo che la risposta sia inequivocabile

Descrivi il flusso di lavoro invece del meccanismo: quale applicazione ha bisogno di quale servizio, se un’altra applicazione deve essere tenuta lontana da quello stesso servizio, e cosa deve succedere mentre il tunnel è inattivo. Queste tre risposte scelgono il progetto. Dicono anche all’amministratore se la richiesta è una modifica di routing o un progetto di distribuzione.

Includi esplicitamente il caso dell’applicazione esclusa. Un client che arresta un’applicazione quando il suo percorso protetto non è disponibile si comporta diversamente da uno che la lascia ripiegare sull’interfaccia fisica, e gli utenti notano subito la differenza. Nomina l’aspettativa nel ticket. Poi verifica sulla macchina reale, perché lo stesso prodotto spesso si comporta diversamente su macOS e su Windows, e la sua documentazione macOS è l’unica fonte affidabile su ciò che fanno le sue impostazioni.

Articoli correlati