Flytte OpenVPN frå TAP til TUN: ein migrasjonsrekkjefølgje som fungerer

Å byte dev tap mot dev tun endrar kva tunnelen ber, ikkje berre kva han heiter. Eit TAP-grensesnitt leverer Ethernet-rammer til ei bru, så klientane oppfører seg som om dei var kopla til svitsjen på kontoret. Eit TUN-grensesnitt ber IP-pakkar, så klientane treng ruter og den andre sida treng ein veg tilbake. Klientane, adresseplanen og returruta til LAN-et må alle flyttast med den endringa.

Migrasjonen er ein redesign av nettverket med ein tunnel påmontert, og rekkjefølgja nedanfor held han reversibel.

Kartlegg kva som faktisk er avhengig av Ethernet

List opp applikasjonane, ikkje vertane. Avgjer om kvar av dei brukar ruta TCP- eller UDP-tenester, oppdaging via kringkasting, DHCP frå kontor-LAN-et, ein Ethernet-protokoll som ikkje er IP, eller ei føresetnad om at begge endane ligg i same subnett. Vanleg IP-tilgang overlever eit ruta design. Ein protokoll som treng rå Ethernet-rammer gjer det ikkje, og inga mengd ruting får han til å verke. Applikasjonar som er avhengige av oppdaging treng ein erstatningsmekanisme som er bestemt før overgangen, ikkje under han.

Den kartlegginga er også akseptlista. Kvar oppføring du ikkje kan flytte, blir eit dokumentert unntak eller ein grunn til å halde eit lite TAP-segment i live for nettopp den arbeidsmengda.

Lag planen for adresser og returruter

Vel eit klientprefiks som ikkje overlappar LAN-et, det gamle bruområdet eller noko nettverk ein klient allereie når. Ein tenar med subnett-topologi treng eit fragment som dev tun, topology subnet og server 10.78.0.0 255.255.255.0, men det er eit fragment og ikkje ein fungerande profil. Hald den godkjende TLS-, identitets-, transport- og tilgangspolicyen rundt det, og bruk eit prefiks du har stadfesta at er ledig.

Skriv så ned måla klientane må nå og kven som syter for returvegen. Tenaren treng videresending slått på og ein tillaten veg vidare. LAN-rutarar treng ei rute tilbake til det nye prefikset, eller så treng designet kjeldeomsetjing med den synlegheitskostnaden det fører med seg. Ei rute som blir dytta til klienten konfigurerer klienten, ikkje svarvegen til LAN-et.

Prøv på ein eigen lyttar

Set den nye tenesta opp ved sida av den gamle på sin eigen port og sitt eige adresseområde, i staden for å byte ut det einaste inngangspunktet som verkar. Utsted prøveprofilar gjennom den eksisterande registreringsprosessen så ingen byggjer CA-en på nytt for ein migrasjon. Kopla til éin representativ klient med berre prøvevegen aktiv, og samanlikn deretter tildelte adresser, privat DNS, applikasjonane frå kartlegginga og vegane som skal halde fram med å vere blokkerte.

Ta med ein test for attkopling og returtrafikk. Eit handtrykk som fullførast seier ingenting om den andre sida kan svare.

Flytt klientar i grupper med ein tilbakerulling

Migrer i grupper som er små nok til at ein feil blir ein støtteoppgåve i staden for eit avbrot. Hald den gamle tenesta i drift og dokumentert til dei reelle arbeidsflytane til kvar gruppe passerer, og skriv tilbakerullinga som ei tilbakekopling til førre profil, ikkje ein gjenoppbygging. Oppdater adressebaserte brannmurreglar, overvaking og all tenarinitiert tilgang for det nye prefikset etter kvart som kvar gruppe flyttar seg.

Grupper gjev deg også ein stad til å oppdage applikasjonen ingen nemnde, medan den gamle vegen enno finst å samanlikne med.

Avvikla brua først etter aksept

Å fjerne TAP-eininga er det siste trinnet, ikkje det første. Sjekk om brua enno ber administrasjonsadressa til tenaren, ein overvakingsveg eller ei urelatert arbeidsmengd før du slettar noko. Avvikla oppstartsavhengnader, brumedlemskap og DHCP-reservasjonar gjennom eigarane deira, i den rekkjefølgja, med eit notat om kva som vart fjerna.

Migrasjonen er ferdig når den ruta tilgangsmodellen fungerer for kartlegginga, ikkje når eit TAP-grensesnitt forsvinn frå utdata frå ip link.