Due lavori diversi portano il nome VPN in macOS, e il pannello delle impostazioni ne gestisce solo uno. Se vuoi che il traffico di questo Mac esca tramite un provider o un gateway remoto, basta una voce client. Se vuoi raggiungere la stampante, il NAS o una pagina di amministrazione della tua rete domestica da una camera d’albergo, qualcosa su quella rete deve accettare connessioni dall’esterno, e un Mac attuale non è quel qualcosa di serie. Tre domande stabiliscono in quale caso ti trovi, e vale la pena rispondervi prima di digitare un indirizzo in un campo.

Una voce client nomina una destinazione, non un listener

In Impostazioni di Sistema > Rete > VPN su macOS Ventura e successivi, i campi che le versioni precedenti tengono in Preferenze di Rete descrivono come raggiungere l’endpoint di qualcun altro: un indirizzo server, un ID remoto, un account o certificato e regole opzionali di connessione su richiesta. Salvare quella voce memorizza una connessione nella configurazione di rete del tuo Mac. Nulla nel processo associa una porta, apre un listener o registra un utente remoto.

Puoi verificarlo dalla shell. Su un Mac che sospetti stia servendo, esegui sudo lsof -nP -iUDP e cerca le porte usate dal tuo protocollo: 500 e 4500 per IKEv2, 1194 per il default di OpenVPN, 51820 per WireGuard. Una macchina solo client mostra socket accoppiati a un indirizzo e a una porta remoti, non un binding wildcard che qualsiasi cosa su internet potrebbe raggiungere. I tunnel che girano dentro un Network Extension possono nascondersi a lsof, quindi controlla comunque il pannello di stato dell’app; quello che non troverai è una preferenza Apple che trasformi questo Mac nel gateway.

Tre domande separano i due ruoli

Affrontale in ordine. La prima di solito decide il resto, e la terza è dove la maggior parte della pianificazione specifica per Mac sbaglia.

1. Chi inizia la conversazione? Se il tuo Mac chiama verso l’esterno e l’altra parte risponde, ti serve un client. Se i dispositivi su internet devono chiamare verso l’interno per raggiungere la tua rete, ti serve un gateway con un punto d’ingresso pubblico, e il Mac può restare client di quel gateway.

2. Cosa deve essere raggiungibile mentre il tunnel è attivo? Un servizio su un host è una decisione di port forwarding. Un’intera sottorete, risoluzione dei nomi inclusa, è una decisione di routing e DNS, e cambia ciò che il gateway deve inoltrare, non ciò che dice la voce client.

3. Quale versione del sistema esegue il lato che accetta? Per i Mac quella domanda ha una risposta netta. Apple elenca VPN come rimosso da macOS Server 5.7.1, e l’app macOS Server stessa è stata dismessa il 21 aprile 2022; il avviso sulla cronologia del servizio è la pagina da leggere quando un vecchio tutorial ti guida attraverso una casella di servizio VPN che non esiste più.

Quando la prima risposta è “qualcuno dall’esterno avvia”, smetti di cercare un interruttore nel pannello client del Mac e vai a scegliere l’host che terminerà il tunnel.

Dove può vivere il gateway invece

Quattro soluzioni coprono la maggior parte dei casi domestici e di piccolo ufficio. Un router con una vera modalità server, anziché una modalità client con un’etichetta diversa, termina il tunnel al bordo e tiene basso il numero di host, al prezzo di dipendere dal supporto protocollare di quel firmware. Un NAS o un mini PC sempre acceso esegue il pacchetto server del produttore e ti lascia log che puoi leggere. Una piccola VM cloud ti dà un indirizzo pubblico che controlli e raggiunge casa tramite un secondo tunnel. Un overlay mesh costruito su WireGuard, o un servizio gestito che inoltra tra peer, aggira il port forwarding in ingresso facendo chiamare verso l’esterno entrambe le estremità.

Il confine tra quelle opzioni di solito è la tua connessione a internet, non il software. Se l’ISP ti mette dietro un NAT di grado operatore, nessuna quantità di port forwarding sul router produce un punto d’ingresso raggiungibile, e una soluzione a relay o mesh è la risposta onesta. Confronta l’indirizzo WAN riportato dal router con l’indirizzo che vede il mondo esterno; se differiscono e il valore del router sta in un intervallo privato o condiviso, pianifica il caso relay.

Qualunque host scegli, inoltra un protocollo su una porta invece di un intervallo, e tieni il Mac fuori dal percorso in ingresso a meno che quel prodotto specifico documenti un ruolo server per la versione di macOS che esegui.

Conferma il ruolo prima di distribuire i profili

Sul gateway candidato, dimostra che esiste un listener invece di fidarti che l’installer ne abbia creato uno. Su macOS ciò significa sudo lsof -nP -iUDP filtrato sulle porte precedenti, più sudo pfctl -s nat se le regole del filtro pacchetti fanno parte del progetto. Su Linux, ss -lunp mostra gli stessi fatti senza ambiguità.

Poi prova da fuori dalla rete, usando il protocollo stesso. Ping dimostra poco: ICMP è spesso filtrato e non dice nulla su UDP 51820. Un handshake client con log dettagliato, eseguito da un telefono su dati cellulari, è il test reale più economico perché attraversa lo stesso percorso di un collega remoto.

Solo dopo tocchi i profili client. Sul Mac, scutil --nc list stampa i servizi VPN che il sistema conosce; se il gateway che hai appena costruito non è tra loro, stai configurando una macchina diversa da quella che hai testato. Se l’handshake riesce sulla LAN ma fallisce dall’esterno, il guasto è nel percorso in ingresso: regola NAT, CGNAT del provider o firewall sul gateway, in quest’ordine.

Prima di costruire qualsiasi cosa, risolvi quattro punti:

  • Quale lato avvia la connessione, il tuo Mac o un dispositivo remoto.
  • Se la versione del sistema e il prodotto dell’host che accetta supportano davvero un ruolo server.
  • Se il tuo ISP ti dà davvero un indirizzo pubblico raggiungibile.
  • Quale singola porta e protocollo accetterà il gateway, e quale servizio dietro risponde.

Il passo successivo è concreto: scegli l’host gateway, confermane il listener dall’esterno, e solo allora crea sul Mac la voce client che punta a esso.

Articoli correlati