Un accesso VPN su un PC condiviso: chi altro riceve la rotta?

Condividere una workstation solleva una domanda a cui un portatile monoposto non deve mai rispondere: una volta che una persona autentica il tunnel, chi altro può usarlo? L'accesso identifica un soggetto e la rotta che installa descrive un ambito, e queste due cose non sono lo stesso oggetto. Tra di esse ci sono il sistema operativo, la configurazione del client e ciò che il servizio privato esige da sé. Confrontare i punti di applicazione è l'unico modo per rispondere senza indovinare.

Un accesso, più ambiti

L'autenticazione risponde a chi è stato ammesso. La rotta risponde a quali pacchetti possono uscire dal tunnel. L'autorizzazione risponde a quale servizio accetterà la connessione risultante, e nessuna delle tre implica la successiva.

Un tunnel a livello di host è l'impostazione predefinita comune e rende evidente il divario. La rotta sta nella tabella del kernel, quindi ogni processo che usa quella tabella può raggiungere la rete privata, compreso uno avviato da un utente che non ha mai visto la finestra VPN. Non è un difetto del tunnel; è ciò che significa una rotta a livello di sistema. Il servizio privato può comunque rifiutare la connessione, ed è per questo che raggiungibilità e autorizzazione richiedono risposte separate.

Scrivere le quattro domande prima del test impedisce alla revisione di ridursi a una di esse.

Dove si trova davvero il confine

Quattro disposizioni coprono la maggior parte delle macchine: un tunnel a livello di host, una connessione per utente, un elenco di applicazioni consentite e uno spazio dei nomi di rete o una macchina virtuale separati.

Ognuna colloca il punto di applicazione altrove, e le differenze contano più delle etichette. Una connessione per utente è applicata dai permessi del profilo, non dalla schermata di accesso del desktop. Un elenco di applicazioni consentite è applicato all'interno del client, che decide che cosa trasporterà. Uno spazio dei nomi o una VM applica al confine dell'interfaccia, così un processo all'interno non vede affatto la rotta dell'host. Il numero di schermate di accesso sulla macchina non dice nulla di nessuna di esse.

Leggere la tabella riga per riga mostra che la vera domanda non è se esista isolamento, ma dove sia implementato.

Confronta quattro punti di applicazione

Su Linux la tabella delle rotte è la prima cosa da ispezionare, perché un tunnel a livello di host compare lì e uno spazio dei nomi no. Eseguire la ricerca come secondo utente è il passo che le persone saltano; la risposta differisce da quella ottenuta come se stessi, e questo spiega il rapporto.

I due controlli successivi guardano la politica, non l'instradamento. Una regola del firewall che corrisponde a un UID si applica al traffico generato localmente, quindi può separare due utenti su un host anche quando entrambi condividono la rotta. Un profilo di connessione con un elenco esplicito di autorizzazioni è applicato dal gestore di rete all'attivazione. Nessuno dei controlli richiede di cambiare il tunnel, ed è per questo che vale la pena farli prima di riprogettare qualsiasi cosa.

ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuid

Se la seconda ricerca mostra la rotta del tunnel, il confine non è dove la progettazione supponeva.

Le regole sulle sessioni simultanee sono un controllo separato

I gateway limitano spesso quante sessioni può tenere un account, e quel limite non ha nulla a che vedere con gli utenti locali. Limita l'account, quindi una seconda persona che accede con le stesse credenziali può terminare il tunnel della prima.

Leggi l'errore prima di supporre un problema locale di isolamento. Un limite di sessioni produce una disconnessione al gateway, mentre un problema di ambito produce un tunnel funzionante che semplicemente non trasporta il traffico dell'altro utente. Questi due sintomi portano a correzioni del tutto diverse. Conserva il messaggio esatto del client, perché di solito nomina la regola. Chiedi al proprietario del profilo il flusso di lavoro approvato invece di aggirare il limite.

Una macchina virtuale non esenta nessuno da quella regola e aggiunge un proprio progetto di rete e di credenziali.

Prova il contesto che ti interessa

Prova l'utente e l'applicazione previsti, poi prova un contesto che dovrebbe essere negato. Una revisione che dimostra solo che la password originale funziona ha provato l'autenticazione e nient'altro.

sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'

Annota il punto di applicazione accanto a ogni risultato: la tabella delle rotte, una regola UID, un'autorizzazione di profilo o la politica di sessioni del gateway. Quella traccia rende verificabile il cambiamento successivo. Impedisce anche che la stessa domanda venga riaperta ogni volta che qualcuno nota una seconda schermata di accesso. La raggiungibilità non è autorizzazione, e nessuna delle due è isolamento.