Spostare OpenVPN da TAP a TUN: un ordine di migrazione che funziona

Sostituire dev tap con dev tun cambia ciò che il tunnel trasporta, non solo il suo nome. Un'interfaccia TAP consegna frame Ethernet a un bridge, quindi i client si comportano come se fossero collegati allo switch dell'ufficio. Un'interfaccia TUN trasporta pacchetti IP, quindi i client hanno bisogno di rotte e l'altro lato ha bisogno di un percorso di ritorno. I client, il piano degli indirizzi e la rotta di ritorno della LAN devono tutti spostarsi con quel cambiamento.

La migrazione è una riprogettazione della rete con un tunnel allegato, e l'ordine sotto la mantiene reversibile.

Inventariate ciò che dipende davvero da Ethernet

Elencate le applicazioni, non gli host. Determinate se ciascuna usa servizi TCP o UDP instradati, scoperta tramite broadcast, DHCP dalla LAN dell'ufficio, un protocollo Ethernet non IP o l'assunzione che entrambe le estremità siano nella stessa sottorete. L'accesso IP ordinario sopravvive a un progetto instradato. Un protocollo che richiede frame Ethernet grezzi no, e nessuna quantità di routing lo farà funzionare. Le applicazioni che dipendono dalla scoperta hanno bisogno di un meccanismo sostitutivo deciso prima del passaggio, non durante.

Quell'inventario è anche la lista di accettazione. Ogni voce che non potete migrare diventa un'eccezione documentata o un motivo per tenere vivo un piccolo segmento TAP solo per quel carico.

Costruite il piano degli indirizzi e delle rotte di ritorno

Scegliete un prefisso client che non si sovrapponga alla LAN, all'intervallo vecchio del bridge o a qualsiasi rete che un client raggiunge già.dev tun, topology subnet e server 10.78.0.0 255.255.255.0, ma questo è un frammento, non un profilo funzionante. Mantenete attorno la politica approvata di TLS, identità, trasporto e accesso, e usate un prefisso che avete verificato come libero.

Poi annotate le destinazioni che i client devono raggiungere e chi fornisce il percorso di ritorno. Il server ha bisogno dell'inoltro attivo e di un percorso consentito in avanti. I router della LAN hanno bisogno di una rotta verso il nuovo prefisso, oppure il progetto ha bisogno della traduzione di origine con il costo di visibilità che comporta. Una rotta spinta nella configurazione del client configura il client, non il percorso di risposta della LAN.

Provate su un listener separato

Alzate il nuovo servizio accanto al vecchio, sulla sua porta e sul suo intervallo di indirizzi, invece di sostituire l'unico punto d'ingresso che funziona. Emettete i profili pilota tramite il processo di registrazione esistente, così nessuno ricostruisce la CA per una migrazione. Collegate un client rappresentativo con solo il percorso pilota attivo, poi confrontate gli indirizzi assegnati, il DNS privato, le applicazioni dell'inventario e i percorsi che devono restare bloccati.

Incluse una prova di riconnessione e di traffico di ritorno. Una stretta di mano che si completa non dice nulla sulla capacità dell'altro lato di rispondere.

Spostate i client a gruppi con un rollback

Migrate a gruppi abbastanza piccoli che un guasto sia un'attività di supporto e non un'interruzione. Tenete il vecchio servizio in funzione e documentato finché i flussi di lavoro reali di ogni gruppo non passano, e scrivete il rollback come un ritorno al profilo precedente, non come una ricostruzione. Aggiornate le regole del firewall basate sugli indirizzi, il monitoraggio e qualsiasi accesso avviato dal server per il nuovo prefisso mentre ogni gruppo si sposta.

I gruppi vi danno anche un posto dove scoprire l'applicazione che nessuno ha menzionato, mentre il vecchio percorso esiste ancora per il confronto.

Ritirate il bridge solo dopo l'accettazione

Rimuovere il dispositivo TAP è l'ultimo passo, non il primo. Controllate se il bridge porta ancora l'indirizzo di gestione del server, un percorso di monitoraggio o un carico non correlato prima di cancellare qualcosa. Ritirate le dipendenze di avvio, l'appartenenza al bridge e le prenotazioni DHCP tramite i loro proprietari, in quest'ordine, con una nota di ciò che è stato rimosso.

La migrazione è finita quando il modello di accesso instradato funziona per l'inventario, non quando un'interfaccia TAP scompare dall'output di ip link.