Quale strumento macOS può forzare una sola app a passare solo attraverso la VPN?
Un confine solo-VPN richiede sia un percorso sia un rifiuto. Confrontate profili per app, proxy, filtri e PF, poi testate l’app che vi interessa.
Una riga in un documento dei requisiti, «questa app può usare la VPN e nient’altro», chiede in silenzio due meccanismi che nessun singolo interruttore fornisce. Il traffico ha bisogno di un percorso nel tunnel previsto, e il traffico che uscirebbe direttamente deve essere rifiutato. Gli strumenti che fanno bene uno dei due e l’altro per niente sono comuni, perciò un confronto che chiede solo se qualcosa può bloccare risponde con sicurezza a metà della domanda. Scrivete prima il confine, poi scegliete i componenti che ne coprono entrambe le metà.
Due requisiti nascosti in una sola frase
L’instradamento è la parte che mette una connessione nel tunnel o nel proxy. Il rifiuto è la parte che impedisce alla stessa connessione di uscire per qualsiasi altra rotta. Li implementano componenti diversi, falliscono in modi diversi, e un prodotto può essere eccellente in uno senza dire nulla dell’altro:
| Approach | Steers traffic | Refuses direct egress | Knows the app identity |
|---|---|---|---|
| Per-app VPN profile | Yes, for the apps it names | Only if a filter or firewall also blocks | Yes, within its own rules |
| Application proxy setting | Partly, for requests that honour it | No | No |
| Content filter | No | Yes | Yes, if the filter is written that way |
| Local PF ruleset | No | Yes, by address and port | Not reliably |
Leggete la tabella come una lista di controllo e non come una classifica. Nessuna riga riempie entrambe le colonne centrali, e le righe che le coprono sono due componenti che cooperano: uno possiede il percorso, l’altro possiede il rifiuto. La colonna dell’identità conta per un altro motivo, perché una regola che non può nominare l’app non può applicare una regola su quell’app. Qualunque cosa distribuate, deve rispondere a tutte e tre, altrimenti il confine nel documento dei requisiti non è il confine sulla macchina.
L’instradamento da solo lascia una via d’uscita
L’impostazione del proxy di applicazione è l’esempio più chiaro di instradamento senza rifiuto. Può instradare le richieste di un’app che rispetta il proxy di sistema e non copre nient’altro: un processo ausiliario, un programma di aggiornamento, un servizio in background o un protocollo diverso possono viaggiare per la propria strada senza mai leggere quella preferenza. Scegliere un endpoint SOCKS in un pannello non crea quindi una politica di divieto di uscita diretta per l’applicazione. Se il requisito riguarda l’app nel suo insieme, chiedete quali componenti la regola identifichi davvero.
Un profilo VPN per app instrada meglio di un proxy, perché è la piattaforma a decidere quali app entrano nel tunnel invece che ogni app decida da sola. Eppure non rifiuta nulla: il profilo fornisce un percorso, e il traffico che non vi corrisponde prende la rotta ordinaria. È esattamente in quel vuoto che un secondo componente si guadagna il suo posto, ed è per questo che i prodotti che sembrano un solo interruttore sono di solito due.
Il rifiuto da solo rompe l’app
La documentazione di Apple sui filtri di contenuto descrive un verdetto consentire-o-bloccare sul traffico mentre attraversa lo stack di rete. Quel verdetto non è un tunnel né una connessione proxy, perché decide se qualcosa può continuare, non dove va. Un filtro da solo applica perfettamente il rifiuto e lascia l’applicazione inutilizzabile, con registri puliti e nessuna spiegazione. Il verdetto di un filtro può fermare una connessione ma non fornisce mai il tunnel, quindi abbinarlo all’instradamento è la decisione di progetto e non un extra opzionale.
Un insieme di regole PF amministrato localmente sta all’altro estremo di quello spettro. È una decisione di supporto legittima su una macchina posseduta da un amministratore, e non è automaticamente la base di un prodotto distribuibile, perché chi possiede l’insieme di regole possiede anche le sue interazioni con gli altri utenti del firewall, il suo percorso di aggiornamento e il suo ripristino quando una regola è sbagliata. Aggiungere PF a un prodotto non elimina quella questione di proprietà; la definisce.
La distribuzione decide se la regola esisterà ancora domani
Come viene distribuita una Network Extension sulle piattaforme Apple dipende dal tipo di fornitore, dal confezionamento e dalla versione del sistema operativo che avete davanti. Un’estensione app su macOS gira in un contesto utente e termina quando quell’utente esce, mentre un’estensione di sistema ha un contesto globale che non dipende dalla sessione. Se la protezione deve sopravvivere a un’uscita, quella differenza è tutto il progetto e non una nota a piè di pagina. Confermate il percorso di distribuzione prima di promettere il comportamento, perché lo stesso codice atterra diversamente a seconda del tipo di estensione spedito.
La disponibilità del codice sorgente è una questione separata dall’applicazione. Leggere un repository vi dice come qualcosa è implementato, non che cosa il binario installato può fare su questa macchina. Firma, installazione e autorizzazione valgono ancora, e istruzioni costruite intorno a un’estensione del kernel obsoleta o a un trucco di iniezione di libreria descrivono un’altra piattaforma e un’altra postura di rischio, per bene che funzionassero un tempo.
Un caso di accettazione che nomina l’app
Scegliete una sola azione che l’applicazione compie da sola, annotate l’indirizzo che dovrebbe raggiungere e se quell’indirizzo è IPv4 o IPv6, poi ripetete la stessa azione nello stato approvato senza tunnel. La seconda esecuzione deve produrre il rifiuto dichiarato e non un nuovo tentativo diretto silenzioso. È quella la metà che le persone lasciano non specificata, e l’unica metà che dimostra che il rifiuto esiste. Eseguitela prima con il tunnel disponibile, così che una differenza tra i due risultati possa venire solo dal tunnel mancante.
Poi percorrete le transizioni che il requisito nomina: riavvio dell’app, attivazione di un processo ausiliario, riconnessione del tunnel, cambio di rete della macchina e uscita o riavvio dove si applicano. Una pagina di IP pubblico del browser non è un test dei socket di un’altra applicazione, quindi non può sostituire questo. Dove nessuna distribuzione supportata copre il comportamento reale dell’app, un ambiente isolato autorizzato con un gateway esplicito e senza uscita alternativa è una decisione di contenimento con un proprio costo di gestione, non un sostituto di una casella di controllo.
Concludete annotando quattro voci: da quali componenti è composta l’app, chi possiede l’instradamento, chi possiede il rifiuto e gli stati in cui la regola deve ancora valere. Un repository pubblico può essere un criterio di selezione, ma non è una delle quattro, e sono quelle voci a stabilire se un dato strumento soddisfa il requisito di rete.