Wi-Fi pubblico e VPN: cosa il tunnel non copre

Badge verde, portale soddisfatto, browser funzionante: questa è tutta la storia visibile. Ciò che il badge omette è che la connessione cifrata è trasportata proprio dal collegamento senza fili da cui dovrebbe proteggerti. Quel collegamento consegna ancora ogni pacchetto, vede ancora l'indirizzo di destinazione e decide ancora se qualcosa arriva. Ripercorrere il lato portatile di una connessione alberghiera mostra quali parti copre il tunnel e quali lascia a te.

Il collegamento di accesso trasporta tutto

Un tunnel IPsec ESP avvolge un pacchetto interno protetto in un'intestazione esterna che la rete può instradare, e RFC 4303 sezione 3.1.2 illustra questa separazione. Il pacchetto interno è ciò che il tunnel protegge. L'intestazione esterna è ciò che l'hotspot legge per inoltrarlo. Altri progetti incapsulano diversamente, ma la domanda di progettazione è identica: quale percorso di accesso trasporta questa connessione?

Un guasto del gateway o un collegamento che perde pacchetti ferma la consegna senza rivelare il contenuto. Passare a una cifratura più forte non cambia nulla, perché il pezzo mancante è il trasporto, non la crittografia. Una consegna riuscita dimostra altrettanto poco nella direzione opposta, dato che un percorso funzionante non dice nulla sullo stato di nessuna delle due macchine.

Il tuo portatile ha ancora le sue porte

Unirsi a un segmento non attendibile cambia chi può raggiungere le porte su cui ascolta la tua macchina. Un servizio di condivisione file, un agente di amministrazione remota o un server di sviluppo legato a tutte le interfacce è raggiungibile da chiunque in quel segmento, a meno che qualcosa non lo fermi. Il traffico che non entra mai nel tunnel non è protetto da esso. Un ascoltatore che risponde prima che il tunnel sia attivo è esposto esattamente per quella finestra.

Il requisito è ristretto e va enunciato con precisione: il portatile deve raggiungere l'endpoint VPN, e i dispositivi non correlati sull'hotspot non devono raggiungere i servizi locali. Le regole del firewall dell'host esprimono quel confine, e anche le impostazioni di condivisione della piattaforma ne esprimono una parte. Una stampante o un passaggio del portale è un'eccezione circoscritta che aggiungi deliberatamente, non la prova che l'intero hotspot meriti la fiducia di una LAN d'ufficio.

Alcune organizzazioni limitano anche l'accesso locale mentre è attiva una connessione di lavoro, il che è politica e non ingegneria. Leggi quella politica prima di disattivare un firewall per far funzionare una periferica.

Controlla cosa sta effettivamente ascoltando

Guarda i socket invece della pagina delle impostazioni, perché la pagina descrive l'intenzione e la tabella dei socket descrive la macchina. I due elenchi seguenti separano ogni socket in ascolto da quelli che un vicino potrebbe raggiungere. Eseguili sul segmento non attendibile prima di collegare il tunnel.

ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net

Il primo comando mostra ogni socket, e il secondo filtra quelli legati oltre il loopback. Un servizio su 0.0.0.0 o :: è disponibile su ogni interfaccia, compresa quella senza fili, mentre lo stesso servizio su 127.0.0.1 non è affatto raggiungibile dal segmento. La query al resolver conferma quale percorso prende il nome prima che il tunnel esista, ed è lì che interferiscono i portali captive. Ripeti l'elenco dopo la connessione, perché alcuni client sollevano interfacce che cambiano la risposta.

Una porta che compare solo mentre il tunnel è attivo è meno esposta, anche se vale ancora la pena conoscerla. Registra la differenza e non l'elenco assoluto, perché il delta è ciò che il tunnel ha aggiunto.

Non accettare una nuova identità a metà sessione

Un cambio di rotta inatteso, una riconnessione o un reindirizzamento del portale non sono il permesso di accettare un'identità del server diversa. Se il client segnala una discrepanza di certificato o di chiave, trattala come un riscontro sull'identità e non come una connettività da aggirare. Installare un certificato radice inspiegato per far funzionare un portale trasforma un problema di consegna in un problema di fiducia. E il problema di fiducia sopravvive poi al viaggio che lo ha creato.

Usa il flusso del browser del portale stesso, poi riconnetti il tunnel e leggi il registro del client per l'identità che ha verificato. Un errore di identità significa che la controparte non è chi ti aspettavi, mentre un errore di consegna significa che la controparte non ha mai risposto. Il primo è un motivo per fermarsi, il secondo un motivo per provare un altro percorso.

Decidi prima il comportamento in caso di interruzione

Qui si confondono due funzioni diverse. La riconnessione tenta di ripristinare il servizio, mentre una politica di blocco controlla quale traffico è consentito mentre il tunnel è inattivo. Nessuna delle due fornisce un collegamento senza fili funzionante, e nessuna dimostra che l'endpoint sia pulito. Scegli esplicitamente: errore chiuso per le applicazioni che non devono mai usare il percorso locale, e consenti la navigazione ordinaria fuori dal tunnel se ciò è accettabile.

Annota la scelta, perché il valore predefinito nella maggior parte dei client non è nessuno dei due, e varia con la versione. Poi predisponi un percorso di accesso alternativo se la disponibilità conta, come un hotspot telefonico con il proprio piano dati. Un test di accettazione accettabile ha tre esiti separati: il traffico previsto usa il tunnel verificato, gli ascoltatori locali non correlati sono irraggiungibili, e un'interruzione produce il comportamento scelto.