Un prefisso pubblico per i client VPN: cosa rompe davvero

Un pool di client scelto perché i numeri sembrano ordinati è una rotta in attesa di essere installata. Il prefisso non deve essere privato perché la VPN funzioni, e usare un blocco che appartiene a qualcun altro non espone automaticamente i tuoi utenti a internet. Quello che fa è far significare a questi indirizzi qualcosa di diverso finché il tunnel è attivo, e poi qualcos'altro ancora quando cade. Segui i cinque controlli qui sotto in ordine e fermati dove la risposta è «assegnato altrove».

Assegnare non è annunciare

Mettere un indirizzo su un'interfaccia di tunnel non lo annuncia a internet. La raggiungibilità pubblica richiede una rotta, un percorso autorizzato e un fornitore disposto a trasportarla, e nulla di questo compare perché un client ha ricevuto l'indirizzo da un pool. La politica del firewall e l'autorizzazione dell'host sono ancora decisioni separate.

Ecco perché il rischio non è quello che la maggior parte delle persone suppone. Il prefisso preso in prestito non rende raggiungibili i tuoi client; rende le destinazioni di qualcun altro irraggiungibili dai tuoi client, il che è un guasto diverso con un proprietario diverso. Nessuno viene attaccato e nessun annuncio sfugge. Un utente semplicemente non riesce ad aprire un sito che ieri funzionava, e l'assistenza non ha motivo di sospettare del pool VPN.

La distinzione conta quando scegli un pool. Se la tua unica preoccupazione fosse l'esposizione a internet, un blocco pubblico sembrerebbe sicuro perché nulla lo annuncia. La preoccupazione è la rotta locale che il client installa per quel prefisso, e quella rotta viene installata che qualcun altro possa vederla o no.

Cosa cattura davvero la rotta del client

Quando il tunnel sale, il client riceve una rotta per il prefisso del pool, e quella rotta vince sulla rotta predefinita per ogni destinazione al suo interno. Una richiesta verso un host legittimo in quel blocco ora va alla VPN invece che a internet. Che fallisca, si blocchi o raggiunga il server sbagliato dipende da cosa fa il tuo lato con essa.

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

Esegui la ricerca con il tunnel attivo e di nuovo con il tunnel disattivato. L'indirizzo significa una cosa nel primo caso e qualcosa di completamente diverso nel secondo, e qualsiasi applicazione che abbia memorizzato una connessione o una risoluzione di nome durante quella transizione si comporterà in modo incoerente. Quell'incoerenza è più difficile da supportare di un guasto netto, perché dipende dal momento. Un utente che si riconnette nel momento sbagliato ha un'esperienza diversa da chi non lo fa.

È anche per questo che un indirizzo IP familiare non è una prova di identità. Mantieni la validazione del certificato e del nome del server per la destinazione reale, perché l'indirizzo numerico che hai raggiunto cinque minuti fa ora può appartenere a un'altra conversazione.

Confronta il pool con ogni rete che conosci

RFC 1918 riserva tre blocchi all'uso privato: 192.168.0.0/16, 172.16.0.0/12 e 10.0.0.0/8. Milioni di organizzazioni separate li riutilizzano, quindi privato è un'affermazione sull'assegnazione e mai una promessa che nessun altro abbia scelto gli stessi numeri.

Confronta il pool candidato con le LAN di ufficio, le VPC del cloud, altri pool VPN, i collegamenti dei partner e gli intervalli che i lavoratori da remoto probabilmente hanno a casa. Il caso domestico non è un motivo per inventare un prefisso strano; è un motivo per mantenere il pool piccolo e documentato.

Coordina l'assegnazione con chi possiede l'instradamento e registra il percorso di ritorno nello stesso posto. Un pool verso cui nessuno può instradare al ritorno è un pool che verrà riscoperto durante un guasto. Metti il pool nello stesso documento degli intervalli dei siti, non in una configurazione client che una sola persona ha modificato. Il documento è ciò che rende evitabile la collisione successiva.

Quando l'indirizzamento pubblico è la risposta giusta

Le organizzazioni con spazio globale assegnato correttamente possono senz'altro costruire un pool VPN con indirizzi pubblici, e alcune lo fanno deliberatamente per evitare la traduzione. Quel progetto ha comunque bisogno di instradamento, validazione dell'origine, regole di accesso e autenticazione dei client; l'assegnazione non ne fornisce nessuno.

Quello che fornisce è l'unicità, la proprietà che manca al prefisso preso in prestito. Se possiedi il blocco, la rotta che il tuo client installa punta a indirizzi che sono davvero tuoi, e il significato non cambia quando il tunnel cade.

Non aggiungere NAT automaticamente per compensare una scelta di pool. Un progetto privato instradato con rotte di ritorno esplicite è più pulito di una traduzione applicata perché l'indirizzamento non è mai stato pianificato, e IPv6 ha bisogno di un proprio piano deliberato invece di una copia delle ipotesi IPv4.

Dismetti un pool sbagliato senza perdere l'accesso

Se il pool è già distribuito, fai un inventario prima di cambiarlo: prenotazioni di indirizzi, rotte installate, record DNS che risolvono nel blocco, ambiti del firewall e le applicazioni che ne dipendono. Poi pianifica il cambiamento con la stessa cura di qualsiasi altro passaggio di instradamento. Annuncialo alle persone che se ne accorgeranno, perché le loro sessioni cadranno quando il pool si sposta. Un cambiamento silenzioso dell'indirizzamento dei client genera ticket di assistenza che sembrano non avere rapporto con il lavoro.

Preserva un percorso di ripristino che non dipenda dal pool che stai rimuovendo, perché il momento in cui lo ritiri è il momento in cui il tuo accesso remoto potrebbe sparire con lui. Poi valida entrambe le direzioni: le destinazioni private previste funzionano ancora, e le destinazioni internet che prima venivano catturate ora risolvono ai loro veri proprietari.

Quello che vuoi è un pool che il team di rete possa assegnare, instradare e dismettere come un'unica cosa coerente. Un formato di indirizzo da solo non stabilisce né sicurezza né connettività.