Cosa può e cosa non può vedere un firewall aziendale dentro una VPN
Un firewall può bloccare un tunnel e comunque non leggerne l’interno. Controlla cosa espone l’intestazione esterna, se si applica l’ispezione TLS e verifica la catena.
Lo stesso portatile raggiunge la VPN da casa e non riesce a connettersi dall’ufficio, quindi qualcuno deve stare leggendo il traffico. Bloccare e leggere sono poteri separati, e solo il secondo richiede un punto sul percorso più un certificato di cui il client si fida. Un elemento intermedio che scarta il tuo handshake non ha imparato nulla su ciò che avresti inviato. Decidere quale dei due hai davanti è tutto il lavoro.
Bloccare e leggere sono poteri diversi
Un rifiuto è economico e rumoroso: il socket si apre e nulla risponde, oppure arriva subito un reset. Niente di tutto ciò implica ispezione, perché nessun carico ha attraversato il cavo.
Leggere richiede un punto finale che termini la protezione, si dimostri con un certificato e apra una nuova connessione in avanti. Quel punto deve stare sul percorso ed essere fidato dal client. Un firewall che si limita a inoltrare pacchetti non ha né posizione né credenziale.
Cosa regala l’involucro
Ogni pacchetto del tunnel ha un esterno, e l’esterno deve essere instradabile. Significa due indirizzi, un protocollo, una porta e una lunghezza, più tempi e volume. Qualsiasi router gestisce già quei campi, e un NAT riscrive indirizzo e porta per mantenere coerente la sua tabella di mappatura. Il carico resta sigillato, quindi l’osservazione si ferma al fatto che esiste un tunnel tra due host.
Un nome host non è tra questi. I siti trapelano da altre porte, e la più larga è il DNS: se il portatile chiede ancora al resolver locale, i nomi compaiono in chiaro.
Tempi e volume meritano rispetto senza essere esagerati. Byte al minuto possono mostrare che un trasferimento grande inizia alle 14:20; non possono mostrare quale file si è mosso. È una rivelazione reale sul comportamento, e una categoria diversa dalla lettura del contenuto.
L’intercettazione TLS richiede una radice di cui ti fidi già
Un apparato di ispezione non rompe TLS; lo termina. Al client risponde un certificato da una radice posseduta dall’organizzazione, e una seconda connessione va alla destinazione reale. Il client lo accetta perché quella radice è nel suo archivio di fiducia, ed è per questo che un portatile gestito non mostra alcun avviso. La crittografia non è mai stata sconfitta; è stato spostato il punto finale.
È anche per questo che la disposizione lascia prove. L’emittente della catena presentata appartiene all’organizzazione e non a una CA pubblica, e un client può vederlo senza strumenti speciali. Una catena che termina su una radice interna è la firma dell’intercettazione, non un guasto.
Perché un canale VPN non è una sessione HTTPS
Un canale dati VPN non dà all’ispettore un simile appiglio. IKEv2 e WireGuard eseguono i propri handshake e calendari di chiavi, senza TLS da terminare, mentre OpenVPN prende in prestito TLS per il suo canale di controllo in forma modificata prima di proteggere i dati a modo suo. Un proxy costruito per HTTPS non riconosce quella sessione come qualcosa che possa analizzare.
Un apparato che non riesce ad analizzare una sessione può comunque scartarla. Per questo il blocco delle VPN di solito sembra un timeout e non un avviso di certificato, e per questo un’eccezione non cambia nulla.
Verifica dalla tua macchina
Parti dalla catena che il sito presenta. I dettagli del sito nel browser mostrano l’emittente, e la riga di comando riporta lo stesso senza il riepilogo:
openssl s_client -connect example.com:443 -servername example.comPoi separa un handshake rifiutato dal traffico interno filtrato con dei contatori. Registra la porta di trasporto prima di qualsiasi regola di scarto e leggili dopo il tentativo:
iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbersNessuna riga di log sul socket esterno significa che l’handshake non è mai uscito, quindi il percorso rifiuta il tunnel. Un handshake completato con solo alcune destinazioni che falliscono significa che il tunnel funziona e la politica al suo interno no. Nessuno dei due risultati ha richiesto di leggere un byte di carico.
La lettura che avviene davvero sta ai bordi: un tunnel diviso consegna l’HTTPS interno a un proxy aziendale, e un concentratore di proprietà del datore di lavoro espone tutto in uscita. Qualunque cosa trovi, non disattivare la verifica dei certificati per forzare una connessione, perché quel controllo è l’unica cosa che separa l’ispezione da un attaccante.