Moure OpenVPN de TAP a TUN: un ordre de migració que funciona

Substituir dev tap per dev tun canvia què porta el túnel, no només com s'anomena. Una interfície TAP lliura trames Ethernet a un pont, així que els clients es comporten com si estiguessin endollats al commutador de l'oficina. Una interfície TUN porta paquets IP, així que els clients necessiten rutes i l'altre costat necessita un camí de tornada. Els clients, el pla d'adreces i la ruta de tornada de la LAN s'han de moure amb aquest canvi.

La migració és un redisseny de la xarxa amb un túnel afegit, i l'ordre de sota el manté reversible.

Inventarieu què depèn realment d'Ethernet

Llisteu les aplicacions, no els amfitrions. Determineu si cadascuna fa servir serveis TCP o UDP encaminats, descobriment per difusió, DHCP de la LAN de l'oficina, un protocol Ethernet que no sigui IP o la suposició que tots dos extrems són a la mateixa subxarxa. L'accés IP ordinari sobreviu a un disseny encaminat. Un protocol que necessita trames Ethernet en brut no, i cap quantitat d'encaminament el farà funcionar. Les aplicacions que depenen del descobriment necessiten un mecanisme de substitució decidit abans del canvi, no durant.

Aquest inventari és també la llista d'acceptació. Cada entrada que no podeu migrar es converteix en una excepció documentada o en una raó per mantenir viu un petit segment TAP només per a aquesta càrrega.

Construïu el pla d'adreces i rutes de tornada

Trieu un prefix de clients que no se solapi amb la LAN, el rang antic del pont ni cap xarxa a què un client ja arribi.dev tun, topology subnet i server 10.78.0.0 255.255.255.0, però això és un fragment, no un perfil que funcioni. Manteniu-hi al voltant la política aprovada de TLS, identitat, transport i accés, i feu servir un prefix que hàgiu verificat com a lliure.

Després anoteu les destinacions a què els clients han d'arribar i qui proporciona el camí de tornada. El servidor necessita el reenviament activat i un camí permès endavant. Els encaminadors de la LAN necessiten una ruta de tornada al prefix nou, o el disseny necessita traducció d'origen amb el cost de visibilitat que això implica. Una ruta enviada a la configuració del client configura el client, no el camí de resposta de la LAN.

Proveu-ho en un oient separat

Aixequueu el servei nou al costat del vell, al seu propi port i al seu propi rang d'adreces, en lloc de substituir l'únic punt d'entrada que funciona. Emetiu perfils de prova pel procés d'inscripció existent perquè ningú no refaci la CA per una migració. Connecteu un client representatiu amb només el camí de prova actiu i després compareu les adreces assignades, el DNS privat, les aplicacions de l'inventari i els camins que han de quedar bloquejats.

Incloeu una prova de reconnexió i de trànsit de tornada. Una negociació que es completa no diu res sobre si l'altre costat pot respondre.

Moveu els clients en grups amb reversió

Migreu en grups prou petits perquè una fallada sigui una tasca de suport i no una caiguda. Manteniu el servei vell en marxa i documentat fins que els fluxos de treball reals de cada grup passin, i escriviu la reversió com un retorn al perfil anterior, no com una reconstrucció. Actualitzeu les regles de tallafocs basades en adreces, la monitorització i qualsevol accés iniciat pel servidor per al prefix nou a mesura que cada grup es mou.

Els grups també us donen un lloc on descobrir l'aplicació que ningú no ha esmentat, mentre el camí vell encara existeix per comparar.

Retireu el pont només després de l'acceptació

Treure el dispositiu TAP és l'últim pas, no el primer. Comproveu si el pont encara porta l'adreça de gestió del servidor, un camí de monitorització o una càrrega no relacionada abans de suprimir res. Retireu les dependències d'inici, la pertinença al pont i les reserves DHCP a través dels seus propietaris, en aquest ordre, amb una nota del que s'ha eliminat.

La migració s'acaba quan el model d'accés encaminat funciona per a l'inventari, no quan una interfície TAP desapareix de la sortida de ip link.