Migrare da una VPN basata su PPP senza copiarne le assunzioni

Una migrazione VPN è conclusa quando utenti, destinazioni, risoluzione dei nomi e comportamento in caso di guasto sono ancora corretti, non quando il nuovo client mostra un’icona verde. Le vecchie installazioni basate su PPP portano assunzioni che non sono mai state scritte: un segreto condiviso che fungeva anche da unico controllo d’identità, un pool di indirizzi fisso che il firewall ha in whitelist, un suffisso DNS che il server spinge. Sostituire il protocollo senza inventariare queste assunzioni produce un tunnel che completa l’handshake e una frontiera che non esiste. Il percorso qui sotto è l’ordine che uso io, e l’ultimo passo è quello che i team saltano.

Passo 1: inventariate ciò che fornisce la vecchia connessione

L’inventario si scrive, non si ricorda. Annotate i client supportati, i ruoli di autenticazione, i pool di indirizzi, le reti protette, i requisiti DNS e i permessi di servizio che ogni gruppo di utenti richiede.

Per L2TP/IPsec, separate esplicitamente i due livelli. L’identità del peer IPsec autentica le macchine; PPP autentica l’utente, di solito con CHAP o MSCHAPv2.

È in questa separazione che le vecchie installazioni nascondono le proprie assunzioni. Una chiave precondivisa condivisa da ogni client autentica un gruppo e non un dispositivo, ed è spesso l’unica cosa che sia mai stata ruotata. Se l’account PPP è il vero controllo per utente, ditelo, perché la sostituzione deve riprodurre quel controllo con qualcosa che non sia una stringa condivisa. Annotate anche gli indirizzi sorgente fissi e le eccezioni di rete locale, perché sono le dipendenze che nessuno documenta finché non si rompono.

Passo 2: progettate la sostituzione deliberatamente

Scegliere la sostituzione è una mappatura requisito per requisito: un protocollo e un client mantenuto che l’organizzazione supporta, con ogni requisito di identità e accesso che atterra in un meccanismo reale. Un segreto condiviso non equivale automaticamente a una chiave o a un certificato per dispositivo, e un account PPP per utente non equivale a un certificato di dispositivo.

Coordinate gli intervalli di indirizzi prima di ogni altra cosa, perché un pool sostitutivo che si sovrappone a una LAN domestica o d’ufficio crea un guasto che non ha nulla a che fare con la robustezza del cifrario. Controllate il pool rispetto alla stessa lista che avete costruito per il vecchio servizio, più ciò che il nuovo client assume per impostazione predefinita. Confermate l’instradamento di ritorno per le reti protette e confermate che il nuovo client possa spingere o documentare il suffisso DNS che spingeva il vecchio. Questi due punti generano più ticket di migrazione del cambio di protocollo stesso.

Passo 3: distribuite per fasi e verificate sia il permesso sia il rifiuto

Distribuite con un utente rappresentativo e un’applicazione rappresentativa. Includete la risoluzione DNS privata nel test, perché un tunnel che raggiunge un indirizzo ma non risolve un nome interno è migrato solo a metà. Includete anche lo stato di indisponibilità atteso: cosa deve succedere quando il tunnel cade e se il client lo impone.

Poi provate una destinazione che deve restare negata. Una regola di permesso temporanea ampia può far sembrare sano il nuovo tunnel mentre rimuove silenziosamente la frontiera di autorizzazione che il vecchio servizio applicava, e nessuno se ne accorge fino a un audit. Confrontate i risultati di permesso e rifiuto fianco a fianco, dallo stesso client, nella stessa sessione. Tenete in funzione il vecchio servizio finché entrambe le colonne non corrispondono al progetto.

Prima di spostare l’accesso amministrativo, confermate di avere un percorso di ripristino autorizzato che non dipenda dal tunnel che state cambiando.

Passo 4: ritirate l’identità vecchia

Ritirare correttamente l’identità vecchia significa revocare utenti e credenziali di dispositivo obsolete tramite il servizio che le possiede, poi rimuovere profili e listener vecchi quando non resta alcuna dipendenza. Cancellare un file locale non revoca una copia altrove, e un vecchio listener che accetta ancora il vecchio segreto condiviso è una porta senza sorveglianza.

Vale la pena rallentare su questo punto. Un profilo client dismesso su un portatile non è una credenziale revocata; la credenziale vive sul server e resta valida finché il server non smette di accettarla. Cercate altre copie della vecchia configurazione — dispositivi di test, un telefono dimenticato, un installer che qualcuno ha conservato — e trattate lo spegnimento del listener come il momento in cui il vecchio servizio finisce davvero. Fino ad allora, la migrazione ha due porte d’ingresso.

Il registro di accettazione è l’inventario del primo passo con una colonna in più: cosa fa il nuovo progetto per ogni riga, e come l’avete verificato. Questo trasforma un aggiornamento di protocollo in un requisito di servizio con prove.

Tenete l’esito legato a ciò che serve al servizio e non al nome del protocollo, perché un protocollo moderno con le vecchie assunzioni copiate dentro è lo stesso rischio con una cornice migliore. RFC 3193 descrive come L2TP viene trasportato su IPsec, il che è un utile promemoria del fatto che i due livelli sono sempre stati decisioni separate. Se l’inventario ha una riga che non riuscite a spiegare, fermatevi e scoprite da cosa dipende. La migrazione è finita quando la lista è noiosa.