Gli indirizzi IPv6 non sostituiscono la VPN: ripercorri il lavoro originale

Apri la pagina di stato del client, vedi un indirizzo IPv6 globale e la tentazione è concludere che il tunnel sia diventato facoltativo. Quella pagina mostra un indirizzo, non un confine di cifratura, non una tabella di instradamento privata e non una decisione di accesso. Una VPN di solito porta tre lavori insieme, e IPv6 tocca solo quello che riguarda la condivisione di indirizzi scarsi. Ripercorrere un singolo servizio dal client fino all’ascoltatore è l’unico modo per vedere quale lavoro sopravvive al cambiamento.

Nomina il lavoro prima di rimuovere lo strumento

Le persone dicono «la VPN» quando intendono una di tre disposizioni, e tutte e tre falliscono per ragioni diverse. Raggiungere un’applicazione pubblicata da un solo team è un problema di accesso alle applicazioni. Entrare in un insieme definito di reti private perché più sedi possano raggiungersi è una relazione di instradamento. Mantenere uno strato amministrativo stabile sopra un’infrastruttura che non controlli del tutto è una disposizione operativa con il proprio piano di indirizzamento.

IPv6 rimuove un ostacolo di condivisione degli indirizzi per la prima disposizione, e lì fa lavoro reale, perché un indirizzo diretto può sostituire un traduttore. Per le altre due non cambia nulla, poiché il requisito non è mai stato la scarsità di indirizzi. Scrivi quale delle tre stai davvero eseguendo prima di toccare una configurazione.

Un indirizzo pubblico non è cifratura

Un indirizzo con ambito globale ti dice dove un host è raggiungibile; non dice nulla sul fatto che il traffico che arriva lì sia cifrato o autenticato. La discussione sulla sicurezza della RFC 8504 separa il supporto all’implementazione IPsec dalla scelta più ampia tra IPsec, TLS, SSH e altri approcci, ed è proprio la distinzione che svanisce quando la raggiungibilità viene letta come protezione. Uno stack che supporta un meccanismo ha dimostrato solo che il meccanismo è disponibile, mai che questo flusso l’abbia attraversato. Per IPsec in particolare, l’associazione negoziata e il traffico che seleziona decidono cosa è protetto, e una famiglia di indirizzi è una proprietà del pacchetto, non una politica per esso.

La raggiungibilità è di nuovo una questione separata. Un indirizzo pubblico non fa arrivare traffico non richiesto, perché la rotta, il firewall e l’ascoltatore hanno ciascuno un voto, e rimuovere NAT rimuove un filtro, non tutti. Decidi quale di quei tre il tunnel stesse sostituendo, se ce n’era uno.

Ciò che la sovrapposizione fornisce ancora

Una sovrapposizione continua a guadagnarsi il suo posto in tre situazioni. Gli utenti remoti possono aver bisogno di un insieme specifico di rotte invece di una sola applicazione, due sedi possono aver bisogno di un accordo privato di raggiungibilità, e gli operatori possono volere un indirizzamento che non cambia quando cambia il provider di accesso. Nessuna delle tre riguarda la scarsità di indirizzi IPv4.

Gli indirizzi globali non rendono tutto questo privo di manutenzione. Un piano interno ordinato non mantiene l’endpoint esterno in ascolto dopo che il provider lo cambia, e l’autenticazione, la riconnessione e gli aggiornamenti dei nomi hanno ancora bisogno di un responsabile. Decidi come si ripristinano prima che qualcosa venga spento.

Ripercorri il servizio che diventa pubblico

Parti dall’host e elenca ciò che è davvero in ascolto, perché l’applicazione che hai approvato è raramente l’unica cosa sulla macchina. ss -lntup stampa ogni ascoltatore TCP e UDP con il suo indirizzo di bind e aggiunge il processo proprietario dove i tuoi privilegi lo consentono, il che mostra a colpo d’occhio se un’interfaccia di gestione sta su un indirizzo jolly o solo su loopback. Ripetilo come ss -6 -lntup se il tuo stack tiene separati i socket IPv6.

Poi classifica ogni riga per pubblico. Una porta applicativa che porta con sé autenticazione e sicurezza del trasporto può andare bene su un indirizzo pubblico, mentre un’interfaccia amministrativa, un endpoint delle metriche e una porta di database di solito no. Un’applicazione approvata è un giudizio su quella sola applicazione, mai il permesso di esporre ogni servizio che condivide l’host. L’indirizzo di bind su ogni riga ti dice se l’esposizione esiste già o sarebbe creata dal cambiamento che stai pianificando.

Due test, poi decidi cosa spegnere

Prima di rimuovere uno strato, rispondi a due domande su carta. Primo, il requisito ha bisogno di instradamento privato, cioè di raggiungibilità che un indirizzo pubblico non implica e il provider di accesso non offre? Secondo, ha bisogno di un confine di protezione, cioè di cifratura e autenticazione su un flusso che altrimenti attraverserebbe un percorso non fidato in chiaro? Se entrambe le risposte sono no per quel servizio, il tunnel è candidato alla rimozione; se una è sì, resta.

Esegui lo stesso test su IPv4 e IPv6 separatamente su un client dual-stack, perché il traffico IPv4 protetto non descrive nulla del percorso IPv6. Un indirizzo IPv6 globale in una pagina di stato non è prova di una fuga, e la sua assenza non è prova di protezione. Spegni solo i servizi per cui entrambe le risposte sono state scritte e sono ancora no, e annota nel registro delle modifiche quale domanda l’ha deciso.