Una rete può bloccare la tua VPN senza rompere la crittografia?

Nessun operatore ha bisogno di una chiave di sessione per fermare un tunnel: scartate i pacchetti sul percorso e fallisce, mentre la crittografia resta esattamente forte quanto prometteva il suo progetto. La crittografia protegge ciò che una conversazione trasporta, non la volontà di una rete qualsiasi di trasportarlo. Separare queste due proprietà trasforma una discussione sull’impossibilità di bloccare in una domanda su quale politica sia in vigore e fin dove arrivi. Il confronto qui sotto tiene separati disponibilità e riservatezza, perché la maggior parte delle affermazioni sicure sul blocco delle VPN le fonde senza dirlo.

La raggiungibilità è una decisione del percorso

Ogni trasporto dipende da un percorso che inoltra i pacchetti, e ogni questione di politica qui si riduce a quella decisione di inoltro. Una regola che scarta i pacchetti cambia la disponibilità senza toccare la riservatezza, ed è così che un tunnel può essere perfettamente cifrato e del tutto inutilizzabile nello stesso momento. Nulla di quel risultato richiede di rompere un cifrario o recuperare una chiave. Richiede solo il controllo del percorso.

La confusione di solito nasce da due proprietà che condividono una parola. Una crittografia forte dice chi può leggere un flusso; non dice nulla se un dispositivo intermedio lo lascerà passare. L’affermazione che una VPN non può essere bloccata ha quindi bisogno di una seconda affermazione sotto di sé, cioè che nessuno sul percorso sia disposto a scartare i pacchetti.

Stili di applicazione e prezzo di ciascuno

Tre stili coprono la maggior parte delle politiche reali, e differiscono per ciò che devono sapere, per quanto costa gestirli e per chi altro ne soffre. Ciascuno può negare un tunnel senza decifrare nulla. Le differenze contano perché la stessa parola, blocco, serve per tutti e tre.

Quella tabella è una mappa dei costi, non una classifica. Una lista di blocco è economica da avviare e costosa da mantenere accurata; una lista di autorizzazione scambia la scoperta con la manutenzione dell’insieme consentito, e un’interruzione non ha bisogno di alcuna classificazione. Ciò che le separa non è la raffinatezza tecnica ma dove ciascuna mette lo sforzo continuo. Una politica che sembra semplice sulla carta di solito ha una riga di manutenzione nascosta altrove.

Una lista di blocco è limitata da quanto bene un indirizzo nomina un servizio

Una lista di blocco nega le destinazioni già identificate e lascia le altre generalmente disponibili. Per applicarla servono indirizzi e porte, non testo in chiaro, ed è ciò che la rende economica da gestire all’inizio. Il costo arriva più tardi, perché un intervallo che un tempo identificava un fornitore può poi ospitare una dozzina di inquilini non correlati. Ogni cambio di indirizzo impone una modifica della lista, e ogni voce obsoleta porta con sé traffico innocente.

La precisione in questo modello è limitata da quanto bene una destinazione identifica un servizio, e un endpoint condiviso e molto trafficato è un cattivo identificatore. È un limite strutturale e non un difetto di implementazione, quindi strumenti migliori non lo eliminano. Spiega anche perché le liste di blocco tendono a crescere: ogni nuovo endpoint sembra una piccola aggiunta, e il danno collaterale cresce con la lista.

Una lista di autorizzazione sposta il carico di manutenzione

Una lista di autorizzazione inverte l’impostazione predefinita così che passino solo le destinazioni o i tipi di traffico scelti in anticipo. Non deve elencare ogni endpoint vietato, il che aiuta quando l’insieme vietato è grande o cambia in fretta. Le serve invece una definizione mantenuta di ciò che è consentito, più un’applicazione che corrisponda a quella definizione.

I numeri di porta sono il punto debole abituale in una definizione del genere. Consentire una porta non equivale a identificare ogni applicazione che può usarla, quindi una lista di autorizzazione basata sulle porte spesso ammette più di quanto il suo autore intendesse. Le impronte dei protocolli hanno lo stesso problema da un altro angolo, perché identificano una forma di traffico e non un’intenzione. Una lista di autorizzazione non è quindi automaticamente più precisa di una lista di blocco; è precisa su qualcos’altro.

Che cosa una sola osservazione può sostenere e che cosa no

Qualunque affermazione sul blocco va letta con quattro domande in mano: quali reti di accesso, quali destinazioni, quali protocolli e quale periodo di osservazione. Un guasto visto oggi su una rete mobile non dice nulla sullo stesso endpoint domani da un’altra rete. Nemmeno un tunnel che ha funzionato una volta dice qualcosa sulla disponibilità duratura.

La forma di un guasto è osservabile prima di teorizzare sulla sua causa. Un blocco silenzioso, un rifiuto immediato e un reset dopo la connessione indicano stili di applicazione diversi, e due comandi li distinguono:

curl -sS -m 8 https://vpn.example.com/ -o /dev/null -w "%{http_code}\n"
traceroute -n -m 8 vpn.example.com

Un blocco che termina in timeout suggerisce uno scarto silenzioso, un rifiuto rapido un dispositivo che rifiuta sul percorso, e un reset dopo la connessione un’interferenza con stato invece di una rotta assente. L’indagine RFC 9505 sulle tecniche di censura descrive i punti di controllo e i modelli di interferenza dietro quelle forme. Nessuno di essi dice però fino a che punto si applichi la politica. La permanenza è un’affermazione più forte della raggiungibilità: endpoint, software, politiche e servizi consentiti cambiano tutti, quindi un’efficacia indefinita richiede ipotesi sulla continuazione dell’applicazione e non un elenco di indirizzi visti in un solo momento.