VPN del Mac, filtro dei contenuti o Private Relay: quale è attivo
Tre livelli di rete del Mac si somigliano in Impostazioni. Distinguete VPN, filtro dei contenuti e Private Relay dal percorso di uscita, dalla politica dei flussi e dall'ambito di navigazione.
Il vostro Mac può avere installati insieme un tunnel VPN, un filtro dei contenuti e iCloud Private Relay, e nessuno di essi annuncia quale stia modellando una data connessione. I pannelli delle impostazioni si somigliano, le icone si somigliano, e quasi ogni fornitore chiama sicurezza di rete il proprio prodotto. Tre fatti li separano: se il traffico esce da un endpoint remoto che sapete nominare, se un motore di policy decide consentire-o-scartare sui singoli flussi, e se la protezione si ferma a Safari. Chiarite questi tre punti e la maggior parte delle domande del tipo il-mio-VPN-è-attivo si risponde da sola.
Tre condizioni che identificano il componente
La prima condizione è l'uscita. Un fornitore di tunnel consegna i pacchetti a un gateway remoto, quindi il vostro indirizzo pubblico cambia e, se il profilo lo prevede, gli host dietro quel gateway diventano raggiungibili. Se l'indirizzo non cambia mai e non si apre alcuna sottorete privata, non state guardando un tunnel funzionante, qualunque cosa dica la barra dei menu.
La seconda condizione è la decisione. Un filtro dei contenuti valuta i flussi e restituisce consenti o scarta. Può applicare un blocco di categoria, una regola per applicazione o una policy inviata dal datore di lavoro, e può registrare il verdetto. Ciò che non può fare da solo è dare al traffico un posto dove andare.
La terza condizione è l'ambito. Private Relay protegge una porzione definita della navigazione e non un dispositivo intero, e il suo compito è separare chi siete da ciò che visitate, non collocarvi su un'altra rete.
Metteteli uno accanto all'altro e i confini sono difficili da mancare:
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
Un filtro dei contenuti è un motore di policy, non un'uscita
Su macOS un filtro arriva come Network Extension costruita sulla classe di fornitore di dati di filtro di Apple, NEFilterDataProvider. In una distribuzione gestita lo spinge l'MDM, viene installato come estensione di sistema e approvato una volta in Impostazioni di Sistema > Generali > Oggetti di login ed estensioni. Da quel momento vede flussi TCP, e in alcune configurazioni anche UDP, e restituisce un verdetto per ciascuno.
La modalità di guasto è ciò che confonde. Un filtro che scarta un flusso produce un timeout, una stretta di mano TLS bloccata o un reset, che somiglia esattamente a un tunnel alzato ma incapace di far passare traffico. L'indirizzo pubblico non è mai cambiato, perché non c'era alcuna uscita a cambiarlo.
I client commerciali spesso riuniscono entrambi i ruoli. Un solo installer porta un fornitore di tunnel e un filtro, il filtro blocca e il tunnel instrada. Il nome dell'applicazione non vi dice quindi nulla su quale componente abbia rifiutato la connessione. Controllate l'elenco delle estensioni, poi il servizio connesso, poi il log del client, in quest'ordine.
Private Relay copre Safari, non la macchina
Private Relay invia la navigazione che copre attraverso due relay gestiti da parti separate, così nessun singolo operatore detiene sia la vostra identità sia le vostre destinazioni. È un progetto di privacy, non un tunnel: non c'è un gateway in cui entrare, nessuna sottorete privata e nessun modo di fissare un indirizzo di uscita in un paese che scegliete.
La sua portata è volutamente stretta: copre la navigazione di Safari insieme alle query DNS e ai caricamenti HTTP non sicuri che la accompagnano. Una sessione di terminale, un client di posta, un'app di chat e un launcher di giochi restano fuori. Se un controllo nel Terminale mostra ancora l'indirizzo della vostra rete di accesso mentre Safari mostra un indirizzo di relay, è il risultato atteso, non un'installazione rotta.
La disponibilità è condizionata. Serve un piano iCloud+, non è offerto in ogni regione, e una rete gestita può bloccare l'accesso al relay, nel qual caso Safari torna a una connessione diretta. La panoramica di Private Relay di Apple è il riferimento per la portata attuale. Quando un profilo VPN è connesso e trasporta quel traffico, il relay non vi si sovrappone; è il profilo a decidere il percorso.
Leggete le prove nell'ordine giusto
Iniziate dallo stato del servizio, perché è il segnale più economico. scutil --nc list elenca i servizi VPN configurati e se ciascuno è connesso. Un profilo può restare lì per anni senza mai connettersi, e la gente lo conta abitualmente come tunnel.
Poi guardate interfacce e rotte. ifconfig mostra interfacce utun, ma la loro sola presenza prova poco, dato che macOS usa utun per diversi scopi oltre alla VPN. Ciò che conta è se la rotta predefinita punta in una di esse, cosa che route -n get default riporta.
Per la risoluzione dei nomi, scutil --dns elenca i resolver che il sistema userà davvero, e lì compare un fornitore di proxy DNS. Confrontare dig +short example.com con dig +short example.com @1.1.1.1 separa il resolver che risponde da quello che viene intercettato.
L'attività delle estensioni arriva al log unificato: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. State cercando quale estensione è partita e se un filtro ha riportato un verdetto sul flusso che vi interessa, non una riga da memorizzare.
Restringete il sintomo prima di disattivare qualcosa
Classificate prima il guasto. Un nome che non si risolve, una connessione rifiutata subito e una connessione che resta appesa fino al timeout sono tre osservazioni diverse con tre responsabili diversi. La risoluzione punta a un resolver o a un proxy DNS. Un rifiuto immediato punta a una regola del filtro. Il silenzio di solito punta all'instradamento, o a un tunnel alzato ma che non inoltra.
Su un Mac gestito, date per scontato che il filtro appartenga all'organizzazione. Disattivarlo per provare la VPN rimuove il componente che volevate osservare, e l'MDM spesso lo ripristina al controllo successivo. Chiedete all'amministratore il nome della policy prima di cambiare qualcosa, e provate con l'applicazione specifica che ha fallito invece che con tutto il sistema.
Un'altra trappola: spegnere Private Relay per provare una VPN non dice nulla sul traffico estero, perché il relay non ha mai coperto quel traffico. Ogni livello va provato nell'applicazione che governa davvero.
Percorrete questo elenco e fermatevi al primo punto che fallisce:
scutil --nc listmostra come connesso il servizio che vi aspettate?- L'indirizzo pubblico visto dal Terminale è diverso da quello assegnato dalla vostra rete di accesso?
- È installata un'estensione di filtro, e ha registrato un verdetto per il flusso che fallisce?
- Il guasto è solo in Safari? Se sì, controllate la portata del relay prima di dare la colpa al tunnel.
Se tutti e quattro passano e l'applicazione fallisce ancora, il problema sta sopra il livello di rete: impostazioni proxy, fiducia nei certificati o un elenco di autorizzati a livello di applicazione.