Account VPN condiviso: un limite di dispositivi non è isolamento dei client

Otto connessioni simultanee è un numero preso da una pagina di licenza, e non dice nulla su ciò che questi otto dispositivi possono farsi a vicenda. Un accesso condiviso può convivere con chiavi per sessione, e può anche convivere con un gateway che inoltra volentieri il traffico di un client a un altro. L’errore è trattare l’account come un confine di sicurezza. Ponga invece quattro domande separate: cosa è stato acquistato, cosa protegge il tunnel, cosa può attraversare tra peer e cosa può far cadere il collegamento locale.

Cosa promette davvero un limite di connessioni

Un limite di dispositivi conta quante sessioni il fornitore accetterà per un abbonamento. È un controllo commerciale e operativo, non un’affermazione sull’identità o sull’isolamento. Alcuni fornitori rilasciano un certificato distinto per ogni dispositivo sotto un solo account; altri riutilizzano una singola credenziale a ogni connessione. La differenza emerge alla revoca, perché credenziali separate le permettono di tagliare un dispositivo, mentre una condivisa non le lascia questa possibilità.

Legga come il fornitore rilascia le credenziali prima di presumere qualcosa sulla separazione delle chiavi. Il nome dell’account non ne rivela nulla.

Verifichi se il gateway inoltra tra client

La raggiungibilità tra peer è una decisione lato server. Su OpenVPN l’interruttore pertinente è assente a meno che non compaia nella configurazione, ma lo scaricamento moderno del piano dati cambia dove si applica la regola.

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Una configurazione senza quella direttiva lascia il traffico tra peer al firewall dell’host, che potrebbe ancora consentirlo. Quando lo scaricamento è attivo, il kernel gestisce l’interfaccia del tunnel invece del processo nello spazio utente, quindi verifichi i contatori delle regole anziché fidarsi del file. Bloccare il traffico inoltrato tra indirizzi del tunnel isola i client senza toccare il loro accesso al gateway. Lo confermi con una sonda da un client a un servizio su un altro, sia prima sia dopo la regola.

Protegga la sessione prima dei peer

La protezione del tunnel e l’accesso tra peer sono proprietà diverse, e una cifratura forte non implica isolamento. In modalità TLS ogni client deriva le proprie chiavi di sessione, quindi un client non può leggere il traffico di un altro anche quando il gateway lo inoltra. Il vecchio schema a chiave statica condivide un’unica chiave tra tutti, per questo riutilizzare lì un accesso ha conseguenze molto peggiori. Esamini la modalità configurata e non la pagina di marketing, poi giudichi se la condivisione dell’account si adatta ai dati in gioco.

L’autenticazione del servizio su ogni host resta importante, perché il tunnel prova solo che un client ha raggiunto la rete, non che debba raggiungere un determinato demone.

I guasti del Wi-Fi locale non sono compromissioni del VPN

Una connessione caduta prova che il collegamento locale è fallito, non che qualcuno abbia rotto il tunnel. Interferenze, un lease DHCP perso e un passaggio in roaming terminano una sessione senza toccare credenziali o testo cifrato. Tratti la disconnessione come un riscontro di disponibilità e la tenga separata dai riscontri su riservatezza e accesso tra peer. Dove la rete locale non è affidabile, protegga il traffico da un capo all’altro invece di appoggiarsi solo al tunnel.

Annoti le quattro risposte: limite, modello di chiavi, politica tra peer e dipendenza dal collegamento locale. Quell’annotazione trasforma una vaga preoccupazione per un account condiviso in controlli concreti.